[webkit-dev] interested in js speed-up

[Akos Kiss]

Hi Geoff,

thanks for the info. It seems to me that your answers cancelled my 
options. :) Optimizing the AST is not the best way to go since execution 
moves to bytecode. And designing a new bytecode is not an option anymore 
since you are already doing it. :)

However, this opens new possibilities, namely optimizing the bytecode. 
Is the engine of yours available somehow? (We simply could not find it. 
Our fault, perhaps.) I would be happy to take a closer look at it.

Cheers,
Akos


Geoffrey Garen írta:
> Hi Akos.
> 
> Any help speeding up JavaScriptCore is welcome.
> 
> The current plan is:
> 1. Convert from an AST execution engine to a custom bytecode engine
> 2. Perform low-cost optimizations on the custom bytecode (e.g., simple 
> type inference, peephole optimization, constant folding, copy 
> propagation, hoisting constants out of loops)
> 3. JIT from custom bytecode to machine code at function granularity
> 4. Optimize other parts of the JS runtime, like the garbage collector 
> and the regular expression engine
> 
> We plan to finish stage 1 of this plan, which will be pretty disruptive, 
> by the end of the month.
> 
>> We have compiled a small list of enhancement possibilities, see below.
>> Please consider it as the view of an outsider.
>>
>> ---
>> 1) Optimizing the AST
>>  a) either during AST building
>>  b) or the already built, complete AST, possibly in a background thread.
> 
> We already perform a number of optimizations on the AST. Are there any 
> specific additions you would recommend / like to work on?
> 
>> Comment: The execution model of the JS engine is quite simple. It simply
>> builds an AST from the source and executes it. Thus, there are no CFG,
>> basic blocks, use-definition chains, etc., which are common in
>> traditional optimizing compilers. This either makes the possible
>> optimizations less powerful or requires significan effort to implement
>> such analysis techniques.
> 
> Indeed, those kinds of analysis tools could be very helpful. They could 
> guide optimization, but they could also help us move from a 
> function-granularity JIT to a tracing JIT.
> 
> As we make the parser / compiler more intelligent, the key challenge we 
> face is ensuring that it's still very fast -- ensuring that we can still 
> render web pages in less than 200ms (and sometimes, less than 10ms!).
> 
>> 2) Optimizing the AST execution.
>>
>> Comment: Not enough knowledge on the internals.
> 
> Since we plan to move away from AST execution soon, I don't think 
> optimizing AST execution would be very valuable.
> 
>> 3) JIT compiling the AST to another language.
>>  a) JIT compilation to native code.
>>
>> Comment: Furthermore, the engine is currently platform independent. This
>> would require platform-specific code on a per platform basis.
> 
> Yes.
> 
>>  b) JIT compilation to Java bytecode or ActionScript bytecode.
>>
>> Comment: Huge work. Currently available compiler implementations do not
>> fit to the architecture of the JS engine.
> 
> Right. We're also reluctant to rely on code that we don't own. We've 
> seen very large performance wins from tightly integrating and 
> customizing all the components of the web stack. We also need the 
> freedom to fix crashes and compatibility problems on very short notice 
> (for example, 12 hours before a keynote address).
> 
>>  c) JIT compilation to a new intermediate language.
>>
>> Comment: Is it a good idea to come up with yet-another-bytecode?
>> Interesting: According to the homepage, there are plans to use a
>> bytecode interpreter in the JS engine. However, it is not specified what
>> kind of bytecode is meant: Java, ActionScript, or a new one?
> 
> A new one.
> 
> I suppose the world is not eager to see yet-another-bytecode, but, in 
> prototyping, we've seen measurable performance wins from fine-tuning the 
> bytecode to match JavaScript idioms.
> 
>> So, this is our view. But before starting any work, we would like to
>> hear the opinion of the developers. What do you think of the above? Did
>> we left out something important? Do you think that we can contribute
>> somehow?
> 
> I definitely think you can contribute. We could really use the help of 
> some compiler experts!
> 
> If you're interested in writing optimization passes for the bytecode, 
> that's great. If you're interested in experimenting with translating 
> JavaScriptCore's emitted instructions into a lower level, more 
> established bytecode (for example, the Tamarin engine translates many 
> instructions to Forth), that's great, too. There's really no limit to 
> what you can contribute.
> 
> Since many of us working on the project are not compiler experts, the 
> best contribution you can make might be something we haven't thought of 
> yet.
> 
> I encourage you to dive into the code now, to gain a greater 
> understanding of its internals. Feel free to ask question on IRC 
> (#webkit on irc.freenode.net). The bytecode changes in the short term 
> will be pretty disruptive to the execution engine, but the AST and the 
> rest of the runtime should remain intact.
> 
> If you have an optimization idea you want to discuss, this is a great 
> forum. But you should also feel free just to write up a patch and post 
> it in bugzilla for comment.
> 
> Cheers,
> Geoff