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.

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)`.