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.