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