Lua is faster than Fortran???
in [Python]
|
From: sturlamolden on 4 Jul 2010 12:21 On 4 Jul, 14:29, David Cournapeau <courn...(a)gmail.com> wrote: > Actually, I think the main reason why Lua is much faster than other > dynamic languages is its size. The language is small. You don't list, > dict, tuples, etc... They have managed to combine list and dict into one type (table) that does the job of both. And yes there are tuples. There are no classes, but there are closures and other building blocks that can be used to create any object-oriented type system (just like CLOS is defined by Lisp, not a part of the basic Lisp syntax). So I imagine it would be possible to define an equivalent to the Python type system in Lua, and compile Python to Lua. Lua can be compiled to Lua byte code. Factoring Lua, out that means we should be able to compile Python to Lua byte code.
From: David Cournapeau on 4 Jul 2010 12:34 On Mon, Jul 5, 2010 at 1:12 AM, sturlamolden <sturlamolden(a)yahoo.no> wrote: > On 4 Jul, 10:03, Stefan Behnel <stefan...(a)behnel.de> wrote: > >> Sort of. One of the major differences is the "number" type, which is (by >> default) a floating point type - there is no other type for numbers. The >> main reason why Python is slow for arithmetic computations is its integer >> type (int in Py3, int/long in Py2), which has arbitrary size and is an >> immutable object. So it needs to be reallocated on each computation. > > That is why Lua got it right. A floating point type has a mantissa and > can duck type an integer. MATLAB does the same. I sincerly doubt it - where do take the information that matlab use float to represent int ? It would not be able to represent the full range of 64 bits integer for example. David
From: sturlamolden on 4 Jul 2010 12:37 On 4 Jul, 09:12, Rami Chowdhury <rami.chowdh...(a)gmail.com> wrote: > Out of curiosity, does anyone know how the Unladen Swallow version of Python > does by comparison? Judging from their PyCon slides, it's roughly 1.5 times faster than CPython. That might be important to Google, but not to me.
From: sturlamolden on 4 Jul 2010 12:50 On 4 Jul, 18:34, David Cournapeau <courn...(a)gmail.com> wrote: > I sincerly doubt it - where do take the information that matlab use > float to represent int ? I've used Matlab since 1994, so I know it rather well... Only the recent versions can do arithmetics with number types different from double (or complex double). > It would not be able to represent the full > range of 64 bits integer for example. There is a 53 bit mantissa plus a sign bit. Nobody complained on 32 bit systems. That is, when the signed 54 bit integer contained in a double was overflowed, there was a loss of precision but the numerical range would still be that of a double. You get an unsigned integer in MATLAB like this x = uint64(0) but until recently, MATLAB could not do any arithmetics with it. It was there for interaction with Java and C MEX files. A long double has a mantissa of 64 bit however, so it can represent signed 65 bit integers without loss of precision.
From: Stefan Behnel on 4 Jul 2010 13:02
sturlamolden, 04.07.2010 18:37: > On 4 Jul, 09:12, Rami Chowdhury wrote: > >> Out of curiosity, does anyone know how the Unladen Swallow version of Python >> does by comparison? > > Judging from their PyCon slides, it's roughly 1.5 times faster than > CPython. A number like "1.5 times faster" is meaningless without a specific application and/or code section in mind. I'm pretty sure there are cases where they are much faster than that, and there are cases where the net gain is zero (or -0.x or whatever). Stefan |