From: sturlamolden on 4 Jul 2010 13:10 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 4 Jul 2010 13:51 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 4 Jul 2010 14:26 "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 4 Jul 2010 15:44 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 4 Jul 2010 15:51
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 |