2018 LLVM Developers’ Meeting: C. Schafmeister “Lessons Learned Implementing Common Lisp with LLVM”
Vložit
- čas přidán 22. 06. 2024
- llvm.org/devmtg/2018-10/
-
Lessons Learned Implementing Common Lisp with LLVM over Six Years - Christian Schafmeister
Slides: Coming Soon
-
I will present the lessons learned while using LLVM to efficiently implement a complex memory managed, dynamic programming language within which everything can be redefined on the fly. I will present Clasp, a new Common Lisp compiler and programming environment that uses LLVM as its back-end and that interoperates smoothly with C++/C. Clasp is written in both C++ and Common Lisp. The Clasp compiler is written in Common Lisp and makes extensive use of the LLVM C++ API and the ORC JIT to generate native code both ahead of time and just in time. Among its unique features, Clasp uses a compacting garbage collector to manage memory, incorporates multithreading, uses C++ compatible exception handling to achieve stack unwinding and an incorporates an advanced compiler written in Common Lisp to achieve performance that approaches that of C++. Clasp is being developed as a high-performance scientific and general purpose programming language that makes use of available C++ libraries.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com - Věda a technologie
"Common Lisp macros are to C++ templates what poetry is to IRS tax forms"
10:32 :)
Author here: I'd like to thank Karsten Poeck for all of his work getting the ansi tests running and fixing bugs.
You're the man! I remember seeing your Google Talk a few years ago, it's awesome to see how the project has progressed.
Thank you for your awesomeness, sir!
You are very passionate. Thanks for the inspiration!
Thank you for your lectures, sir! Your work have inspired me to change my career path
This is so cool! I just had a daydream of combining Lisp with llvm, googled it and then ended up here. :) And I absolutely agree with you on Lisp macros. The macros are a killing feature of Lisp IMHO.
Captain Jean Luc Picard, from USS Enterprise.
Awesome work!
11:22 It's a standard language and It's timeless; it's not being updated all the time. It's not changing It doesn't need to because it has macros
llvm is such a wonderful tool for people writing compilers!!
And it’s developed by someone at UIUC and I’m so excited when I learned it because I’m going to attend uiuc this fall!!
Great work; for a cause that's more useful that what the IT domains gets busy with in most cases .. And such a humble presentation :) Thank you
Wow he's programming chemistry.
I remember watching his talk many years ago, great to see an update and the progress that is made!
woah! I am blown away. Amazing
Great approach. I love that he could craft CUDA kernels with an LLVM compiler. I'll need to take a closer look at this!
I loved this talk, your enthusiasm, and confidence to just go for it, is amazing, thank you. Inspiring indeed
Common Lisp is indeed a long lasting "local optimum" for programming. It is fast, has enough core functionality to get you started with a project without having to hunt for libraries (you can, but you are not forced to like you are in other languages, which are "minimalist").
The only drawback which annoys me is that all implementations use pointer tagging, so, if you REALLY need a 64 bit fixnum, not boxed, you are out of luck.
sbcl: (log most-positive-fixnum 2) >> 62.0
clasp: (log most-positive-fixnum 2) >> 61.0
Common Lisp would be perfect, if there was an implementation which has 64 bit fixnums.
Is it really a case, what about declare optimize speed 3 fixnum x ?
I'm just blown away by what this guy says about aging. I need to follow this development. I want to know if he's right. If he is this is miraculous.
Amazing work!
Wow, this is mega cool. Would love to have this debug for elisp.
Brilliant mind
That was really great!
This was an awesome talk. Thanks !
Lisp is God's favorite language
God program himself in Lisp.
10:32 Oh I'm stealing this line, genius!
Fascinating
CanDo was hypercard like programming application on the Amiga
FANCY! SUPER NIFTY
lovely. Esp. the GPU part is interesting.
if sbcl faster why not just use that?
Always liked c style languages but learned clojure recently and liked it too. Not sure how it compares to clisp in terms of speed and macro capabilities.
Clojure is generally slower than SBCL, there is a heavy price to being hosted on the JVM. The macro capabilities are similar however. Be careful with the word "clisp" there is a dormant Common Lisp implementation called "clisp" so it should not be used to mean "Common Lisp" itself. I would say Common Lisp is the more "lispy" of the two as most people using Clojure don't have a Lisp background in general so they drag in habits from non-Lisp languages this spills over into the libraries favoring things like hashmap dispatch over combinators and also hashmaps over functions with heavy destructuring rather than abstracting and reusing.
Why need to implement CL on LLVM, why not just exposing C++ to SBCL? Why new compiler?
He uses a lot of existing code to implement CL (Like SICL), and because it has LLVM internals exposed in CL and presumably uses C++ style object style storage internally it will be much easier to co-mingle with C++ going into the future. Also, he can target any LLVM backend architecture with his CL code so it can be relatively easily adapted to modern compute architectures (Supercomputer, GPU, etc.).
Common Lisp is hackers’ favorite language
Why so?
@@JstJaybeingJay Because it's too flexible, you can optimize the language as you want, like human languate
wow
I wonder if Julia would work here as well
@spaceLem what are limitations of Julia's macro system? Just that it's practically harder to use because the language has rich syntax and you need to keep that in mind?
People talk a lot about Common Lisp but its implemented in C/C++, right?
It can be or it can be in a different language. In the past, they've implemented C using Lisp. More about that here: en.wikipedia.org/wiki/Genera_(operating_system)
@FichDich InDemArsch My example was just concrete evidence that C or C++ is not strictly necessary to implement Common Lisp. There are even systems where C and C++ are not available out of the box instead you might have a horrid language like IBM RPG. For most common computers, C and C++ are probably the way to go. You can't necessarily implement any language in any language. If you've got a high level language which can't access hardware but the language you're implementing, language B needs to access hardware, say display to screen as part of the language spec you can't get there. Some languages especially dialects of BASIC can render shapes and such as part of the spec, if you've got a language which can't get at the display driver say Scheme (R5RS only), you're not getting there.
Try Julia Lang