3 ms·
I've heard this claim several times, but there seems to be very little evidence to support it. The fast native code Lisp compilers such as SBCL and Lispworks s
by jd 18y ago
I've heard this claim several times, but there seems to be very little evidence to support it.
The fast native code Lisp compilers such as SBCL and Lispworks sacrifice correctness for speed. You can fully expect the VM to crash when you give incorrect hints to the compiler. This is obviously unacceptable for languages such as Ruby and Python. I don't know of any serious Lisp JIT compilers.
Smalltalk has never had decent performance as far as I know - not even with a JIT backend. Not compared to Java/C# with JIT compilation at least.
So yes, my claim is that languages such as Python and Ruby are inherently slower than languages such as C# and Java. The less information the compiler has to work with, the fewer optimizations can be made.
- amix 18y ago"Smalltalk has never had decent performance as far as I know - not even with a JIT backend. Not compared to Java/C# with JIT compilation at least." This is largely because the team that did a JIT enabled Smalltalk dropped it and started to work on a JIT enabled VM for Java. This team got bought by Sun in the 90's and their Java VM was HotSpot, which is used in Java today. As somebody else notes, a lot of the optimizations used in JVM come from dynamic languages such as Smalltalk and Self...
- gruseom 18y agoSmalltalk has never had decent performance as far as I know I don't know what you mean by "decent". Strongtalk was widely regarded as highly performant in its day, certainly far beyond what had been thought possible for a Smalltalk. Its techniques are now being applied to produce impressive gains in contemporary dynamic languages (Maglev, V8). Given that Python and Ruby are in loosely the same class of dynamicness as Smalltalk and JS, I think that's plenty of evidence. Point taken about native Lisp compilation, though.