We do HPC at Graphistry with node because of its low overhead ability to script async over binary buffers (which go straight to cuda/opencl/WebGL) and many general+async app code libs for the 99% case. The result is faster than the native equivs - generally by 10-100x, including multicore. So I'd take that hesitation w a grain of salt.
JS's ability to juggle "Fortran-like" code and scripted app code is pretty unappreciated. Granted, we are slowly adding PyGDF support (google GoAi) to get to GB workloads in real-time, but were fine up to that. I'm not sure if we could have done it in Ruby, may be could have done it in Python. Vulkan adds even more async support, which is the type of thing we could certainly use.
So... Yeah, takes a team that gets how to write HPC code to get HPC code, and JS can be a good choice here when there is a lot of app code to use the HPC.
We'd love for WebGL to get close to GPU compute parity, but even webgl2 feels more like 1998 or 2008 than 2018. The problem there isn't the JS side.
JS's ability to juggle "Fortran-like" code and scripted app code is pretty unappreciated. Granted, we are slowly adding PyGDF support (google GoAi) to get to GB workloads in real-time, but were fine up to that. I'm not sure if we could have done it in Ruby, may be could have done it in Python. Vulkan adds even more async support, which is the type of thing we could certainly use.
So... Yeah, takes a team that gets how to write HPC code to get HPC code, and JS can be a good choice here when there is a lot of app code to use the HPC.
We'd love for WebGL to get close to GPU compute parity, but even webgl2 feels more like 1998 or 2008 than 2018. The problem there isn't the JS side.