There have been a few quick discussions about this in ##gwt on irc, and while I think we probably need to both move this to -contrib before much longer but also get some of the compiler experts involved, I suspect this is going to end up being a specific tool to optimize sufficiently c-like methods, not the entire application.
The asm.js 'language' restricts down to just a few things - a TypedArray for a heap, standard lib (math, etc), and a variety of primitives. Within each module you can declare individual functions (as well as arrays of functions to do vtable sorts of things), and return a set of named functions to allow outside code to call into this asm-ified code. This appears to greatly limit what code can do. Since you are confined to a heap, there is no free GC, it has to be implemented (or garbage collect the whole heap with the rest of the module). Since the set of functions in the module is 'exported', and the module may be given a set of 'foreign' functions, it seems likely that individual GWT methods could be compiled to asm-compatible code if they meet certain criteria. The more complex the data going in and out is (i.e. serializing strings or complete objects to the 'heap', then deserializing to call foreign functions or to return again), the more expensive that each call will end up being, so either methods must opt in to this (via an annotation perhaps?), or the compiler has to have a pretty specific heuristic to decide if a method is eligible or not (for example, 'does this method take only primitive/primitive[] arguments, use only primitive/primitive[] fields, return a primitive/primitive[] value, and call only other methods which meet this same criteria?'). Then, methods should be grouped so that they share a heap and are only compiled once, so that they can start to deal with field in a consistent way without encoding/decoding (i.e. asm-ify all of an object's methods, store its fields in the heap, and GC the whole heap when the object itself goes away, and expose methods that can read out fields (getters/setters) directly from that heap). In short, the developer will likely need to be very aware of what GWT is going to try to do it their code and monitor something like the compiler report to see why a particular slow method isn't getting asm-ified. Ümit's point is probably right that for general purpose code, compiling code that the browser can handle efficiently while still viewing it as JS is a far easier win. But since the asm-ification has to be done to the JS code itself, I doubt that simply a library will make it possible to produce asm-compatible code, but instead that the compiler will need to be aware and actively participating, unless all such code is to be written in JSNI. On Tuesday, February 4, 2014 7:42:12 AM UTC-6, Ümit Seren wrote: > > What is your use case ? > AFAIK asm.js is only intended as a highly efficient backend/LLVM for C++/C > code (emmscripten). > It's quite low level and usually as a programmer you don't directly code > against asm.js (it is quite painful to work with: > http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html). > > In addition to this traditional web-development (DOM/CSS, javascript code) > won't won't really benefit from asm.js. > It would be only beneficial for games and computational (scientific) > workloads (maybe create a library similar to Elemental for that use case). > If you are concerned about performance than it would be better to push for > the GWT compiler to emit code that is optimized for modern javascript > engines (V8, etc). > > > > > > On Monday, February 3, 2014 6:29:30 PM UTC+1, Bora Ertung wrote: >> >> Are there any plans for asm.js support for GWT compiled code? Chrome has >> started support asm.js optimizations and I think it is about time to add >> this into GWT. >> >> any ideas? >> -B >> >> >> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
