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

21–28 of 28 posts

Re: Julia GPU

#21

Post by mrfox321 »

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 is programming language lock-in?

When any code is written in some language?

Re: Julia GPU

#22

Post by jpsamaroo »

soganess wrote: post #20
maleadt wrote: post #16

Earlier quoted context omitted.

Yes, that's fair. I focused on CUDA.jl because it is the most mature, easiest to install, etc. but as I mentioned we're actively working on generalizing that support as much as possible, and as a result support for AMD (AMDGPU.jl) and Intel (oneAPI.jl) GPUs is rapidly catching up.

This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly version out? https://github.com/ROCm-Developer-Tools/HIP I realize these sort of tools aren't magic and whatever it spites out will need work, but it seems like a really good thin starting place for AMD suppo…

> This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly version out?

HIP and HIPify only work on C++ source code, via a Perl script. Since we start with plain Julia code, and we already have LLVM integrated into Julia's compiler, it's easiest to just change the LLVM "target" from Native to AMDGPU (or NVPTX in CUDA.jl's case) to get native machine code, while preserving Julia's semantics for the most part.

Also, interfacing to ROCR (AMD's implementation of the Heterogeneous System Architecture or HSA runtime) was really easy when I first started on this, and codegen through Julia's compiler and LLVM is trivial when you have CUDAnative.jl (CUDA.jl's predecessor) to look at :)

I should also mention that not everything that CUDA does maps well to AMD GPU; CUDA's streams are generally in-order (blocking), whereas AMD's queues are non-blocking unless barriers are scheduled. Also, things like hostcall (calling a CPU function from the GPU) doesn't have an obvious alternative with CUDA.

Re: Julia GPU

#23

Post by jpsamaroo »

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

Tim has been working on making it easy to use CUDA.jl and AMDGPU.jl pretty interchangeably through GPUArrays.jl, and this approach seems to be pretty extensible to other accelerators like Intel's dGPUs. KernelAbstractions.jl will also be gaining AMDGPU.jl support soon, so it'll be easy to write generic kernels without buying into a single vendor's cards.

Re: Julia GPU

#24

Post by deathtrader666 »

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.

I don't think there is anything in our programming world that is programming language agnostic, except for theory.

Re: Julia GPU

#25

Post by soganess »

jpsamaroo wrote: post #22
soganess wrote: post #20

Earlier quoted context omitted.

This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly version out? https://github.com/ROCm-Developer-Tools/HIP I realize these sort of tools aren't magic and whatever it spites out will need work, but it seems like a really good thin starting place for AMD suppo…

> This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly version out? HIP and HIPify only work on C++ source code, via a Perl script. Since we start with plain Julia code, and we already have LLVM integrated into Julia's compiler, it's easiest to just change the…

Thank you for taking the time! I found this quite helpful.

Re: Julia GPU

#26

Post by oivey »

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.

As opposed to being trapped in the C++ CUDA API? Julia isn’t that much harder to learn than Python. Does anyone really think the hard part of say, deep learning, is in learning Python or PyTorch?

Re: Julia GPU

#27

Post by MayeulC »

soganess wrote: post #25
jpsamaroo wrote: post #22

Earlier quoted context omitted.

> This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly version out? HIP and HIPify only work on C++ source code, via a Perl script. Since we start with plain Julia code, and we already have LLVM integrated into Julia's compiler, it's easiest to just change the…

Thank you for taking the time! I found this quite helpful.

Something that is hinted at, but not spelled out loud in our posts is that AMD actively upstreams and maintains a LLVM back-end for their GPUs, so it really is a matter of switching the binary target for the generated code, at least in theory :)

Re: Julia GPU

#28

Post by gc9 »

mrfox321 wrote: post #21
fizixer wrote: post #8

Earlier quoted context omitted.

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 is programming language lock-in? When any code is written in some language?

Maybe the issue raised is that libraries/APIs that define an ABI (Application Binary Interface) can be used from multiple programming languages that share calling conventions. So a question is about how Julialang libraries can be called from other programming languages. The "Embedding Julia" chapter of the manual says that from C there is an interface layer to lookup function objects, box parameters, and call.
Post reply on HN