High-Performance GPU Computing in the Julia Programming Language (2017)
devblogs.nvidia.com
High-Performance GPU Computing in the Julia Programming Language (2017)
1–10 of 58 posts
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#2Just pointing out that this is an article from 2017 and was discussed before on hn https://news.ycombinator.com/item?id=15564639
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#3I always glad to see topics about Julia. I think it has good potential to replace several other languages with one better language.
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#4Julia 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.
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#5Julia 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 updates) to non-existent. For example, lots of tutorials will often link to broken links to official documentation, links that one time were thought to be working but now aren't.
And so on...
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#6Julia 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…
Sounds like road to maturity problems. The key is to think, "are these issues solvable?" if they are it's only a matter of time. The next thing is when those things are fixed, does Julia offer something above and beyond what Python and R can do (easily). If the answer is for you, thne it's a matter of whether Julia provides value now for you.
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#7Julia 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…
Your 1st, 2nd and 4th points seem to be fundamentally the same, which is compile time latency making interactive use slow. That's definitely a problem for a language trying to solve the two language problem of having high interactivity and high performance at the same time, and the compiler team [1] are now focusing on that issue on versions 1.4 and beyond hopefully it will get to the point where it isn't a problem anymore.
Documentation is always a problem (especially for smaller packages), but I don't feel I had more issue with Julia than other languages (with a few exceptions, some languages managed to have an exceptional culture in terms of great documentation). Most of the issues were due to the fact that Julia just got to 1.0 a year ago, and the breaking changes made so most documentation became outdated, but this will only become less of a problem since the language became stable.
Julia has one of the best REPL of any language I used, and thankfully I didn't meet with any problems with it. Might be a good idea to create an issue on the github.
[1] https://discourse.julialang.org/t/compiler-work-priorities/1...
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#8Why 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.
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#9Why 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.
Re: High-Performance GPU Computing in the Julia Programming Language (2017)
#10Why 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