4 ms·
This is fascinating to me because coming at it as a Lisp programmer, my impression of LLVM is that it's primarily a library for doing Lispy things in C. It kin
by ken 8y ago
This is fascinating to me because coming at it as a Lisp programmer, my impression of LLVM is that it's primarily a library for doing Lispy things in C. It kind of makes sense, then, that you should be able to use the codegen parts of LLVM for implementing Lisp itself, and I love that someone has actually done that. And that he bootstrapped it using an existing self-hosted compiler.
The obvious question I have is why not just use something like SBCL as the starting point. His own benchmarks show it's ~4x faster (so far). Is it not easier to add GPU support to SBCL, than to write a new Lisp compiler from scratch? Of course, this way is more fun.
- jacobush 8y ago"easier to add GPU support to SBCL" excuse me?! Where'd you even begin?
- ken 8y agoI'd begin by adding a new architecture, and merging an existing library which can convert expressions to GPU kernels -- same as he's doing now with his LLVM-based one. Why would it be any different? Is LLVM so GPU-friendly that it's worth it to write 250K lines of code just to be able to call it a bit more easily?
- pjmlp 8y agoYes it is, LLVM toolchain is directly supported by Khronos for GPGPU standards (LLVM <-> SPIR-V integration), NVidia also makes use of it, and it has a backend for shaders emulation on CPUs.
- chrisseaton 8y agoI don’t think anyone anywhere has achieved general GPU offload for a general purpose language yet, so your idea that it would be easier than writing a lisp compiler, which we’ve done millions of times, is probably not realistic.
- pfdietz 8y agoMillions of times? Toy lisps, maybe; full Common Lisps, no. Good to see ansi-tests mentioned. :)
- ken 8y agoCommon Lisp is not just "a lisp". I can probably count on the fingers of one hand the number of Common Lisp compilers I've seen in my life. I can write "a lisp" in a couple dozen lines of code, but my copy of CLTL2 on the shelf is about 2 inches thick. I'm not saying GPU offload is easy. As you point out, no general-purpose language today does that (and LLVM doesn't seem to offer it as a feature), so you'd have to implement that either way. The choice is "new compiler + GPU target" versus "mature portable compiler + GPU target". Why is the latter "not realistic"? I find it hard to believe that the architecture of every (free) compiler is so horribly suited to this that we need to start from scratch. We've forked CL compilers many times, for new architectures, but I've never seen any architecture that required starting over.
- pmarin 8y agoThe main reason to write a new Lisp compiler based on LLVM was the full integration with the hundred of thousands c++ lines of code he previously wrote.
- ken 8y agoWhat does "full integration" mean, and why couldn't that be achieved with some macros? He already showed how he used macros to achieve nice integration with LLVM (written in C++) for his interpreter. Worst case, you'd have to write a name mangler, to teach your FFI about C++ symbols, but I imagine that would be at least an order of magnitude easier than an entire compiler (150K lines C++, 85K lines CL).
- zelly 8y agoI have no idea why he did it instead of forking SBCL, but I thank him for it dearly. Lisp on LLVM is one of the things that will save it from dying. LLVM comes with extreme portability (future proofing to future platforms) and lots of industrial strength tooling. SBCL is very good, but it’s hard to say how long it will keep being developed.
- lispm 8y ago> I have no idea why he did it instead of forking SBCL It's basically explained in the video. He forked ECL, because he wanted to have a CL implementation based on LLVM and very deep C++ integration. ECL is already a C-based Common Lisp. > SBCL is very good, but it’s hard to say how long it will keep being developed. As long as people work on it.
- drmeister 8y agoIt's easy to say something like this in retrospect But even after working on this for a couple of years I have no idea how I would get started with SBCL. There was a team at Google that tried to add a llvm backend to SBCL and they stopped working on it after a year. I don't want to knock SBCL - it's an amazing compiler! But I think there are way too many problems that I would have had to solve, all at once, to get C++ and SBCL to interoperate.