Closed Bug 681004 Opened 8 years ago Closed 8 years ago

TI: Slower than m-c on closure-compiled fasta benchmark

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: azakai, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached is a compiled and closure-compiled (cc) fasta benchmark. Results with argument 2100000 are

m-c/cc      1.855  (-m -j -p)
jm/cc       3.668  (-m -j -p -n)
v8/cc       2.713

So m-c is fast, but jm takes almost twice as long to complete.


Side note: Interestingly, the picture without running closure compiler is different:

m-c normal  2.890
jm  normal  1.335
v8  normal  2.519

Here TI is very fast, faster than m-c/cc even. So the closure compiler does something to the code that helps m-c a lot, hurts v8 a tiny bit, and hurts TI a lot, making it almost 3 times slower.
Not sure if this is useful or not, but here is the benchmark before closure compiler. And here are the variable mappings:

FS$ensureRoot:S
__Z9makeFastaI10RandomizedEvPKcS2_jRT_:oa
HEAP:u
___setErrNo:K
_fputc:fa
FS$createObject:R
_fputc$$1:X
___setErrNo$$1:J
CorrectionsMonitor$print:ca
_puts:Y
STACK_MAX:z
FS$absolutePath:O
L 0:a
FS$nextInode:da
_free:Z
L 1:b
FUNCTION_TABLE:pa
ALLOC_STATIC:v
L 2:d
L 3:c
STACKTOP:o
intArrayFromString:B
__Z12puts_limitedPc:ka
L 9:s
L 8:k
__ZdaPv:ha
L 7:h
_write:W
L 6:i
L 5:g
Runtime:l
L 4:e
FS$init:ea
FS$analyzePath:P
__ATEXIT__:q
FS$init$initialized:V
STATICTOP:p
FS$streams:M
_llvm_memcpy_p0i8_p0i8_i32:$
FS$createDevice:U
JSCompiler_alias_VOID:f
_main:la
__Znaj:ia
_homosapiens:H
e$$6:ba
FS$root:Q
e$$5:aa
JSCompiler_alias_NULL:j
run:qa
__ZdlPv:ja
L 13:ga
FS$createFolder:T
L 11:n
__ZZ12puts_limitedPcE4left:E
L 12:x
L 10:r
_rng:F
_stdout:L
_iub:G
_malloc:y
__ZL3alu:I
allocate:w
setValue:t
String_len:D
i:A
__ZN14RotatingStringD2Ev:ma
__ZN10CumulativeC2EP3IUB:na
base:C
FS$ignorePermissions:N
abort:m
Kind of goofy, Closure introduced some temporaries which read from the global 'f' (nee JSCompiler_alias_VOID), which is always undefined.  (Side note: I'm not sure why it did this.  It assigns the global to 'n' twice on line 564, which is very hot code, and then almost immediately clobbers it with '1' or '2' in the following conditional).

When *we* compiled these 'n = f' assignments, we inserted a test for undefined that made a stub call that didn't do anything.  Neither the test nor the call are necessary, as 'undefined' had been observed as a possible result of these global property accesses.  I get these times (I don't know how to run this with d8):

js -m -n: 1265
js -m -j -p: 1984

http://hg.mozilla.org/projects/jaegermonkey/rev/4eed9e7ab27f
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Awesome! I get

v8  2.908
m-c 1.925
TI  1.106

(For v8, if you had a problem because of the argument, use '--' before the script args, so |d8 fasta.js -- 2100000|)
You need to log in before you can comment on or make changes to this bug.