From: sturlamolden on
On 4 Jul, 19:02, Stefan Behnel <stefan...(a)behnel.de> wrote:

> 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).

Here is what they say:

Benchmark CPython Unladen Change
2to3 25.13 s 24.87 s 1.01x faster
django 1.08 s 0.68 s 1.59x faster
html5lib 14.29 s 13.20 s 1.08x faster
nbody 0.51 s 0.28 s 1.84x faster
rietveld 0.75 s 0.55 s 1.37x faster
slowpickle 0.75 s 0.55 s 1.37x faster
slowspitfire 0.83 s 0.61 s 1.36x faster
slowunpickle 0.33 s 0.26 s 1.26x faster
spambayes 0.31 s 0.34 s 1.10x slower




From: Stefan Behnel on
sturlamolden, 04.07.2010 19:10:
> On 4 Jul, 19:02, Stefan Behnel wrote:
>
>> 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).
>
> Here is what they say:
>
> Benchmark CPython Unladen Change
> 2to3 25.13 s 24.87 s 1.01x faster
> django 1.08 s 0.68 s 1.59x faster
> html5lib 14.29 s 13.20 s 1.08x faster
> nbody 0.51 s 0.28 s 1.84x faster
> rietveld 0.75 s 0.55 s 1.37x faster
> slowpickle 0.75 s 0.55 s 1.37x faster
> slowspitfire 0.83 s 0.61 s 1.36x faster
> slowunpickle 0.33 s 0.26 s 1.26x faster
> spambayes 0.31 s 0.34 s 1.10x slower

Ok, so, which of those do you care about?

Stefan

From: Paul Rubin on
"D'Arcy J.M. Cain" <darcy(a)druid.net> writes:
>> I find LUA quite interesting: instead of providing a language simple
>> to develop in, it focuses heavily on implementation simplicity. Maybe
>> that's the reason why it could be done at all by a single person.
>
> Is that really true about LUA? I haven't looked that closely at it but
> that paragraph probably turned off most people on this list to LUA.

I would say Lua focuses on implementation compactness; it's intended as
an embedded scripting interpreter. It's easy to sandbox and uses just
50k or so of memory. It's running in a lot of mobile phones, cameras,
etc. The language itself is nowhere near as featureful as Python and I
wouldn't want to use it for large scale development, but it appears
pretty good for what it was intended for.

Interestingly, it doesn't have lists or arrays. Its only container
structure is comparable to a Python dictionary. Arrays are just the
special case of dictionaries indexed by numbers. There is a little bit
of syntax sugar to help with that, but it's just the dict structure
underneath.

I wouldn't say it was all done by one person though, and in particular
I think LuaJIT was done by a different group than the main Lua developers.
From: sturlamolden on
On 4 Jul, 19:51, Stefan Behnel <stefan...(a)behnel.de> wrote:

> Ok, so, which of those do you care about?

I have already said I don't care about unladen swallow.


From: Luis M. González on
On Jul 4, 12:30 am, sturlamolden <sturlamol...(a)yahoo.no> wrote:
> I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
> median) beating Intel Fortran!
>
> C (gcc) is running the benchmarks faster by less than a factor of two.
> Consider that Lua is a dynamically typed scripting language very
> similar to Python.
>
> LuaJIT also runs the benchmarks faster than Java 6 server, OCaml, and
> SBCL.
>
> I know it's "just a benchmark" but this has to count as insanely
> impressive. Beating Intel Fortran with a dynamic scripting language,
> how is that even possible? And what about all those arguments that
> dynamic languages "have to be slow"?
>
> If this keeps up we'll need a Python to Lua bytecode compiler very
> soon. And LuaJIT 2 is rumoured to be much faster than the current...
>
> Looking at median runtimes, here is what I got:
>
>    gcc               1.10
>
>    LuaJIT            1.96
>
>    Java 6 -server    2.13
>    Intel Fortran     2.18
>    OCaml             3.41
>    SBCL              3.66
>
>    JavaScript V8     7.57
>
>    PyPy             31.5
>    CPython          64.6
>    Perl             67.2
>    Ruby 1.9         71.1
>
> The only comfort for CPython is that Ruby and Perl did even worse.

You should read this thread: http://lambda-the-ultimate.org/node/3851
There, you'll see this subject discussed and explained at length.
Pay special attention to Mike Pall's comments (he is the creator of
Luajit) and his opinion about python and pypy.
You will read also about other projects, specially new javascript
engines such as Mozila's Tracemonkey (the authors participate in this
thread) and the pypy folks.
It is a very good read for anyone interested in the subject. Very
recommended!
Good luck!

Luis