4 ms·
The book looks interesting and the associated libraries (neanderthal for e.g.) But while going through your performance comparison [1], I feel something is off
by bhattisatish 6y ago
The book looks interesting and the associated libraries (neanderthal for e.g.)
But while going through your performance comparison [1], I feel something is off.
I am not that familiar with libpython-clj and how it works, but looks like you are loading python from within the JVM and in turn the python is loading the C++/fortran OpenBLAS libraries to get the numerical calculations done for the Correlation Coefficient. I suspect this multi-level indirection is creating it's own performance overhead.
For now, I don't believe the performance benchmark are telling us the true story :-)
But after saying all that, I love how concise is the clojure implementation is.
[1] https://dragan.rocks/articles/20/Clojure-Numpy-Cupy-CPU-GPU https://dragan.rocks/articles/20/Clojure-Numpy-Cupy-CPU-GPU
- gandreani 6y agoThe follow up article addresses this concern. Similar results https://dragan.rocks/articles/20/Clojure-Numpy-Cupy-CPU-GPU-2 https://dragan.rocks/articles/20/Clojure-Numpy-Cupy-CPU-GPU-...
- scottlocklin 6y agoYeah, well, that's a nonsense comparison: the neanderthal package is freaking lapack (in C++), and they used a java trick to get Clojure fast on it (basically run the C++ on allocated unmanaged memory blobs, which is the only marginally sane thing one can do in a language like Clojure). I wrote an early version of this in Clojure before throwing my hands up at the atrocity of doing this sort of thing. They also wash over very obvious (to anyone who knows how a computer works) issues with using Cuda and Clojure numerics in general. Misleading and Fail statements. If the whole book is filled with such chirpy and wrong assertions, they should fall on their swords for offending their numeric linear algebra forefathers and the shame of it all.