3 ms·

The thing I finally realized after being big on parallel algorithms and such since first learning about them in university is that, honestly, most things don't

The thing I finally realized after being big on parallel algorithms and such since first learning about them in university is that, honestly, most things don't need to be cleverly parallel. The majority of tasks are "embarrassingly parallel" as they say. Which is just to mean, there are a lot of standalone tasks that need to be done. For example, any web server is embarrassingly parallel. You don't need to be clever, you just need to have the processing power available to handle them.

WrtCdEvrydy 7y ago
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 graphics) can get a small upgrade out of moving some data into a more parallel format.
- 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)`.

WrtCdEvrydy 7y ago

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 graphics) can get a small upgrade out of moving some data into a more parallel format.

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