On Tue, Jun 30, 2009 at 12:17 AM, Daniel Keep<[email protected]> wrote: > > dsimcha wrote: >> == Quote from bearophile ([email protected])'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 >
*jaw drop* Daaaamn.
