News for hackers. Stuff that matters.
Re:Fast.ai and why Python is not the future of ML with Jerem... by ummonk on Wednesday September 09, 2020 @08:23PM (#24427570)
And notably, CUDA.jl or whatever Julia package you use for gpu acceleration still has to incorporate CUDA, the same way Pytorch does.

So to the end user who doesn't want to write CUDA, I don't see why using a Julia package for gpu acceleration is any better than using PyTorch in Python.

Re:Fast.ai and why Python is not the future of ML with Jerem... by amkkma on Thursday September 10, 2020 @12:01AM (#24428768)
Wrong. Julia can call out to Cuda kernels, but it also does codegen for custom ops and types. Technically with enough engineering time, someone could rewrite all those C cuda kernels in julia, and julia would just generate low level machine GPU code on the fly.

Pytorch on the other hand HAS to glue together c and c++ cuda code.

Re:Fast.ai and why Python is not the future of ML with Jerem... by ummonk on Thursday September 10, 2020 @02:21AM (#24429451)
You mean like PyCuda?
Re:Fast.ai and why Python is not the future of ML with Jerem... by dklend122 on Thursday September 10, 2020 @05:09AM (#24430327)
Nope. PyCuda is writing inline C cuda and hardly integrated with python.

Julia has four layers of GPU abstractions, each being successively easier to use ( bit a bit less control. ), all in pure Julia and reusing the compiler and normal Julia abstractions and integrated with AD etc

CUDA.JL, GPUArrays.jl, kernelabstracions.jl, tullio.jl.

At the highest levels you just write normal loops or index notation and the code and backward pass generated. Also generic to backend-simd and multithreading cpu and soon AMD rock, intel accelerator and distributed

This all composed with deep learning libs etc