Closed Bug 681004 Opened 8 years ago Closed 8 years ago
TI: Slower than m-c on closure-compiled fasta benchmark
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.