[webkit-dev] interested in js speed-up

[Edward Rowe]

Hi Geoff -

It sounds as though you looked at adopting Tamarin and decided against
it. Can you flesh out what you came up with as the pros and cons of
using Tamarin vs. writing a new engine from scratch? Did you have
discussions with the folks involved in Tamarin regarding adapting it to
your needs? As I'm sure you know, writing a world class VM and moving it
forward is hard and expensive. I hate to our see efforts being split
across multiple JS implementations, which dilutes all of our time for
moving the web forward.


Ed Rowe
Adobe Systems

 

-----Original Message-----
From: webkit-dev-bounces at lists.webkit.org
[mailto:webkit-dev-bounces at lists.webkit.org] On Behalf Of Geoffrey Garen
Sent: Tuesday, March 04, 2008 12:01 PM
To: Akos Kiss
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] interested in js speed-up

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