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

Julia GPU

notamonadtutorial.com

Post reply on HN
Print view View original

1–10 of 28 posts

Re: Julia GPU

#2

Post by marmaduke »

> From a Python programmer perspective, how does CUDA.jl compare to PyCUDA?

I think the relevant comparison today is with Numba, here's a real world recurrence analysis,

    @cuda.jit
    def _sseij(Y, I, J, O):
        # strides
        sty = cuda.blockDim.x
        sbx = sty * cuda.blockDim.y
        sby = sbx * cuda.gridDim.x
        sbz = sby * cuda.gridDim.y
        # this thread's index
        t = (cuda.threadIdx.x
           + cuda.threadIdx.y * sty
           + cuda.blockIdx.x * sbx
           + cuda.blockIdx.y * sby
           + cuda.blockIdx.z * sbz)
        if t
most of it is index calculation, but super easy

Re: Julia GPU

#3

Post by MayeulC »

I was really confused for a moment, because the article mention CUDA a lot, which is a nvidia-specific API/framework/language. I guess that's mainly to appeal to the CUDA crowd? However, Julia being seemingly based on LLVM, interfacing it with AMD GPUs should be quite doable:

> Much of the initial work focused on developing tools that make it possible to write low-level code in Julia. For example, we developed the LLVM.jl package that gives us access to the LLVM APIs. Recently, our focus has shifted towards generalizing this functionality so that other GPU back-ends, like AMDGPU.jl or oneAPI.jl can benefit from developments to CUDA.jl. Vendor-neutral array operations, for examples, are now implemented in GPUArrays.jl whereas shared compiler functionality now lives in GPUCompiler.jl. That should make it possible to work on several GPU back-ends, even though most of them are maintained by only a single developer.

This is the takeaway to me. First-class access to GPU accelerators using the same syntax, regardless of the vendor :)

Re: Julia GPU

#4

Post by fulafel »

The Nvidia proprietary bit does leave HLLs like Furhark or DSLs like Neanderthal a bit of an advantage. Are there ways of doing portable GPU things with Julia?

Re: Julia GPU

#5

Post by Athas »

I'm not sure I understand the bounds checking example. Can someone shed some light on how CUDA.jl does bounds checking? It's not entirely straightforward to do on a GPU.

Re: Julia GPU

#6

Post by fizixer »

JuliaGPU appears to be a textbook example of 'how to present a bug as a feature'.

"You're a CUDA programmer. Well, why don't you learn it all over again the Julia way, and also unlearn CUDA, so the next time you have to program an nVidia GPU, you don't have a choice but to do it in Julia"

Vendor lock-in FTW.

Re: Julia GPU

#7

Post by eigenspace »

fizixer wrote: post #6

JuliaGPU appears to be a textbook example of 'how to present a bug as a feature'. "You're a CUDA programmer. Well, why don't you learn it all over again the Julia way, and also unlearn CUDA, so the next time you have to program an nVidia GPU, you don't have a choice but to do it in Julia" Vendor lock-in FTW.

Most of the julia GPU stuff is being made vendor agnostic via moving infrastructure from CUDA.jl to CPUCompiler.jl. The package AMDGPU.jl is coming along very well and will be plug-able with all this stuff.

https://github.com/JuliaGPU/GPUCompiler.jl

https://github.com/JuliaGPU/AMDGPU.jl

Re: Julia GPU

#8

Post by fizixer »

eigenspace wrote: post #7
fizixer wrote: post #6

JuliaGPU appears to be a textbook example of 'how to present a bug as a feature'. "You're a CUDA programmer. Well, why don't you learn it all over again the Julia way, and also unlearn CUDA, so the next time you have to program an nVidia GPU, you don't have a choice but to do it in Julia" Vendor lock-in FTW.

Most of the julia GPU stuff is being made vendor agnostic via moving infrastructure from CUDA.jl to CPUCompiler.jl. The package AMDGPU.jl is coming along very well and will be plug-able with all this stuff. https://github.com/JuliaGPU/GPUCompiler.jl https://github.com/JuliaGPU/AMDGPU.jl

So we're freed from GPU vendor lock-in by getting a programming language lock-in.

Out of the frying pan, into the fire. Great.

Re: Julia GPU

#9

Post by dahart »

fizixer wrote: post #8
eigenspace wrote: post #7

Earlier quoted context omitted.

Most of the julia GPU stuff is being made vendor agnostic via moving infrastructure from CUDA.jl to CPUCompiler.jl. The package AMDGPU.jl is coming along very well and will be plug-able with all this stuff. https://github.com/JuliaGPU/GPUCompiler.jl https://github.com/JuliaGPU/AMDGPU.jl

So we're freed from GPU vendor lock-in by getting a programming language lock-in. Out of the frying pan, into the fire. Great.

What do you mean? What is programming language lock-in, and how is that worse than (or even comparable to) vendor lock-in? What's your goal?

Re: Julia GPU

#10

Post by amelius »

MayeulC wrote: post #3

I was really confused for a moment, because the article mention CUDA a lot, which is a nvidia-specific API/framework/language. I guess that's mainly to appeal to the CUDA crowd? However, Julia being seemingly based on LLVM, interfacing it with AMD GPUs should be quite doable: > Much of the initial work focused on developing tools that make it possible to write low-level code in Julia. For example, we developed the LL…

Yes, it would be great if the .jl source code didn't even mention CUDA (but right now it does, with statements such as "using CUDA" and "CuArray(...)".)
Post reply on HN