CUDA 10 in Clojure | Hacker News Reader

CUDA 10 in Clojure

dragan.rocks

157 pointsdragandj19 comments

Reminder that you can support Dragan's work on Patreon, if it's acceptable to post here:

https://www.patreon.com/draganrocks

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.

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.

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

could start with something like this https://github.com/kovasb/gamma

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.

yes but wouldn't it be nice to be able to emit CUDA/OpenCL code from an AST so that you could use your Clojure functions on the GPU without duplication ?

It wouldn't since most of Clojure functions would be poor match for the GPU hardware.

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

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.

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/

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

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.

Dragan does it again

He does rock!

Reply on news.ycombinator.com