tweetnacl VS cl-cuda

Because that product was an embedded system running on a very small SoC. It only had 1MB of flash and 192k of SRAM. It's theoretically possible to run CL on a system that small -- Coral Common Lisp ran on a Mac Plus with 1MB of RAM back in the 1980s -- but nothing off-the-shelf will do that today.

(I did, however, put a little Scheme interpreter on it as an easter egg :-)

I do have some CL code that supports the crypto project. The back-end for this:

https://stage.sc4.us/sc4/sc4tk.html

is written in CL (though all the actual encryption is done client-side in Javascript). I also have some prototype crypto code that I don't really use for anything, including this double-ratchet implementation:

https://github.com/rongarret/tweetnacl/blob/master/ratchet.l...

and some elliptic curve code:

http://www.flownet.com/ron/lisp/djbec.lisp

Of course. There are many. Any binary format. Any ASN.1 format. DEF and LEF for hardware descriptions. The output of mysqldump.

Here's another example:

https://github.com/rongarret/tweetnacl/blob/master/ratchet.l...

starting at line 82. (That's one that I designed.)

> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this

this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1]

[0] https://github.com/JuliaGPU/CUDA.jl

[1] https://github.com/takagi/cl-cuda

A Common Lisp Library to Use Nvidia CUDA\ (0 comments)

Personally, I've been relying on the stream-based method using py4cl/2, mostly because I did not - and perhaps do not - have the knowledge and time to dig into the CFFI based method. The limitation is that this would get you less than 10000 python interactions per second. That is sufficient if you will be running a long running python task - and I have successfully run trivial ML programs using it, but any intensive array processing gets in the way. For this later task, there are a few emerging libraries like numcl and array-operations without SIMD (yet), and numericals using SIMD. For reasons mentioned on the readme, I recently cooked up dense-arrays. This has interchangeable backends and can also use cl-cuda. But barring that, the developer overhead of actually setting up native-CFFI ecosystem is still too high, and I'm back to py4cl/2 for tasks beyond array processing.