Lua is faster than Fortran???
in [Python]
|
From: Stefan Behnel on 4 Jul 2010 15:59 sturlamolden, 04.07.2010 21:44: > On 4 Jul, 19:51, Stefan Behnel wrote: >> Ok, so, which of those do you care about? > > I have already said I don't care about unladen swallow. What I meant, was: which of these benchmarks would have to be better to make you care? Because your decision not to care seems to be based on exactly these benchmarks. Stefan
From: Luis M. González on 4 Jul 2010 16:04 On Jul 4, 4:51 pm, Luis M. González <luis...(a)gmail.com> wrote: > 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 To be more specific, check these comments on the above the above suggested thread: http://lambda-the-ultimate.org/node/3851#comment-57804 http://lambda-the-ultimate.org/node/3851#comment-57700 Luis
From: Stephen Hansen on 4 Jul 2010 17:09 On 7/4/10 9:21 AM, sturlamolden wrote: > 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. You say "managed" as if it were some technical accomplishment, or that the result is able to actually do the job of both: neither of these assertions are true. Have you actually *used* Lua? I quite like the language in certain contexts where its appropriate, but if you've actually used it in real code and found tables to be at all a substitute for *either* dictionaries *or* lists, then I think somehow you've managed to actually miss using either data structure in Python to any real extent, somehow. Lua's tables are at very weak "dictionary-like" and "list-like" objects, which indeed have been folded into one. To the detriment of both, at least as far as they are an actual useful data structure. You can't even get the equivalent of len(dict) in it: you have to actually brute-force iterate the table and count manually. Even for a purely array-like table with onlyn umbered indexes, #table can be unreliable: its quite possible through normal list-like operations that you perform on it, it can end up with holes where #table will fail. Since it is *not* an list internally at *all*, but simply an associative array with numbered indexes. I could go on, and on, and on: but the fundamental *weakness* of Lua' data types as data-structures is irrefutable, from its tables to strings to numbers: they are incredibly weak on capabilities. You end up writing all kinds of "library" functions to just do the normal things that should be really easy to do. Now, of course, there's really good reason why Lua is so simple in these ways. Its entirely suitable for Lua as an embedded scripting language to keep things very light, so it can be simple and fast. Good for Lua to fill this niche superbly. But you can't start saying its simple alternatives are at all comparable to Python's extremely rich and capable data types. > And yes there are tuples. No, there isn't. There's ways to create a tuple-like-thing which kind of behaves like a braindead tuple, and functions have a positively bizarre capability of returning more then one value (and accepting variable values), so there's these points in the language where you have this sort of Immutable Sequence, but its opaque until you unwrap it -- and then it ceases to be. That's not the same thing as having an immutable sequence that you can store data in at your discretion, with a rich series of capabilities that you can leverage. > There are no classes, but there are closures and other building blocks > that can be used to create any object-oriented type system Not really. Above, I spoke of tables as data structures, things just storing data. But you're right, they are capable of more then that-- but you're over-selling just how far that capability goes, by a long shot (and underselling just how much work it takes to get it there). Yes, tables have a limited series of 'hooks' that you can tie into to alter their behavior, and through this you can simulate certain higher order type systems as defined in other languages. In fact, lots of people have done this: there's multiple "classy" libraries out there to bring some kind of Class-or-Object-Oriented-Programming to Lua. They work to varying degrees: but the hooks that Lua provides to tables is still significantly lacking to really replace Python's comprehensively dynamic object model, without a LOT of wasted cycles. For example, while you can use __newindex to 'catch' someone setting a new 'key' on a table, and and __index to replace or forward the actual lookup, you can't actually capture someone trying to set a value to a key which already exists. So, you end up having to do a full proxy approach, where your table never actually stores anything directly (except a reference to another hidden table), and so when someone goes to set something you have to set it on the proxied object instead. Because you can't let there ever be any real keys on the proxying / external table. So you're able to work around its lack a bit, to simulate something /like/ what it means to have __setattr__. But then you run into problems. There's no way now to iterate over the table now, because pairs() will only return your internal hidden keys that you're using to point to the proxied table (Although you can get around this with some more complexity by hiding said key into a closure-- but even then, you still can't iterate over the proxied table's keys instead). So what do you do? Well you go replace the global "pairs" function, that's what you do! So it learns your particular style of Classness, and interacts well. Hope you never use any third-party code which has even a vaguely different kind of Classness. Alternately, you can just decide to never use the standard idiom of iteration for your classes, and instead one must always "for x in my_table:iter()" -- so now you have one kind of code operating on 'real' tables, and a totally different kind operating on your 'classy tables'. And on and on. The point is, sure. Lua can sort of simulate different OOP approaches, and Lua-folk are very adept at tweaking, twisting, turning and ripping tables into all kinds of pseudo-data types that match other paradigms, but its all hacks on top of hacks on top of hacks. You end up with some *really* weird and/or messy code if you try. Better to do Lua in Lua, instead of Python in Lua, or Java in Lua. (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. > > > > -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Luis M. González on 8 Jul 2010 14:52 On Jul 4, 5:58 pm, John Nagle <na...(a)animats.com> wrote: > TheUnladenSwallowpeople should in theory be able to reach > that level of performance. (Both groups are employed at Google. > So their effectiveness will be compared.) > > John Nagle No. Collin Winter said that they will never be as fast as Chrome's V8 or similar JS engines, since they were created from scratch to be super fast above all else. On the other hand, US is a project to enhance an existing interpreter, carrying a lot of the burden of early design decisions.
From: sturlamolden on 8 Jul 2010 16:15
On 4 Jul, 21:59, Stefan Behnel <stefan...(a)behnel.de> wrote: > > I have already said I don't care about unladen swallow. > > What I meant, was: which of these benchmarks would have to be better to > make you care? Because your decision not to care seems to be based on > exactly these benchmarks. Those are the only one I've seen. |