[webkit-dev] interested in js speed-up
akiss at inf.u-szeged.hu
Wed Mar 12 10:51:13 PDT 2008
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.
Geoffrey Garen írta:
> Hi Akos.
> 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.
>> 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
>> 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
> 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
> 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
> 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.
More information about the webkit-dev