
Lessons Learned Implementing Common Lisp with LLVM [video] - StreamBright
https://www.youtube.com/watch?v=mbdXeRBbgDM
======
ngcc_hk
Wow!!! This is a wonderful talk.

The title is so old school though that need changing.

\- How I use lisp to fight human aging or \- why I choose lisp over python to
combat protein generation \- my protein generation using llvm was done all by
lisp for. Reason

The talk is amazing. This one chemistry prof. who seems to be an IT expert but
really just start lisp programming by building a lisp interpreter.

Wow!!!

[https://github.com/clasp-developers/clasp](https://github.com/clasp-
developers/clasp) And The cando one.

~~~
drmeister
Thank you. It was a talk for the llvm developers meeting and I'd been turned
down for talks a couple of times a couple of years before that. I REALLY
needed to get to this meeting to talk with llvm developers - so I pitched the
title that I thought people there wanted to hear...

------
sctb
This talk references the Cleavir compiler, which is part of Robert Strandh's
(of McCLIM and Climacs fame, at least) modular CL implementation called SICL:
[https://github.com/robert-strandh/SICL](https://github.com/robert-
strandh/SICL). Looks like there's at least one discussion on HN:
[https://news.ycombinator.com/item?id=8284835](https://news.ycombinator.com/item?id=8284835).

------
ken
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.

~~~
zelly
I 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.

~~~
drmeister
It'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.

------
jeofken
Having a hard time finding words to express how interesting of a topic Mr.
Schafmeister is working on!

I’m playing around with compilation, self-studying during weekends. I want to
learn how to compile Closures from my small Lambda Calculus language into
something like C++. “Baby’s first FP codegen”, or the like.

I have struggled to find reading material for the intermediate beginner on
this subject. So, if anyone on HN has a favourite link on the web about
compiling functional languages, please feel free to share them.

~~~
nils-m-holm
Here's a book dedicated to compiling closures to C:

[http://t3x.org/clc/index.html](http://t3x.org/clc/index.html)

It starts with lambda calculus and ends with compiling a tiny Scheme subset to
portable C code.

------
rurban
Still 4x slower than sbcl. And lot of threading problems, thread-unsafe hashes
and symbols all over.

A proper C++ ffi for CL with a good clbind and GPU binding would probably help
him better than this monster.

~~~
drmeister
"A proper C++ ffi for CL with a good clbind" is easy to say but much harder to
implement - no one but I have achieved it and I had to implement a Common Lisp
to achieve it. It's not just calling functions and translating arguments and
return values that is difficult. The much harder problem is unwinding the
stack over C++ frames that use RAII.

------
mark_l_watson
I have heard him talk before about Clasp, really entertaining. Coincidentally,
I just built Clasp from source last weekend. I don’t when I will have time to
do this, but I would like to choose a deep learning library with a good C++
interface (perhaps mxnet) and try to get a good Clasp wrapper written.

~~~
currymj
If you do this, using PyTorch’s new C++ frontend and API might be better; I
think PyTorch is generally more popular, at least for use by individuals
(maybe MXNet is better in production or something).

[https://pytorch.org/cppdocs/](https://pytorch.org/cppdocs/)

(i was recently working with PyTorch and wishing I could use Common Lisp
instead of Python, for various reasons.)

------
drmeister
Thanks, everyone! I missed this thread when it first came out.

------
tomcam
The video is preternaturally clear. Not sure if it's because I'm on a new
monitor or what.

