Is anyone from the node team interested in getting node v4 to work on nVIDIA's CUDA?
There is an existing project, but looks out of date and it doesn't work on latest node.
https://github.com/kashif/node-cuda
All of the errors are v8 ones, so I have no idea how to update it.
( current output http://pastebin.com/pZ5x0n1j )
Would be interesting to have js running on a powerful GPU...
AntouanK
All 8 comments
Sounds reasonable if we could get it to work like any other platform.
cc.. @indutny maybe?
Fishrock123
on 12 Sep 2015
@Fishrock123 this is not about running JS on CUDA, but rather about providing the bindings for it.
indutny
on 13 Sep 2015
@indutny Are you sure?
Would be interesting to have js running on a powerful GPU...
I think the aforementioned module may be just bindings though?
Fishrock123
on 13 Sep 2015
Yeah, exactly... Running JS on CUDA sounds like a too big project :)
indutny
on 13 Sep 2015
@indutny what's the difference exactly? If you "provide the bindings", does it mean that V8 will run on CUDA? So on the GPU?
In any case, there's a lot of computational power on GPUs, so it would be a worthwhile project I guess.
AntouanK
on 13 Sep 2015
If you "provide the bindings", does it mean that V8 will run on CUDA? So on the GPU?
No, it doesn't. I'm going to close this, there isn't anything actionable here.
bnoordhuis
on 13 Sep 2015
In any case, there's a lot of computational power on GPUs, so it would be a worthwhile project I guess.
That's not _exactly_ how it works.
ChALkeR
on 13 Sep 2015
I just want to clarify a few things about what CUDA, and alternatives like OpenCL, actually _do_.
GPUs are not inherently _more_ powerful than CPUs, they are _different_. They focus on massive parallelism for the purpose of high performance shader operations. Individual pixels can have their result computed in parallel to other pixels on the screen. That _difference_ happens to be something that can sometimes be applied to other things like machine learning. Because of this, various technologies emerged to do more general, non-graphics-oriented computing on the GPU.
Imperative-style code, which makes up the vast majority of the code in a typical app, is completely unsuitable for the parallelism you get from GPU computing. V8 itself can not run on CUDA, and it wouldn't even make sense for it to. Only code that can be logically divided in a way that makes it easily distributable can gain from GPU computation. It's pretty much the same as offloading computation to something like Hadoop or Storm. You need a discrete segment of code and data that can be operated on without any side effects between the point of deploying the code and data to compute and the point the job completes. Many JavaScript features, especially lexical scope, make this sort of thing extremely difficult in the best of cases and completely impossible in the others.
Qard
on 14 Sep 2015
Related issues
willnwhite
路
3Comments
srl295
路
3Comments
fanjunzhi
路
3Comments
sandeepks1
路
3Comments
Icemic
路
3Comments
Most helpful comment
I just want to clarify a few things about what CUDA, and alternatives like OpenCL, actually _do_.
GPUs are not inherently _more_ powerful than CPUs, they are _different_. They focus on massive parallelism for the purpose of high performance shader operations. Individual pixels can have their result computed in parallel to other pixels on the screen. That _difference_ happens to be something that can sometimes be applied to other things like machine learning. Because of this, various technologies emerged to do more general, non-graphics-oriented computing on the GPU.
Imperative-style code, which makes up the vast majority of the code in a typical app, is completely unsuitable for the parallelism you get from GPU computing. V8 itself can not run on CUDA, and it wouldn't even make sense for it to. Only code that can be logically divided in a way that makes it easily distributable can gain from GPU computation. It's pretty much the same as offloading computation to something like Hadoop or Storm. You need a discrete segment of code and data that can be operated on without any side effects between the point of deploying the code and data to compute and the point the job completes. Many JavaScript features, especially lexical scope, make this sort of thing extremely difficult in the best of cases and completely impossible in the others.