At a crossroad

[Daniel Keep]

dsimcha wrote:
> == Quote from bearophile (bearophileHUGS at lycos.com)'s article
>> dsimcha:
>>> Python and Ruby
>>> are constrained by their dynamic design such that they will likely always be slow
>>> and there is no room for improvement.
>> This is the opposite of the truth :-)
>> Being Python slow, there can be ways to speed it up. Being D fast, there's
> little room from improvement. See unladen swallow project, for example:
>> http://code.google.com/p/unladen-swallow/
>> Or Just Psyco:
>> http://psyco.sourceforge.net/
>> Bye,
>> bearophile
> 
> Sorry, I misspoke slightly.  I meant that these languages will never be in the
> same league as D, not that they will never be faster than they are now.  Of
> course, they can be made *somewhat* faster, but all the fancy stuff they do at
> runtime is pretty limiting in terms of performance optimizations.

You might be surprised...

http://lua-users.org/lists/lua-l/2009-06/msg00071.html

For those who are allergic to reading:

Language        SciMark score (larger is better)
=============== ================================
Lua 5.1.4        13.87
LuaJIT 1.1.x     89.80
LuaJIT 2 [1]    425.11
C [2]           604.44

LuaJIT 2 is getting perilously close to C.  That's a language with no
static typing (not even optional), no compile step; it doesn't even have
classes to help the JIT.

Here's the thing: tracing JITs can theoretically BEAT C.  Why?  Because
a tracing JIT knows more about the system the program is running on than
a compiler ever will.  It knows which parts of the code are being hit
the hardest.  It can even inline whole inner loops across function and
module boundaries.

Saying dynamic languages will never be in the same league as D is just
ASKING to be proven wrong.  :D



[1] Still under development; that result is from early this month.

[2] Compiled with GCC 4.3.2 with -march=core2 -O3 -fomit-frame-pointer