takagi

cl-cuda

Common Lisp2015–2025

takagi / cl-cuda

cl-cuda

Cl-cuda is a library to use NVIDIA CUDA in Common Lisp programs.

Explore on GitHub Read Hacker News discussions

5Distinct people

7Mentions

0Explicit recommenders

305GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Cl-cuda is a library to use NVIDIA CUDA in Common Lisp programs.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2015-02-04 08:27:39 UTC to 2025-09-05 23:08:44 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	0	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	3	1	2
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	0	1

What Hacker News says

7 sources

Karrot_Kream·Sep 5, 2025

From what I can tell, gaming has mostly just embraced two language solutions. The big engines Unity, Unreal, and Godot have tight cores written in C/C++ and then scripting languages that are written on top. Hobby engines like Love2D often also have a tight, small core and are extensible with languages like Lua or Fennel. Modern Common Lisp also seems to have given up its "one language to rule them all" mindset and is pretty okay with just dropping into CFFI to call into C libraries as needed. Over the years I've come to see that mindset as mostly a dead-end. Python, web browsers, game engines, emacs, these are all prominent living examples of two-language solutions that have come to dominate in their problem spaces. One aspect of the "two language problem" that I find troubling though is that modern environments often ossify around the ex

Read the rest

act solution. For example, it's very difficult to have something like PyTorch in say Common Lisp even though libcuda and libdnn should be fairly straightforward to wrap in Common Lisp (see [1] for Common Lisp CUDA bindings.) JS/TS/WASM that runs in the browser often is dependent on Chrome's behavior. Emacs continues to be tied to its ancient, tech-debt ridden C runtime. There seems to be a lot of value tied into the glue between the two chosen languages and it's hard to recreate that value with other HLLs even if the "metal" language/runtime stays the same. [1]: https://github.com/takagi/cl-cuda

In ML needs a new programming language – Interview with Chris Lattner

medo-bear·Oct 27, 2021

> 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

In Why Lisp? (2015)

medo-bear·Oct 24, 2021

my background is also in physics and mathematics. in fact i think common lisp is well suited to a physicist-hacker type mindset. i could probably write a lengthy blog post about why i think this could be, but some of the key appeal factors are: * unmatched interactive development which could be used for exploration of problems such as dynamical and complex systems * although it is a very high level language you can perform low level optimizations in common lisp itself * extremely powerful macro system that allows you to develop in a declarative style to reflect your problem domain. for example you can program in a syntax that is natural to general or special relativity, quantum mechanics, etc. * fast and free implementations such as SBCL * the language is standardized so your code will not need to be unnecessarily maintained (this is good

Read the rest

for university professors that have repeating long-running courses) i am not sure what type of references you are asking for but i will list few open source projects that might be interesting to you: * CLASP - common lisp implementation build on top of LLVM. this project is headed by a computational chemist (prof. schafmeister) [0] * PetaLisp - for HPC [1] * MAGICL - Matrix Algebra proGrams In Common Lisp by Rigetti Computing [2] * Quil - quantum instruction language developed on top of common lisp [3] * CL-CUDA - use NVIDIA CUDA in Common Lisp programs [4] * MGL - Common Lisp machine learning library [5] * Maxima - a computer algebra system developed in common lisp [6] i think these are plenty to show that there exists serious interest in using common lisp for scientific computing. it is possible that some of the people behind these projects are on HN and maybe they can further expand on this [0] https://github.com/clasp-developers/clasp [1] https://github.com/marcoheisig/Petalisp [2] https://github.com/quil-lang/magicl [3] https://github.com/quil-lang/quilc [4] https://github.com/takagi/cl-cuda [5] https://github.com/melisgl/mgl also https://github.com/melisgl/higgsml [6] https://maxima.sourceforge.io/

In Idiomatic Clojure without sacrificing performance

oumua_don17·Aug 13, 2021Submission

A Common Lisp Library to Use Nvidia CUDA

93 points · Open discussion

medo-bear·Oct 18, 2020Submission

Common Lisp CUDA

2 points · Open discussion

akssri·Apr 11, 2020

Common Lispers have had the ability to write CUDA kernels (with shaders) on-the-fly with a DSL in cl-cuda for many years now. See, https://github.com/takagi/cl-cuda Cupy (a project in which takagi is/was actively involved) also has the ability to compile kernels in the Python REPL, but the kernel code needs to be written in C and passed in as a string (pyOpencl can do the same for OpenCL). In fact, not too many years ago, the kernels for gradient descent, max pooling etc. were all entirely in Python in Chainer. Projects like JAX take this to another level by having the ability to transform the bytecode of a restricted class of Python functions straight into CUDA kernels. I can't speak much about Clojure/Neanderthal, but I'd advise the people to stop dissing projects they are not familiar with, least of all using silly benchmarks like the

Read the rest

above.

In CuPy Accelerates NumPy on the GPU? Hold My Cider, Here's Clojure

ICWiener·Feb 4, 2015

Instead of @kernel and @cuda, you might want to use defkernel and with-cuda... See the example files for cl-cuda: https://github.com/takagi/cl-cuda/blob/master/examples/vecto... I though that Julia had macros, so I don't understand why what you propose is not possible (note to self: find time to learn Julia).

In Compiling Julia for NVIDIA GPUs