I did see that, yeah - very entertaining and insightful. We've actually almost seen a "Metal"-like effect in emscripten already. We used to have a dlmalloc benchmark that was meant to measure the speed of a memory allocator implementing malloc. The benchmark allocated and freed lots of stuff. But once emscripten got to a point where its output was fairly optimized, it was significantly faster than native! The reason was apparently that in the native build, dlmalloc will call sbrk() or another syscall to actually get or free memory from the OS, while in emscripten sbrk() and other syscalls are merely JS calls - no syscall overhead, and they can even be inlined by the VM, etc.
Of course this isn't apples to apples because the sbrk() in emscripten works on its own memory space, not the system's, so dlmalloc's syscalls actually do more (hence I removed the benchmark). But in principle, if the entire system was using asm.js - as in Metal in that talk - then it could work on global system memory while also avoiding syscall overhead, allowing the VM to inline, etc. etc., i.e., achieving a speedup by relying on software sandboxing instead of hardware. - Alon On Tue, Apr 22, 2014 at 11:38 AM, Dirk Krause <[email protected]> wrote: > Hi, > > interesting take on JS here: > https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript > > You might know this talk already, so feel free to ignore. :-) > > Best, > Dirk > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
