Lua is faster than Fortran???
in [Python]
|
From: Stefan Behnel on 13 Jul 2010 02:37 sturlamolden, 04.07.2010 05:30: > 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... In case anyone's interested, I uploaded a wrapper for LuaJIT2 to PyPI: http://pypi.python.org/pypi/lupa It's written in Cython and heavily borrows from the existing Lua wrapper LunaticPython, with a couple of enhancements and a couple of yet missing features. Stefan
From: Luis M. González on 13 Jul 2010 11:38
On Jul 4, 6:09 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > 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/ > > signature.asc > < 1KViewDownload This is a very good explanation of what Lua is and how it differs from python. It all comes down to what you are looking for in a language. Simplicity of use or simplicity of implementation? Python gives you all the tools to code your algorithm right now with the least delay an with minimal effort, at the expense of some performance penalty. Lua is lean and fast, but if you need to use classes, or list comprehensions or some other cool features easily found in python, you have to code them yourself before using them. Perhaps you don't need them and you prefer a more spartan language in favor of speed and performance, and that's ok. Actually, this is what Lua is for. You may find that coding your own helper functions in Lua are not that difficult, but you have to do it. Basically, both languages are very similar, and their grammar is almost identical in their simplest aspects. But as soon as you start working with Lua, you wish you had all the missing python features. I see Lua as a some sort of minimal Python. It looks like a simplified subset of python. Being simpler, it's also easier to implement efficiently. Note that Lua was created a simple language to be embedded into larger applications written in c or c++. So it doesn't need a standard library, since you would be using libraries built for the main aplication, written in c or c++. However it worth noting that, according to Mike Pall (the creator of Luajit), there's no reason to believe Python could not be as fast a Luajit. It has no show stoppers. It would simply require much more work around its corner cases, being the main difficulties in python's own environment, not in the core language. This is all explained in the above mentioned thread on tracing jits... Luis |