Hacker News Reader

Comment by jcelerier | Hacker News Reader

> There's already a blazing fast lisp with a large library ecosystem... It's called Common Lisp.

sorry what ? where does this meme comes from ? Most CL implementations are at best multiple times slower than your average JITted language

View on HN

Like I said in a different reply, it was previously possible to compare right on Debian's language shootout page. Apparently they took out that feature, so here's an old link to somebody comparing SBCL, Factor, V8, and LuaJIT.

http://factor-language.blogspot.com/2010/05/comparing-factor...

All four languages have improved over the last 8 years, but you can see SBCL and LuaJIT are in the same ball park, each winning on some tests. My recollection is that SBCL usually "wins" in the number heavy tests like Mandelbrot, but I don't have time to dig up the links.

Interesting you should mention Mandlebrot:

https://old.reddit.com/r/programming/comments/6eg0x/where_ar...

> the inner loop of mandelbrot is now identical (at the ucode IR level) to the IR generated by a C compiler. All type checks have been eliminated and only the pure (statically typed) FP adds/multiplies are left (the remaining task is to transform the ucode to the best possible machine code -- working on it). Similar results can be obtained for other numeric loops.

^ This is from a ten-year-old post about LuaJIT optimizations.

Now I’m curious, so I’ll try to benchmark SBCL vs LuaJIT vs Fennel when I get home tonight and post the results.

Regardless, though, I think it’s clear that there are already fast Lisps.

I'm definitely interested in your results. I do want to chime in to say that I do not think this would, in any way, take away from any of these efforts. If anything, I would hope they would all help challenge each other. In a beneficial way.

I finally got around to doing this, and the results were nearly the same on the Mandelbrot benchmark. SBCL generates slightly faster code, but in this case it's using less efficient multi-threading.

I might try again with a different program.

https://jl2.github.io/2018/09/01/luajit-and-cl-benchmark/

Maybe most are so, but SBCL and CMUCL are reasonably fast. Also I am not sure what you mean with "average JITed language".

Where did the meme come from that the average JIT compiler is fast ?

Maybe you could post some links to benchmarks that demonstrate your claim.

When people only care about the open source ones, maybe.

The free, open source CL implementation that matters and pretty much everyone (incl Google) is using - SBCL - destroys luajit in performance, not to mention your average JITed language..

Out of interest do you have any links regarding performance comparison of SBCL and luajit.

Before they completely ruined the UI, it used to be possible to compare languages on Debian's language benchmark shootout page. But now I can only find Lua, and can't even compare it to Lisp.

If I recall correctly luajit was removed from those benchmarks, for reasons I'm not entirely sure why, but I think it was to do with including only the 'standard' interpreter for a language?

I seriously doubt SBCL "destroys" Luajit. Or maybe it depends on the type of code. I remember a few years ago doing some Project Euler problems in both Common Lisp and Lua, and my recollection is that for that sort of code (nested loops, array accesses, fixnum arithmetic), SBCL ran code that had no type annotations significantly slower than Luajit, and with full type annotations SBCL only slightly faster than Luajit (and Lua uses no type annotations!). Of course, that type of code is probably in the JIT's sweet spot.

(I recognize this is unscientific and anecdotal, but I'm just trying to point out that it would take significant evidence to convince me SBCL is faster than Luajit, because my experience is the opposite.)

Some benchmarks of graphics stuff was faster for me in SBCL vs. Love. Going with Love still, but yeah.

Reply on news.ycombinator.com