5 ms·

Javascript is now fast in the sense that V8 is good enough at the things you are likely to do in the browser or in a typical node server. The very example in th

Javascript is now fast in the sense that V8 is good enough at the things you are likely to do in the browser or in a typical node server. The very example in this link of how a matrix of random numbers is to be generated is an absolute joke compared to how this would be achieved in lower level languages. Javascript’s lack of static typing doesn’t just affect DX but what performance enhancements can be made. You don’t have direct access to memory and V8’s optimizations just aren’t THAT helpful for this sort of thing. This is a large part of the appeal of WebAssembly in the browser context. Even asm.js, impressive as it is/was, doesn’t really compare favorably and what you see here is clearly nothing like asmjs. I have a lot of love for JS and there are many domains it does well in but unless you show numbers that prove otherwise, I’m quite sure you are totally wrong here.

sillysaurusx 6y ago
You don’t have direct access to memory and V8’s optimizations just aren’t THAT helpful for this sort of thing. You do: ArrayBuffer works great. I have a lot of love for JS and there are many domains it does well in but unless you show numbers that prove otherwise, I’m quite sure you are totally wrong here. I speak from experience :) Here's a demo of Javascript doing what it's unsuited for: buttery-smooth 60FPS on iOS https://twitter.com/theshawwn/status/1222280670908600321 https://twitter.com/theshawwn/status/1222280670908600321 Voice recognition: https://twitter.com/theshawwn/status/1151613837264732167 https://twitter.com/theshawwn/status/1151613837264732167 It's fair to say that writing a matrix multiply in pure JS might not be the best way to deploy your production code. But curing that is a matter of "run profiler, see clear hotspot, optimize hotspot." Especially now that you have so many options for dropping down to a lower-level stack. JS is merely the wrapper, in many cases.
- 0xfffafaCrash 6y ago
  JS is really fast assuming you don’t do anything in JS is not a convincing argument for this. My point is that if you are using JS as a wrapper for a big black box of gpu computations that are close to the metal then you are not really using JS in any meaningful sense and can wrap anything else that has a much better library ecosystem and performance qualities for anything that you’re not just getting the gpu to crank out in a server context (which is implied by nodejs). There’s the speed of generating inputs, the speed of transforming and passing data at the input/output boundaries, and the ability to conveniently and performantly work with data in memory natively (i.e. while not outsourcing the computations elsewhere) that matters here. Is JS a great choice for any of these things? Most importantly, the last thing? This library isn’t using ArrayBuffers for setting up all data or working on the data in JS so even if they work great for performance it seems totally irrelevant and let’s be honest, if it were working with ArrayBuffers directly you would be so far away from usual JS and any convenience JS offers, you might as well not be writing JS.
  - spion 6y ago
    > if it were working with ArrayBuffers directly you would be so far away from usual JS and any convenience JS offers, you might as well not be writing JS Or you might as well do, since it makes interop generally easy. In the library space I no longer have to worry where my web code begins, where my mobile code ends or where my backend code sits. All libraries can be used anywhere I feel necessary with zero interop pain. The same arugment was applied to writing C in the late 70s (vs writing several types of assemblies for various types of hardware at the time)
- dkersten 6y ago
  I always wonder when I see these demos: what is it like in a real world workload? I remember some years ago everyone was going nuts over how WebGL was able to render a detailed model in the browser, native games are dead! Except it was a single non-animated 3D model, in a simple or non-existent background. real games had many animated models, in complex environments, with complex interaction, physics, AI, audio and gameplay logic. Ever since that comparison, I think, yeah, those demos look cool and indeed silky smooth, but most are a single simple thing. Real workloads tend to be much more complex: how does it fare with those? (Of course if the vast majority of the processing time is in the GPU, then it really doesn’t matter what language, fast or slow, you use to control or feed it.)
  - untog 6y ago
    One recent innovation that (IMO) hasn’t got much attention is OffscreenCanvas. Even with WebGL, JS has been sorely limited by the fact that it’s single threaded. OffscreenCanvas lets you pass a drawing context off to a separate thread, or multiple contexts to multiple threads even. There’s a whole lot of potential there that I haven’t seen tapped yet (but I’ll admit I’m not very clued into the kind of scenes you’d see making the most of this). As ever, browser support matters. Chrome and Firefox: yes. Safari? No. https://bugs.webkit.org/show_bug.cgi?id=183720 https://bugs.webkit.org/show_bug.cgi?id=183720
    - rikroots 6y ago
      I'm excited by the prospect of OffscreenCanvas, and yet at the same time I'm not convinced that it's going to be massively useful for my canvas library[1]. The one area where it could have a big impact (I think) would be to run the OC in a web worker alongside the bulk of the library's code, leaving the main thread to deal with final canvas display, user interactions, etc. But to implement that I'd need to recode the entire library from scratch. At the moment I generate additional canvas elements in the code (in a pool, for reuse) and use them without adding them to the DOM. I'm happy with the resulting frame rates, and the flexibility the system gives me for creating responsive, accessible canvas elements in the web page. This is all done using a simple 2d context (even the bendy images code[2] is 2d, rendered in the main thread). I've avoided WebGL and the whole GPU acceleration thing because shaders scare me more than quaternions! [1] - Scrawl-canvas - https://scrawl.rikweb.org.uk/ https://scrawl.rikweb.org.uk/ [2] - Bendy images interactive demo - https://scrawl.rikweb.org.uk/demo/canvas-024.html https://scrawl.rikweb.org.uk/demo/canvas-024.html
- bananaface 6y ago
  GPU-accelerated Javascript is not the same as a Javascript binding to a C library. Come now.
underdeserver 6y ago
About the static typing point, I believe the JIT compiler knows what types you're calling your function with, compiles a version for them, and checks types before calling the compiled function. So in the case of matrix multiplication, it knows that it's a double-vector of ints and runs the whole thing compiled. So it should, theoretically, be just as fast as a compiled language.
- setzer22 6y ago
  Genuine curiosity: How can it check the types at the call side quickly? Let's say I have a function that averages an array of floats. Does the JIT have to check each of the array's inputs to have the right type? That looks like it could become a serious overhead.
  - pjmlp 6y ago
    Usually how it works is it does that a couple of times, while gathering some kind of stats. If those stats prove that it is always an array of floats, then machine code gets generated for an array of floats, with a trap handler for when the code fails. The trap handler, if called, will throw away the code and restart the analysis. So if you are nice for the compiler and keep your types regular, the machine code will not be thrown away and there are no speed bumps.
    - setzer22 6y ago
      (Answering a bit late, sorry I missed your reply!) I still don't get it... How do you know when to activate the trap handler if you're not checking every time? It's not enough to wait for an error condition (e.g. an invalid pointer). If it's an array of integers, and I sneak in a string in there, what's stopping the JITed version from treating that pointer as an integer?

sillysaurusx 6y ago

You don’t have direct access to memory and V8’s optimizations just aren’t THAT helpful for this sort of thing. You do: ArrayBuffer works great. I have a lot of love for JS and there are many domains it does well in but unless you show numbers that prove otherwise, I’m quite sure you are totally wrong here. I speak from experience :) Here's a demo of Javascript doing what it's unsuited for: buttery-smooth 60FPS on iOS https://twitter.com/theshawwn/status/1222280670908600321 https://twitter.com/theshawwn/status/1222280670908600321 Voice recognition: https://twitter.com/theshawwn/status/1151613837264732167 https://twitter.com/theshawwn/status/1151613837264732167 It's fair to say that writing a matrix multiply in pure JS might not be the best way to deploy your production code. But curing that is a matter of "run profiler, see clear hotspot, optimize hotspot." Especially now that you have so many options for dropping down to a lower-level stack. JS is merely the wrapper, in many cases.

0xfffafaCrash 6y ago
JS is really fast assuming you don’t do anything in JS is not a convincing argument for this. My point is that if you are using JS as a wrapper for a big black box of gpu computations that are close to the metal then you are not really using JS in any meaningful sense and can wrap anything else that has a much better library ecosystem and performance qualities for anything that you’re not just getting the gpu to crank out in a server context (which is implied by nodejs). There’s the speed of generating inputs, the speed of transforming and passing data at the input/output boundaries, and the ability to conveniently and performantly work with data in memory natively (i.e. while not outsourcing the computations elsewhere) that matters here. Is JS a great choice for any of these things? Most importantly, the last thing? This library isn’t using ArrayBuffers for setting up all data or working on the data in JS so even if they work great for performance it seems totally irrelevant and let’s be honest, if it were working with ArrayBuffers directly you would be so far away from usual JS and any convenience JS offers, you might as well not be writing JS.
- spion 6y ago
  > if it were working with ArrayBuffers directly you would be so far away from usual JS and any convenience JS offers, you might as well not be writing JS Or you might as well do, since it makes interop generally easy. In the library space I no longer have to worry where my web code begins, where my mobile code ends or where my backend code sits. All libraries can be used anywhere I feel necessary with zero interop pain. The same arugment was applied to writing C in the late 70s (vs writing several types of assemblies for various types of hardware at the time)
dkersten 6y ago
I always wonder when I see these demos: what is it like in a real world workload? I remember some years ago everyone was going nuts over how WebGL was able to render a detailed model in the browser, native games are dead! Except it was a single non-animated 3D model, in a simple or non-existent background. real games had many animated models, in complex environments, with complex interaction, physics, AI, audio and gameplay logic. Ever since that comparison, I think, yeah, those demos look cool and indeed silky smooth, but most are a single simple thing. Real workloads tend to be much more complex: how does it fare with those? (Of course if the vast majority of the processing time is in the GPU, then it really doesn’t matter what language, fast or slow, you use to control or feed it.)
- untog 6y ago
  One recent innovation that (IMO) hasn’t got much attention is OffscreenCanvas. Even with WebGL, JS has been sorely limited by the fact that it’s single threaded. OffscreenCanvas lets you pass a drawing context off to a separate thread, or multiple contexts to multiple threads even. There’s a whole lot of potential there that I haven’t seen tapped yet (but I’ll admit I’m not very clued into the kind of scenes you’d see making the most of this). As ever, browser support matters. Chrome and Firefox: yes. Safari? No. https://bugs.webkit.org/show_bug.cgi?id=183720 https://bugs.webkit.org/show_bug.cgi?id=183720
  - rikroots 6y ago
    I'm excited by the prospect of OffscreenCanvas, and yet at the same time I'm not convinced that it's going to be massively useful for my canvas library[1]. The one area where it could have a big impact (I think) would be to run the OC in a web worker alongside the bulk of the library's code, leaving the main thread to deal with final canvas display, user interactions, etc. But to implement that I'd need to recode the entire library from scratch. At the moment I generate additional canvas elements in the code (in a pool, for reuse) and use them without adding them to the DOM. I'm happy with the resulting frame rates, and the flexibility the system gives me for creating responsive, accessible canvas elements in the web page. This is all done using a simple 2d context (even the bendy images code[2] is 2d, rendered in the main thread). I've avoided WebGL and the whole GPU acceleration thing because shaders scare me more than quaternions! [1] - Scrawl-canvas - https://scrawl.rikweb.org.uk/ https://scrawl.rikweb.org.uk/ [2] - Bendy images interactive demo - https://scrawl.rikweb.org.uk/demo/canvas-024.html https://scrawl.rikweb.org.uk/demo/canvas-024.html
bananaface 6y ago
GPU-accelerated Javascript is not the same as a Javascript binding to a C library. Come now.

underdeserver 6y ago

About the static typing point, I believe the JIT compiler knows what types you're calling your function with, compiles a version for them, and checks types before calling the compiled function. So in the case of matrix multiplication, it knows that it's a double-vector of ints and runs the whole thing compiled. So it should, theoretically, be just as fast as a compiled language.

setzer22 6y ago
Genuine curiosity: How can it check the types at the call side quickly? Let's say I have a function that averages an array of floats. Does the JIT have to check each of the array's inputs to have the right type? That looks like it could become a serious overhead.
- pjmlp 6y ago
  Usually how it works is it does that a couple of times, while gathering some kind of stats. If those stats prove that it is always an array of floats, then machine code gets generated for an array of floats, with a trap handler for when the code fails. The trap handler, if called, will throw away the code and restart the analysis. So if you are nice for the compiler and keep your types regular, the machine code will not be thrown away and there are no speed bumps.
  - setzer22 6y ago
    (Answering a bit late, sorry I missed your reply!) I still don't get it... How do you know when to activate the trap handler if you're not checking every time? It's not enough to wait for an error condition (e.g. an invalid pointer). If it's an array of integers, and I sneak in a string in there, what's stopping the JITed version from treating that pointer as an integer?