4 ms·
> Dart will not be 2x (or more) faster than JS. Why are you so sure of this? The people involved appear to be big believers that dynamic languages can be extr
by equark 15y ago
> Dart will not be 2x (or more) faster than JS.
Why are you so sure of this? The people involved appear to be big believers that dynamic languages can be extremely performant provided they are designed with the VM in mind. LuaJit proves this out. A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C.
http://attractivechaos.wordpress.com/2011/01/23/amazed-by-luajit/ http://attractivechaos.wordpress.com/2011/01/23/amazed-by-lu...
http://lua-users.org/lists/lua-l/2009-06/msg00071.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html
I think far too much emphasis is being placed on whether Dart replaces JS in the browser. Google would gain a huge amount by having a performant server-side language that can be tooled and compiled to JS for the client.
- mraleph 15y ago> A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C. You are using outdated measurements. Up to date results: http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/ http://attractivechaos.github.com/plb/ The difference between V8 and LuaJIT is nowhere near 2x on matmul and comes from differences in language features (no debugger interruption support for generated code in LuaJIT2) and lack of certain optimizations (e.g. array bounds check elimination) in V8 [matmul_v2.lua used for measurements relies on ffi arrays which do not include bounds checks at all]. Code generated by both compilers is roughly equivalent (invariants hosted out of the loop, temporary double values are on xmm registers, etc). A bit more details: http://blog.mrale.ph/post/5436474765/dangers-of-cross-language-benchmark-games http://blog.mrale.ph/post/5436474765/dangers-of-cross-langua...
- equark 15y agoInteresting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have." Where will a redesign likely see gains?
- BrendanEich 15y agoJS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode). These all add some cost in either runtime guards, static analysis burdens, or a mix. A new language could leave out most of these, but it would still want inheritance. Then the question would be: how useful is mutability along the inheritance chain, i.e. shadowing -- even if you remove 'delete'. Beyond this, a new language or a JS extension (this is what the Dash memo rules out as un-possible, without evidence) could allow pinning down the shape of objects, even to include machine types such as int32, etc. That would allow for big speedups on certain benchmarks.
- deleted 15y ago[deleted]
- equark 15y agoI hope Dart proves this out. Things like lack of machine types and operator overloading make Javascript unusable for the data analysis and statistical computing work I'm doing. While these may be feasible Javascript extensions, I can't see how that would come about in the <10 year time frame. And I doubt it would ever happen without some counter example VM. The typical response is that data analysis and statistical computing are server-side tasks. But that is not entirely true. Almost all the scientific applications I have worked on have major front-end needs where the web could help tremendously. On a broader note, one thing I don't quite understand is the complaint about lack of resources. The web browser is one of the most fundamental pieces of technology that exists today. They are also reasonably profitable. From my understanding Google gives Mozilla $60 million a year for the search bar. If browser vendors cannot dedicate new teams of 2-10 programmers on some feature -- like a Dart VM or NaCL clone -- I'm inclined to say the industry should consolidate. New VMs for Javascript are created by hobbyist coders all the time, as part time projects. Why is implementing a new VM and language so much work for Mozilla?