11–20 of 58 posts
Why this infrastructure is so tightly coupled with CUDA? CUDA is very specific and closed APIs for NVidia hardware only. Programming languages should focus on more general primitives that might work on NVidia or TPUs or something else. PyTorch also has CUDA all over in its APIs and its frustrating to see such tight binding with closed one company API. Also take a look at OpenCL.
Why this infrastructure is so tightly coupled with CUDA? CUDA is very specific and closed APIs for NVidia hardware only. Programming languages should focus on more general primitives that might work on NVidia or TPUs or something else. PyTorch also has CUDA all over in its APIs and its frustrating to see such tight binding with closed one company API. Also take a look at OpenCL.
It's because CUDA performs better. It's not nice, but it's the situation we're living in. Particularly AMD support and performance are lot.
Earlier quoted context omitted.
It's because CUDA performs better. It's not nice, but it's the situation we're living in. Particularly AMD support and performance are lot.
Sure, I don't mind CUDA backend as first class citizen. I'm talking about having my code sprinkled with word "cuda" all over. Why can't I write my code that is bit more abstract and potentially compilable to different backends? That is, think about the primitives instead of tightly getting married to cuda forever. AMD performance might not be good today but how about 10 years later? How about using TPUs instead? or F…
Why this infrastructure is so tightly coupled with CUDA? CUDA is very specific and closed APIs for NVidia hardware only. Programming languages should focus on more general primitives that might work on NVidia or TPUs or something else. PyTorch also has CUDA all over in its APIs and its frustrating to see such tight binding with closed one company API. Also take a look at OpenCL.
there are specific benefits of cuda over opencl: see https://arxiv.org/vc/arxiv/papers/1005/1005.2581v1.pdf
Julia is one of my fav languages. For numerical computing, neither python + numpy, nor matlab come even close. The interop is nuts. To call, say numpy fft, you just do using PyCall np = pyimport("numpy") res = np.fft.fft(rand(ComplexF64, 10)) No casting back and forth. This is a toy example, julia ofc has fftw bindings. Interop with C++, MATLAB, Mathematica etc is similarly simple.
In theory Julia is supposed to be fantastic. In practice, things either don't exist, or are poorly implemented: Plotting simple things take 30 seconds. And that's if you don't count the time it takes to `] add Plots`, especially on Windows! And the REPL is broken. And the editor is slow and annoying (Juno or vscode). And documentation ranges from poor (no examples, buggy between platforms, broken links due to version…
Earlier quoted context omitted.
there are specific benefits of cuda over opencl: see https://arxiv.org/vc/arxiv/papers/1005/1005.2581v1.pdf
Yes, but is cuda going to keep its edge 10 years down the line? Do I want to hardcode my algorithms so tightly with today's cuda APIs? Can there be better more generic primitives that are agnostic of propitiatory cuda APIs but would support it as backend without too much perf hit?
Earlier quoted context omitted.
In theory Julia is supposed to be fantastic. In practice, things either don't exist, or are poorly implemented: Plotting simple things take 30 seconds. And that's if you don't count the time it takes to `] add Plots`, especially on Windows! And the REPL is broken. And the editor is slow and annoying (Juno or vscode). And documentation ranges from poor (no examples, buggy between platforms, broken links due to version…
Similar experience here. Did a comparison of a bunch of statistical tools (R, Matlab, Julia, Python, etc.) on small-ish datasets. Used the latest versions in all cases, in Windows 10. All but Julia ran the regressions in Sure, the usual answer is "well its an initial cost, its faster after that" but not all my code would otherwise take days to run. As long as "using CSV" takes 10 seconds, I'm out.
How exactly CUDA is "democratizing" anything, if it's tied to Nvidia? Vulkan backend would make more sense for that purpose.
Why this infrastructure is so tightly coupled with CUDA? CUDA is very specific and closed APIs for NVidia hardware only. Programming languages should focus on more general primitives that might work on NVidia or TPUs or something else. PyTorch also has CUDA all over in its APIs and its frustrating to see such tight binding with closed one company API. Also take a look at OpenCL.
Why this infrastructure is so tightly coupled with CUDA? CUDA is very specific and closed APIs for NVidia hardware only. Programming languages should focus on more general primitives that might work on NVidia or TPUs or something else. PyTorch also has CUDA all over in its APIs and its frustrating to see such tight binding with closed one company API. Also take a look at OpenCL.
It's because CUDA performs better. It's not nice, but it's the situation we're living in. Particularly AMD support and performance are lot.