[webkit-dev] interested in js speed-up

Wed Mar 12 11:37:40 PDT 2008

On Mar 12, 2008, at 10:51 AM, Akos Kiss wrote:

> 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. :)

There are some optimizations which are useful to do at the AST level  
and which will continue to benefit when execution is through bytecode.  
There are also optimizations to the GC and other parts of the runtime  
possible. But, as Geoff said, we should have the bytecode framework  
out in basic form in a week or two.

  - Maciej

>
>
> 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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev