CUDA 10 in Clojure(dragan.rocks)
dragan.rocks
CUDA 10 in Clojure
https://dragan.rocks/articles/18/CUDA-10-in-Clojure
19 comments
The experimental CUDA bindings for LWJGL3 might also be an interesting target for Clojure interop: https://github.com/LWJGL/lwjgl3/blob/master/modules/samples/...
LWJGL3 is full of hidden treasures.
LWJGL3 is full of hidden treasures.
Neanderthal and ClojureCUDA seem like such awesome projects, makes me wish I had more time to get into linear algebra. Is anyone doing anything fun with it they could share?
non-ANN ML is essentially a subset of linear algebra applied to statistics.
also, if you do anything involving physics simulations, (actual physics, mechanical engineering, other engineering, etc) you will likely use it.
also finance. also also also.
also, if you do anything involving physics simulations, (actual physics, mechanical engineering, other engineering, etc) you will likely use it.
also finance. also also also.
Wonder if there'd be any lisp or clojure dsl that compiles down to fairly minimal c/cpp, so that you wouldn't have to have the cuda program be a string
Cuda program doesn't have to be a string. I keep them in regular .cu files, and just load them with slurp into clojure repl.
could start with something like this https://github.com/kovasb/gamma
I really wish clojure would adopt a heredoc syntax to make embed language snippets and docstrings nicer.
Some codebases have adopted markdown for their docstrings, and other nice formats are only a macro away.
Using markdown doesn't fix the problem of having to escape double quotes, unless you are using a literate programming technique where the clojure code is quoted inside of the markdown instead of vice versa. Using macros only works if the formats consist entirely of balanced s-expressions.
Clojure could just adopt user-defined reader macros instead. As expected there's an open source heredoc lib[0] for Common Lisp; the feature is so easy to add though it's probably been independently added several different ways (this uses ring buffers) to who knows how many projects.
[0] https://github.com/e-user/cl-heredoc alas gpl3, but no matter, easy to write your own
[0] https://github.com/e-user/cl-heredoc alas gpl3, but no matter, easy to write your own
Ya, it could be a good addition. But I dunno. For docstring I'd rather it just adopted a markup which everyone used. Heredoc would create too many kind of markups for doc I feel.
And for language embeds, I'm also torned. Because in a way, it is way nicer to use EDN and create a conversion layer from it to the underlying language.
Basically, I feel like there's a lot to gain from sticking to standard Clojure syntax. Like is the case for core.logic, hiccup, garden, etc.
The benefits being, they become first class this way. And then you can build macros on top, create them through functions, etc.
And for language embeds, I'm also torned. Because in a way, it is way nicer to use EDN and create a conversion layer from it to the underlying language.
Basically, I feel like there's a lot to gain from sticking to standard Clojure syntax. Like is the case for core.logic, hiccup, garden, etc.
The benefits being, they become first class this way. And then you can build macros on top, create them through functions, etc.
Been searching for a while trying to see if there are only CUDA libraries for Clojure and as far I can tell that is sadly the truth, no signs of any ROCm libraries available https://rocm.github.io/
Neanderthal has an OpenCL backend, and ClojureCL can be used for programming your own stuff, and they both work fine with ROCm's OpenCL support.
ah seems I was wrong it seems https://github.com/ROCmSoftwarePlatform/mxnet could conceivably be used through two layers of interop from clojure to java to scala
https://www.patreon.com/draganrocks