4 ms·

Maybe people will get to their senses and switch to Julia instead of having to waste all these time on Python bindings.

by socialdemocrat 6y ago

habibur 6y ago
Python here basically works as a binder for C, which is what everything is written in.
- eigenspace 6y ago
  That is in fact the problem, yes.
dnautics 6y ago
Honestly I think julia missed the boat. There was an opportunity for julia to treat the gpu as an abstract distributed node (which is a first class concept in julia) and pay respect to the reality of data gravity. But they chose to instead basically treat the gpu as a synchronous entity. I'm now bullish on elixir-nx because I think there's an outside shot they will get it right. Python is a lost cause.
- BadInformatics 6y ago
  I'm not sure that's necessarily the domain of a low-level package like CUDA.jl though (which I assume you're referring to). That kind of interface is more the domain of higher-level packages like https://github.com/JuliaGPU/DaggerGPU.jl https://github.com/JuliaGPU/DaggerGPU.jl and to a lesser extent https://juliagpu.github.io/KernelAbstractions.jl/stable/ https://juliagpu.github.io/KernelAbstractions.jl/stable/. Moreover, the jury is still out on whether the built-in Distributed module is an ideal abstraction for every use-case (clusters, heterogeneous compute, etc.) WRT Nx, my biggest question is how they'll crack the problem of still needing big balls of C++ and the shims everywhere to get acceleration. Creating a compiler that generates efficient GPU or other accelerator code is a massive research project with no clear winners, never mind the challenge of reconciling the very mutation-heavy needs of GPU compute with a mostly immutable language model.
  - dnautics 6y ago
    There's plenty of mutability escape hatches in the erlang vm, and basically everyone who works in the language long enough is familiar with the idea of holding on to an immutable reference to a mutable thing. Like a database connection. Or a connection to a remote microservice. Or an ETS table.

Maybe people will get to their senses and switch to Julia instead of having to waste all these time on Python bindings.

habibur 6y ago

Python here basically works as a binder for C, which is what everything is written in.

eigenspace 6y ago
That is in fact the problem, yes.

dnautics 6y ago

Honestly I think julia missed the boat. There was an opportunity for julia to treat the gpu as an abstract distributed node (which is a first class concept in julia) and pay respect to the reality of data gravity. But they chose to instead basically treat the gpu as a synchronous entity. I'm now bullish on elixir-nx because I think there's an outside shot they will get it right. Python is a lost cause.

BadInformatics 6y ago
I'm not sure that's necessarily the domain of a low-level package like CUDA.jl though (which I assume you're referring to). That kind of interface is more the domain of higher-level packages like https://github.com/JuliaGPU/DaggerGPU.jl https://github.com/JuliaGPU/DaggerGPU.jl and to a lesser extent https://juliagpu.github.io/KernelAbstractions.jl/stable/ https://juliagpu.github.io/KernelAbstractions.jl/stable/. Moreover, the jury is still out on whether the built-in Distributed module is an ideal abstraction for every use-case (clusters, heterogeneous compute, etc.) WRT Nx, my biggest question is how they'll crack the problem of still needing big balls of C++ and the shims everywhere to get acceleration. Creating a compiler that generates efficient GPU or other accelerator code is a massive research project with no clear winners, never mind the challenge of reconciling the very mutation-heavy needs of GPU compute with a mostly immutable language model.
- dnautics 6y ago
  There's plenty of mutability escape hatches in the erlang vm, and basically everyone who works in the language long enough is familiar with the idea of holding on to an immutable reference to a mutable thing. Like a database connection. Or a connection to a remote microservice. Or an ETS table.