Hellooooo Qt without Smoke bindings.
A faster Clasp compiler is coming soon – the current Clasp compiler generates slow native code that is about 100x slower than highly tuned Common Lisp compilers like Steel Bank Common Lisp.
No mention of the expected speedup, but 100x is a huge performance problem.
Not true and not even funny.
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.
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.
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. :)
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").
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).
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.
You can see my benchmarks (the last from 2013) on my Mac:
Essentially, LLVM does tons of low-level optimizations but Clasp does few high-level, CL-specific ones. SBCL, on the other hand, mostly does CL-level optimizations and few low-level ones.
This invokes llvm at runtime, and AFAIK emscripten isn't ported to emscripten.
FWIW, I've tried other lisps under emscripten:
Most lisps generate machine code, store them in RAM, and then execute that RAM. This is not possible under emscripten.
Clisp is a good candidate, since it's byte-code interpreted rather than generating machine code, but clisp makes so many assumptions about how the machine works (in particular it strongly wants a C style stack and does manual stack-pointer manipulation). I actually got fairly far into the bootstrap process under emscripten, but the minimal lisp interpreter it compiles generated bizarre errors.
Can you explain what emscripten is used for? I'm fully aware of what it does, just not why someone would want to use it. How do you use things like jQuery or access window or document from C and then compile it to js? Or is emscripten specifically for js that doesn't interact with the DOM?
You have Parenscript for that: http://common-lisp.net/project/parenscript/
(I haven't used it yer though.)
Is this project something that you're doing to support your own research goals in computational chemistry? If so, can you share how this project fits into the bigger picture?
I wonder why start from scratch for an LLVM backend, can't SBCL be used to generate LLVM code?
Best of luck.
Niiice. I want to program C++, but not in C++.
Description-en: conflict-driven nogood learning answer set solver
clasp is an answer set solver for (extended) normal logic
Later another CLASP: Common LISP as simulation program (CLASP)