I don’t think so. My simple reading of things there is that that was for one particular micro-benchmark (and the Benchmarks Game is acknowledged to be unrealistic and not actually suitable for comparing language performance), that the results were not actually conclusive, and that it had required telling SBCL to do some stupidly dangerous things that you should probably never turn on on real software, because they may well make it behave catastrophically badly rather than just crashing when you have a bug.
On https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at present, the fastest SBCL implementation, which seems to include these optimisations, is at 2.0, with other SBCL implementations being slower, the first one (whatever that means) being 8.0; meanwhile, the Rust implementations range between 1.0 and 1.2. The SBCL implementations all use at least eight times as much memory as the Rust implementations, too.
I think this demonstrates my point pretty well, actually.
> … required telling SBCL to do some stupidly dangerous things …
No, that isn't required.
On the contrary SBCL is quite insistent that the arithmetic be made safe.
I'm not even a Lisp newbie, but with help from SO I've been able to tweak those spectral-norm programs to make the SBCL compiler happy without destroying the performance:
The (micro)benchmarks game is a gimmick and should not be taken seriously. You forgot to mention that the SBCL #3 implementation also sits at 2.0 and is fully memory safe.
I fail to see the reason for you presenting the facts in this manner especially the "stupidly dangerous things part" which is of course totally inaccurate. (safety 0) has its uses (e.g. like Rust unsafe).
Your conclusions are not indicative of real world performance.
Might answer your question [0]
[0] https://news.ycombinator.com/item?id=2192629