Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-Performance GPU Computing in the Julia Programming Language (2017)

devblogs.nvidia.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#31

Post by Athas »

shmerl wrote: post #28
rrss wrote: post #25

Earlier quoted context omitted.

That sentence explains perfectly well what it means by democratizing, and how is independent of the platform being tied to nvidia.

Can you elaborate please? I was under the impression that CUDA is tied to Nvidia, unless you mean there are now working shims for other GPUs.

CUDA is ultimately an API. AMD even has a converter for transforming CUDA cuda to something more portable[0].

While it would be better in a democratic sense for GPUs to be accessed using a fully free API, having an easily usable proprietary API is still more democratic than a difficult-to-use API (especially when, as here, the easy-to-use layer is actually fully free, and can perhaps be retargeted to fully free lower layers later).

[0]: https://gpuopen.com/compute-product/hip-convert-cuda-to-port...

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#32

Post by shmerl »

Athas wrote: post #31
shmerl wrote: post #28

Earlier quoted context omitted.

Can you elaborate please? I was under the impression that CUDA is tied to Nvidia, unless you mean there are now working shims for other GPUs.

CUDA is ultimately an API. AMD even has a converter for transforming CUDA cuda to something more portable[0]. While it would be better in a democratic sense for GPUs to be accessed using a fully free API, having an easily usable proprietary API is still more democratic than a difficult-to-use API (especially when, as here, the easy-to-use layer is actually fully free, and can perhaps be retargeted to fully free lower…

It still looks like porting idea, not like a shim that makes CUDA run on AMD. So I'd say CUDA is still locked to Nvidia. AMD are trying to ease up the transition to portable options - that's surely good, but it's not a full fledged lock-in unlocking.

I'd say, Nvidia are being hypocritical here, with this whole "democratizing" claim. They are direct beneficiaries of the lock-in they are advancing with it.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#33

Post by maleadt »

Author here, happy to answer any questions! We've been developing and maintaining this toolchain for a while now, so the relevant packages (CUDAnative.jl for kernel programming, CuArrays.jl for a GPU array abstraction) are much more mature. Our focus has recently been on implementing a common base of array operations that can be used across devices (GPU, CPU, etc), so that users can develop using the base CPU array type, quickly benefit from a GPU by switching to CuArrays, only to rely on specific CUDA-specific functionality from CuArrays/CUDAnative when they need custom functionality.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#34

Post by maleadt »

sytelus wrote: post #8

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.

Our view is that to get performance out of a system (here CUDA), it's better not to start abstracting it right away. So we have CUDAnative.jl and CUDAdrv.jl for fairly low-level CUDA programming, albeit in a high-level language. However, with CuArrays.jl we implement the Julia array interface for CUDA GPUs. That means you can write array code for one platform (CPU using Base.Array) and start using hardware accelerators by just switching the array type (CUDA GPU using CuArray). Of course, real-life applications might still need to use CUDA specific functionality for one reason or another, but at least you can get most of the way without platform-specific programming.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#35

Post by stabbles »

siproprio wrote: post #5
adamnemecek wrote: post #4

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…

> And the REPL is broken.

You should really back up that claim, because in my experience it's absolutely great

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#36

Post by alpaca128 »

mirekrusin wrote: post #21
zzleeper wrote: post #15

Earlier quoted context omitted.

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.

Low latency development flow is slightly different in Julia. You should startup you process and reload updated code with revise. You won't have this problem. Obviously compilation performance improvements will be very welcome when they arrive but it's not a deal breaker because of this revise based flow.

I just tried Revise. Yes, it's very nice and usable for programs without dependencies, but including a Plots example program that normally takes Julia 1 minute and 20 seconds took 19 minutes. There's only so much time I'm willing to wait for that.

Currently I'm mainly using Jupyter Notebook and that is by far the best experience I've had(it's like Revise but much, much faster). But to me it seems Jupyter Notebook wasn't designed with code outside of a single isolated file in mind, which makes it cumbersome in some cases.

I like the language, but I hope the situation improves soon. Editing code in the browser is not that much fun.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#37

Post by socialdemocrat »

siproprio wrote: post #5
adamnemecek wrote: post #4

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…

Yes plotting in Julia is slow upon first invocation due to the JIT. Annoys me too, but to say the REPL is broken is profoundly puzzling to me. It is the best REPL I have ever used. It beats anything I have used for Python, Ruby, JavaScript, Lua etc.

Also your documentation issue is also strange. Yes certain things don’t exist but I would say the Julia docs is quite well made. In particular if you use the REPL documentation I find it much better than Python. Tends to be quite nice examples, color coding etc.

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#38

Post by mirekrusin »

alpaca128 wrote: post #36
mirekrusin wrote: post #21

Earlier quoted context omitted.

Low latency development flow is slightly different in Julia. You should startup you process and reload updated code with revise. You won't have this problem. Obviously compilation performance improvements will be very welcome when they arrive but it's not a deal breaker because of this revise based flow.

I just tried Revise. Yes, it's very nice and usable for programs without dependencies, but including a Plots example program that normally takes Julia 1 minute and 20 seconds took 19 minutes. There's only so much time I'm willing to wait for that. Currently I'm mainly using Jupyter Notebook and that is by far the best experience I've had(it's like Revise but much, much faster). But to me it seems Jupyter Notebook was…

That sounds crazy long, maybe something is not right, have you tried reaching at https://discourse.julialang.org for help for example?

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#39

Post by [deleted] »

shmerl wrote: post #18

> The performance possibilities of GPUs can be democratized by providing more high-level tools that are easy to use by a large community of applied mathematicians and machine learning programmers. How exactly CUDA is "democratizing" anything, if it's tied to Nvidia? Vulkan backend would make more sense for that purpose.

[deleted]

Re: High-Performance GPU Computing in the Julia Programming Language (2017)

#40

Post by llukas »

Athas wrote: post #30
darknoon wrote: post #9

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.

Are you certain that the story is as simple as "CUDA performs better"? It's common folklore, but I have seen little evidence. The only situations I know of when CUDA performs better is when CUDA-specific features are used (if they are relevant for whatever problem is at hand). Also, CUDA libraries (like cuBLAS or cuFFT) tend to be more efficient than their OpenCL equivalent, which is likely because much more work has…

Did you compare the performance of nvrtc vs offline nvcc compiler?
Post reply on HN