3 ms·

Yeah, to be honest, parallelism is great for number crunching. I used GPU.js for some frontend crunching and it turns out even a builtin GPU (integrated graphi

• onion2k 7y ago
  I've only looked at the readme for gpu.js so far but from that I guess it's doing some sort of transformation from the subset of JS it supports in to GLSL, and then running that as a shader in a WebGL context. Presumably there's a not-significant overhead in both starting it up and getting data back from the gpu.js function. Is there a way to "compile" a gpu.js function to remove the translation step? That could be really useful.
  • axel180 7y ago
    Hi! I maintain GPU.js. >I guess it's doing some sort of transformation That is exactly correct. From javascript to an abstract syntax tree, and then to whatever target language we need. In this case GLSL. >Presumably there's a not-significant overhead in both starting it up That has been the goal, we're really careful to measure it with releases. >and getting data back from the gpu.js function That is correct as well, it is about as costly as it would be without GPU.js. However you can enable pipeline on kernels, so they can communicate via textures, which is significantly faster, as we don't need to transfer back to the CPU. >Is there a way to "compile" a gpu.js function to remove the translation step? That could be really useful. It is built into every kernel. You simply call `kernel.toString(...args)`.