Re: asm.js support?
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.
Re: asm.js support?
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.
asm.js support?
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.
Re: asm.js
My understanding is that asm.js is all or nothing. It is designed as a target for languages that manage their own memory (that is generally not garbage collected, but you could implement garbage collection in such a system). Firefox looks at the JavaScript and decides if it is asm.js, then switches to another JavaScript interpreter that is optimized for asm.js. If this interpreter detects anything outside of the asm.js subset, it kicks all execution back to the standard interpreter. This means you can't pick part of a gwt compile to target asm.js; it would be all on none. Ed On Thursday, May 23, 2013 12:52:00 AM UTC-7, RyanZA wrote: > > Have a quick read through this article if you don't know what asm.js is: > > http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/ > > With firefox already supporting it, GWT should have the firefox compile > target target asm.js for, at least, things like ArrayList. > I didn't see anything about it in the recent I/O talk - has anybody looked > at how difficult it would be to support in the GWT compiler ? > > Ryan > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: asm.js
On Thursday, May 23, 2013 9:52:00 AM UTC+2, RyanZA wrote: > > Have a quick read through this article if you don't know what asm.js is: > > http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/ > > With firefox already supporting it, GWT should have the firefox compile > target target asm.js for, at least, things like ArrayList. > I didn't see anything about it in the recent I/O talk - has anybody looked > at how difficult it would be to support in the GWT compiler ? > > Copied from Ray Cromwell's comment on https://plus.google.com/107037260910017774154/posts/179TxALiF5v: > Well, GWT assumes garbage collection semantics, and ASM.JS assumes typed > arrays for everything and malloc/free semantics. So it wouldn't hard to > support asm.js, but we'd end up memory leaking like crazy unless we > implemented a mark/sweep collector in JS :) -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
asm.js
Have a quick read through this article if you don't know what asm.js is: http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/ With firefox already supporting it, GWT should have the firefox compile target target asm.js for, at least, things like ArrayList. I didn't see anything about it in the recent I/O talk - has anybody looked at how difficult it would be to support in the GWT compiler ? Ryan -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.