3 ms·
Considering that SBCL is among the fastest programming language implementations there is, 100x is actually not terrible for a first version.
by krig 12y ago
Considering that SBCL is among the fastest programming language implementations there is, 100x is actually not terrible for a first version.
- sigil 12y ago> Considering that SBCL is among the fastest programming language implementations there is... Source for this? I'd love to find a really fast lisp or scheme. Hadn't heard SBCL was particularly fast, and the alioth benchmarks don't show anything special there. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=sbcl&lang2=gpp&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Edit: actually SBCL stacks up alright against languages like Go or Rust in the alioth benchmarks, so maybe that's what you had in mind.
- mrottenkolber 12y ago> Hadn't heard SBCL was particularly fast What did you think was particularly faster than SBCL?
- sigil 12y ago> What did you think was particularly faster than SBCL? Haskell, Scala, Java, Go and of course C, C++, Fortran all outperform SBCL in the alioth benchmarks. Against the schemes, lisps, and "scripting" languages though SBCL stacks up favorably. I didn't notice that krig's comment was mainly comparing SBCL to this latter category ("programming language implementations").
- pjmlp 12y agoI imagine commercial Lisps like LispWorks would fare even better.
- lispm 12y agoDepends on what you look at. LispWorks is fast, but not really faster than SBCL in Gabriel benchmarks. But what about real programs, garbage collection, etc.? LispWorks is used because its implementation is very capable, widely ported and it has stuff like a GUI toolkit which runs on Windows, GTK+ and Cocoa/Apple.
- pjmlp 12y agoThanks for the info. As I never used it, besides the usual magazine reviews in the old days, as such I thought it was strong on that area as well.
- lispm 12y agoIt is, the 64bit version is really fast, similar to SBCL. But that's already kind of a local maximum. The GC and the rest of the runtime is better, probably CLOS is more optimized, ... LispWorks does not type check code much, but it has type inferencing when optimizing code. You can see my benchmarks (the last from 2013) on my Mac: http://lispm.de/lisp/benchmarks.html http://lispm.de/lisp/benchmarks.html
- ohyes 12y agoAlso consider that the c/++ versions use intrinsics which means it's basically a compiler vs random assembly level code. Without that level of optimization they're fairly equivalent.
- mrottenkolber 12y ago> Haskell, Scala, Java, Go and of course C, C++, Fortran all outperform SBCL in the alioth benchmarks. The way I read it, SBCL is in the same ballpark of what you mentioned above and magnitudes faster than the rest. Its a logarithmic scale. Then again its a biased selection of benchmarks. Try finding a faster regular expression engine than CL-PPCRE. I will stick to the stance pointed out by "Let Over Lambda": Common Lisp is--by language design--the fastest language around, as long as language X does not have COMPILE, it can not beat CL at a whole class of benchmarks (not found on alioth).
- deleted 12y ago[deleted]
- krig 12y agoI'd say those numbers you link to are pretty amazing for a garbage collected language. Compared to Java, SBCL is roughly on par, with some benchmarks 2-3x slower and some 2-3x faster. edit: To clarify, I'm not saying SBCL makes Common Lisp the fastest language (I don't even think that's a meaningful statement). But to be within 2-3x of the JVM or C (and even outperforming C in some scenarios) certainly puts SBCL among the fastest language implementations. All the other ones you mention (C, C++, Go, Java..) are indeed also among the fastest. :)
- ohyes 12y agoAmazing for a garbage collected dynamically typed language.