Re: Timing Comparison?


Using preexisting compilers or compiler backends is great ... if the code they produce is compatible with how the GC works and with how the runtime should work, and dumping images, and, and, and.

Experimentally, for M1, C/LLVM has about 20% on SBCL for FP-intensive code, and quite likely less for more general code.  The difference for FP code was more for LW but LW can often be surprisingly competitive with SBCL for more general code (and LW's GC is better, resulting in much less variability in timings).

LLVM would probably be better at knowing how to generate code for whatever vector extension is fashionable this week.

Given how much money has been thrown at LLVM it's kind of entertaining how little value it provides compared to the Lisp compilers.

--tim

> On 2 Nov 2025, at 15:43, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
> 
>> 
>> On 2 Nov 2025, at 15:15, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> FWIW, SBCL has a pretty darn fast (but fastidious) compiled output on ARM. Impressive. I just wish it also had a CAPI.
> 
> This discussion went into tea-bagging LW compiler even faster than usual. With that said, it is quite remarkable what SBCL has achieved on the performance front, especially given that it is a free community driven project. If anything, this LW vs SBCL situation shows how challenging it is to write a highly performing compiler and it does not look like LW is going to catch up at this stage.
> 
> However, I was wondering the other day if that is really necessary for one to maintain a homebrewn compiler anymore. Surely in the 80s and 90s there was no other real option than to write your own, but given that we have llvm nowadays, writing your own compiler makes no real sense anymore, beyond the learning experience. The performance of the machine code that comes out of llvm is typically on par with hand written assembly and often exceeds that due to its intricate knowledge of the multitude of quirks of the CPUs it can compile for.
> 
> In a very seldom situation when it produces less efficient code one can simply drop into its IR (intermediate representation) and try writing the problematic bit by hand as its own meta-assembly format is very simple (or just use plain assembly if you must but then you will limit yourself to that specific CPU). But it would be very interesting to see still if SBCL would be able to outperform llvm in certain cases given how good its bespoke compiler is, but the cost of maintaining it is probably not worth it anymore even for SBCL who can be very proud of their work on it.
> 
> PS. do I love it when names look like Roman numerals. Check this out: LLVM. I am stoked.
> 
> 1105
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html