Last Comment Bug 959263 - OdinMonkey: move code generation into parallel compilation jobs
: OdinMonkey: move code generation into parallel compilation jobs
Status: RESOLVED DUPLICATE of bug 1181612
:
Product: Core
Classification: Components
Component: JavaScript Engine: JIT (show other bugs)
: unspecified
: x86_64 Linux
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Hannes Verschore [:h4writer]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-13 10:10 PST by Luke Wagner [:luke]
Modified: 2015-10-18 08:56 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Luke Wagner [:luke] 2014-01-13 10:10:12 PST
Right now, the final codegen step of compilation happens on the main thread.  This mostly falls out from having a single MacroAssembler so that all asm.js code in in a single linear slab.  Thus the main challenge to parallelizing codegen is to give each AsmJSParallelTask its own MacroAssembler and replace any current cross-function labels (viz., the ones used for function calls and exit trampolines) with entries in AsmJSStaticLinkData.  From my measurements, this would win more than 1 second on Epic Citadel uncached startup (whose compilation is about 5s).
Comment 1 User image Luke Wagner [:luke] 2014-01-22 14:46:06 PST
It looks like it would be easiest to wait until bug 760642 lands before trying to do this.  Otherwise, this patch will end up just getting in its way.  (Specifically, bug 760642 changes how calls are patched so that we use the single-instruction encoding in the common case and the 3-byte instruction only when the distance between the call and target is bigger than 32MB and this all requires having all the IonAssemblerBuffers together at once at link time which is counter to what I was thinking in comment 0.)
Comment 2 User image Luke Wagner [:luke] 2014-01-22 14:46:47 PST
s/3-byte instruction/3-instruction call/
Comment 3 User image Luke Wagner [:luke] 2014-06-10 17:44:49 PDT
Actually, codegen is a pretty significant part of main thread compilation these days, 2.1s (out of 8s) on Unity DT2 and .47s out of 1.9s on WMW.  Given that we're only saturating ~2 cores atm, this would mean a roughly 25% wall clock reduction.
Comment 4 User image Luke Wagner [:luke] 2015-04-23 08:16:47 PDT
Bug 1157624 would mostly subsume this in a much simpler way that took codegen off the main parsing thread but still kept it sequential (on its own thread).  Assuming parsing is the bottleneck (it is), this would achieve the desired effect.

*** This bug has been marked as a duplicate of bug 1157624 ***
Comment 5 User image Luke Wagner [:luke] 2015-07-09 02:49:13 PDT

*** This bug has been marked as a duplicate of bug 1181612 ***

Note You need to log in before you can comment on or make changes to this bug.