6 ms·

This is cool and I am glad it exists as someone who works with nodejs often, but if you’re doing heavy server side computations where serious parallelization is

This is cool and I am glad it exists as someone who works with nodejs often, but if you’re doing heavy server side computations where serious parallelization is actually important, I’m a little skeptical that investing in having those computations in JS is likely to be a reasonable choice in many cases outside of small hobby projects. I could be wrong, but I think the performance compared to other alternatives also using parallelization via the GPU would be very unfavorable and you also wouldn’t have rich complementary libraries for this as a result of the low performance ceiling for JS in this domain.

sillysaurusx 6y ago
Those criticisms haven't really been true of JS for years. Google has invested many dozens of millions to make JS fast. And GPU acceleration is largely unrelated to the particular language that happens to drive the GPU. If the critique is "static typing good, JS bad" then that's a fair argument. But personally I'm excited to have something akin to a scripting language for a GPU.
- 0xfffafaCrash 6y ago
  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)
- shakna 6y ago
  > But personally I'm excited to have something akin to a scripting language for a GPU. There's a few of these already, depending what you mean by scripting language. You have Numba for Python [0], with official backing from nVidia, and turbo.js [1] for JS. Alea for F# might classify, too, thanks to its REPL, and how quick you can get off the ground. [2] [0] https://developer.nvidia.com/how-to-cuda-python https://developer.nvidia.com/how-to-cuda-python [1] https://turbo.js.org/ https://turbo.js.org/ [2] https://developer.nvidia.com/alea-gpu https://developer.nvidia.com/alea-gpu
  - thom 6y ago
    Neanderthal also exists, giving you REPL based GPU programming in Clojure: https://github.com/uncomplicate/neanderthal https://github.com/uncomplicate/neanderthal
  - deleted 6y ago
    [deleted]
- fulafel 6y ago
  Other high level languages exist already that are oriented to gpu friendly data models. eg Futhark, Halide. Basic gpu kernels are easy to write in low level gpu languages too so a hll that covers only that case is not very useful.
- noobermin 6y ago
  >But personally I'm excited to have something akin to a scripting language for a GPU. This has existed elsewhere for a while. For example, see cupy[0]. [0] https://github.com/cupy/cupy https://github.com/cupy/cupy
noobermin 6y ago
The performance isn't an issue, but the language might be. I'm still waiting for a javascript derivative/platform that has operator overloading so we can finally see a numpy like library for js. Once that hits I'll pick up js and never look back. Python is fine but I always loved javascript's functional lite style over python's imperative style, but the language itself doesn't really allow for a library that would make computational science feasible in javascript.

sillysaurusx 6y ago

Those criticisms haven't really been true of JS for years. Google has invested many dozens of millions to make JS fast. And GPU acceleration is largely unrelated to the particular language that happens to drive the GPU. If the critique is "static typing good, JS bad" then that's a fair argument. But personally I'm excited to have something akin to a scripting language for a GPU.

0xfffafaCrash 6y ago
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)
shakna 6y ago
> But personally I'm excited to have something akin to a scripting language for a GPU. There's a few of these already, depending what you mean by scripting language. You have Numba for Python [0], with official backing from nVidia, and turbo.js [1] for JS. Alea for F# might classify, too, thanks to its REPL, and how quick you can get off the ground. [2] [0] https://developer.nvidia.com/how-to-cuda-python https://developer.nvidia.com/how-to-cuda-python [1] https://turbo.js.org/ https://turbo.js.org/ [2] https://developer.nvidia.com/alea-gpu https://developer.nvidia.com/alea-gpu
- thom 6y ago
  Neanderthal also exists, giving you REPL based GPU programming in Clojure: https://github.com/uncomplicate/neanderthal https://github.com/uncomplicate/neanderthal
- deleted 6y ago
  [deleted]
fulafel 6y ago
Other high level languages exist already that are oriented to gpu friendly data models. eg Futhark, Halide. Basic gpu kernels are easy to write in low level gpu languages too so a hll that covers only that case is not very useful.
noobermin 6y ago
>But personally I'm excited to have something akin to a scripting language for a GPU. This has existed elsewhere for a while. For example, see cupy[0]. [0] https://github.com/cupy/cupy https://github.com/cupy/cupy

noobermin 6y ago

The performance isn't an issue, but the language might be. I'm still waiting for a javascript derivative/platform that has operator overloading so we can finally see a numpy like library for js. Once that hits I'll pick up js and never look back. Python is fine but I always loved javascript's functional lite style over python's imperative style, but the language itself doesn't really allow for a library that would make computational science feasible in javascript.