4 ms·

Not necessarily. You can compile a Ruby VM from C to JS, as people have done. That should give you somewhere around 2 times slower performance, or better, not 2

by azakai 12y ago

Not necessarily. You can compile a Ruby VM from C to JS, as people have done. That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). Things get more complicated if your VM has a JIT, but there are interesting results even there, see pypy.js. This approach lets you have arbitrary semantics, even ones that differ hugely from JavaScript, with decent performance. I've suggested this in the past on HN - I think that approach could work for Dart as well. Would be happy to help investigate it.

munificent 12y ago
> You can compile a Ruby VM from C to JS, as people have done. That sounds to me like it would just kill your startup perf. Users would have to download an entire Ruby VM every time they hit your site, wouldn't they? Maybe I'm just a luddite, but spending network resources downloading a garbage collector written in JS only so that I can run it in JS... which natively supports GC just seems really gross to me. Don't get me wrong, I think Emscripten is very very cool. It just feels like a strange fit for applications written in a language whose semantics aren't that far from JS.
- azakai 12y ago
  I see your point, but don't think it is quite as bad as that. For one thing, it would be cached etc., so it is about as bad as every site on the web using jQuery (that is, not great, but not horrible either). Yes, it seems ironic to download a GC written in JS, when JS can do GC. But JS can only do SOME types of GC. For example, it lacks destructor callbacks, which things like Lua require. Some other language might need weakrefs which JS also lacks. So it is not quite that unreasonable to download a GC, as you can get the right semantics you want. But I do agree it gets less clear when the semantics are very close to JS. I'm not sure if Ruby is close enough, though (CoffeeScript certainly is).
  - rapind 12y ago
    While convoluted, I believe this results in some pretty fast js. mruby -> llvm -> emscripten -> asm.js See: http://vimeo.com/70673036 http://vimeo.com/70673036
mraleph 12y ago
> That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). You are comparing different ratios: munificent was comparing against JS and your "2 times" prediction is against native performance of the compiled VM. > there are interesting results even there, see pypy.js. Yes, the most interesting result is that you have to warm up pypy.js with a blow torch, otherwise performance is abysmal. > I think that approach could work for Dart as well. Have you seen people complaining about size of dart2js output? Can you imagine how big emscripten output would be? I have been arguing that dart2js could have been using hand-written JIT compiler on the client side, but the startup performance compared to AOT would really be a big deal. I think a combination of AOT and JIT would be the best, but sadly it is also true that JavaScript lacks right level of abstraction. It is either too low-level (typed arrays, hand rolled allocations etc) or too high-level.

by azakai 12y ago

munificent 12y ago

> You can compile a Ruby VM from C to JS, as people have done. That sounds to me like it would just kill your startup perf. Users would have to download an entire Ruby VM every time they hit your site, wouldn't they? Maybe I'm just a luddite, but spending network resources downloading a garbage collector written in JS only so that I can run it in JS... which natively supports GC just seems really gross to me. Don't get me wrong, I think Emscripten is very very cool. It just feels like a strange fit for applications written in a language whose semantics aren't that far from JS.

azakai 12y ago
I see your point, but don't think it is quite as bad as that. For one thing, it would be cached etc., so it is about as bad as every site on the web using jQuery (that is, not great, but not horrible either). Yes, it seems ironic to download a GC written in JS, when JS can do GC. But JS can only do SOME types of GC. For example, it lacks destructor callbacks, which things like Lua require. Some other language might need weakrefs which JS also lacks. So it is not quite that unreasonable to download a GC, as you can get the right semantics you want. But I do agree it gets less clear when the semantics are very close to JS. I'm not sure if Ruby is close enough, though (CoffeeScript certainly is).
- rapind 12y ago
  While convoluted, I believe this results in some pretty fast js. mruby -> llvm -> emscripten -> asm.js See: http://vimeo.com/70673036 http://vimeo.com/70673036

mraleph 12y ago

> That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). You are comparing different ratios: munificent was comparing against JS and your "2 times" prediction is against native performance of the compiled VM. > there are interesting results even there, see pypy.js. Yes, the most interesting result is that you have to warm up pypy.js with a blow torch, otherwise performance is abysmal. > I think that approach could work for Dart as well. Have you seen people complaining about size of dart2js output? Can you imagine how big emscripten output would be? I have been arguing that dart2js could have been using hand-written JIT compiler on the client side, but the startup performance compared to AOT would really be a big deal. I think a combination of AOT and JIT would be the best, but sadly it is also true that JavaScript lacks right level of abstraction. It is either too low-level (typed arrays, hand rolled allocations etc) or too high-level.