Re: Lua is faster than Fortran???
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 6:09 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote: On 7/4/10 9:21 AM, sturlamolden wrote: On 4 Jul, 14:29, David Cournapeau courn...@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
Re: Lua is faster than Fortran???
On the positive side, Lua supports tail call optimization and coroutines are built in by default. -- дамјан ((( http://damjan.softver.org.mk/ ))) Education is one of the prices of freedom that some are unwilling to pay. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 9, 1:16 am, sturlamolden sturlamol...@yahoo.no wrote: On 9 Jul, 05:39, Felix schle...@cshl.edu wrote: For an outsider it does not look like a solution to the GIL mess or a true breakthrough for performance are around the corner (even though there seem to be many different attempts at working around these problems or helping with parts). Am I wrong? Yes you are. We don't do CPU intensive work in pure Python. We use Python to control C and Fortran libraries. That gives us the opportunity to multi-thread in C, release the GIL and multi-thread in Python, or both. Yes, this setup works very well and is (as I said) probably the reason python is so widely used in scientific computing these days. However I find that I can almost never do everything with vector operations, but have to iterate over data structures at some point. And here the combination of CPython slowness and the GIL means either bad performance or having to write this in C (with which cython helps fortunately). If it were possible to write simple, parallel, reasonably fast loops in (some subset of) python directly that would certainly be a great advantage. Given the performance of other JITs it sounds like it should be possible, but maybe python is too complex to make this realistic. Felix PS: No need to convince me that MATLAB is not the solution. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 9, 12:44 am, Stefan Behnel stefan...@behnel.de wrote: Felix, 09.07.2010 05:39: Well, at least its parallel processing abilities are quite good actually. If you have really large computations, they usually run on more than one computer (not just more than one processor). So you can't really get around using something like MPI, in which case an additional threading layer is basically worthless, regardless of the language you use. For computations, threading keeps being highly overrated. That is certainly true for large computations. But many smaller tasks are run on single machines and it does make a difference if they take 1 minute per run or 10. The average number of cores per computer has been increasing for quite a while now. It seems unfortunate to be restricted to using only one of them at a time (for regular loops, not mathematical vector operations). Python has made so many complicated things easy, but I have not seen an easy way to parallelize a simple loop on a multicore CPU without having to set up infrastructure and/or incurring large overhead from many interpreters and marshalling data. Just the fact that there is such a large number of attempts out there to fix this suggests that something important is missing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 9 Jul, 15:25, Felix schle...@cshl.edu wrote: PS: No need to convince me that MATLAB is not the solution. What I mean is that Matlab and Mathematica are inherently single threaded interpreters. Yet they are still used for serious parallel computing. While Python has multiple threads but a GIL, only allowing one thread in the interpreter is even more restrictive. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 7/9/2010 1:25 AM, sturlamolden wrote: With OpenCL, Python is better than C for heavy computing. The Python or C/C++ program has to supply OpenCL code (structured text) to the OpenCL driver, which does the real work on GPU or CPU. Python is much better than C or C++ at processing text. There will soon be OpenCL drivers for most processors on the market. For those as ignorant as me, OpenCL = Open Computing Language (for parallel computing). Apple proposed, Khronos Group maintains spec (along with OpenGL), AMD, NVidea, Intel support. Send C-like text to device, as with OpenGL; device compiles and runs; mainly for number crunching with all resources a machine has. OpenCL and OpenGL can work together. There is already a Python binding: http://sourceforge.net/projects/pyopencl/ But OpenCL drivers will not be pre-installed on Windows, as Microsoft has a competing COM-based technology (DirectX Compute, with an atrocious API and syntax). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Fri, Jul 9, 2010 at 5:10 PM, Terry Reedy tjre...@udel.edu wrote: On 7/9/2010 1:25 AM, sturlamolden wrote: With OpenCL, Python is better than C for heavy computing. The Python or C/C++ program has to supply OpenCL code (structured text) to the OpenCL driver, which does the real work on GPU or CPU. Python is much better than C or C++ at processing text. There will soon be OpenCL drivers for most processors on the market. For those as ignorant as me, OpenCL = Open Computing Language (for parallel computing). Apple proposed, Khronos Group maintains spec (along with OpenGL), AMD, NVidea, Intel support. Send C-like text to device, as with OpenGL; device compiles and runs; mainly for number crunching with all resources a machine has. OpenCL and OpenGL can work together. There is already a Python binding: http://sourceforge.net/projects/pyopencl/ Its worth pointing out that right now you're generally better off with CUDA than OpenCL, and that pycuda bindings are usable, if not what I would call easy-to-use. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 5:58 pm, John Nagle na...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 21:59, Stefan Behnel stefan...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 11:25 am, David Cournapeau courn...@gmail.com wrote: On Mon, Jul 5, 2010 at 12:00 AM, D'Arcy J.M. Cain da...@druid.net wrote: I wish it was orders of magnitude faster for web development. I'm just saying that places where we need compiled language speed that Python already has that in C. Well, I wish I did not have to use C, then :) For example, as a contributor to numpy, it bothers me at a fundamental level that so much of numpy is in C. This is something that I have been thinking about recently. Python has won quite a following in the scientific computing area, probably especially because of great libraries such as numpy, scipy, pytables etc. But it also seems python itself is falling further and further behind in terms of performance and parallel processing abilities. Of course all that can be fixed by writing C modules (e.g. with the help of cython), but that weakens the case for using python in the first place. For an outsider it does not look like a solution to the GIL mess or a true breakthrough for performance are around the corner (even though there seem to be many different attempts at working around these problems or helping with parts). Am I wrong? If not, what is the perspective? Do we need to move on to the next language and loose all the great libraries that have been built around python? Felix -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
Felix, 09.07.2010 05:39: On Jul 4, 11:25 am, David Cournapeau wrote: Well, I wish I did not have to use C, then :) For example, as a contributor to numpy, it bothers me at a fundamental level that so much of numpy is in C. This is something that I have been thinking about recently. Python has won quite a following in the scientific computing area, probably especially because of great libraries such as numpy, scipy, pytables etc. But it also seems python itself is falling further and further behind in terms of performance and parallel processing abilities. Well, at least its parallel processing abilities are quite good actually. If you have really large computations, they usually run on more than one computer (not just more than one processor). So you can't really get around using something like MPI, in which case an additional threading layer is basically worthless, regardless of the language you use. For computations, threading keeps being highly overrated. WRT a single machine, you should note that GPGPUs are a lot faster these days than even multi-core CPUs. And Python has pretty good support for GPUs, too. Of course all that can be fixed by writing C modules (e.g. with the help of cython), but that weakens the case for using python in the first place. Not at all. Look at Sage, for example. It's attractive because it provides tons of functionality, all nicely glued together through a simple language that even non-programmers can use efficiently and effectively. And its use of Cython makes all of this easily extensible without crossing the gap of a language border. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 9 Jul, 05:39, Felix schle...@cshl.edu wrote: This is something that I have been thinking about recently. Python has won quite a following in the scientific computing area, probably especially because of great libraries such as numpy, scipy, pytables etc. Python is much more friendly to memory than Matlab, and a much nicer language to work in. It can also be used to program more than just linear algebra. If you have to read data from a socket, Matlab is not so fun anymore. But it also seems python itself is falling further and further behind in terms of performance and parallel processing abilities. First, fine-grained parallelism really belongs in libraries like MKL, GotoBLAS and FFTW. Python can manage the high-level routines just like Matlab. You can call a NumPy routine like np.dot, and the BLAS library (e.g. Intel MKL) will do the multi-threading for you. We almost always use Python to orchestrate C and Fortran. We can use OpenMP in C or Fortran, or we can just release the GIL and use Python threads. Second, the GIL it does not matter for MPI, as it works with processes. Nor does it matter for os.fork or multiprocessing. On clusters, which are as common in high-performance computing as SMP systems, one has to use processes (usually MPI) rather than threads, as there is no shared memory between processors. On SMP systems, MPI can use shared-memory and be just as efficient as threads (OpenMP). (MPI is usually faster due to cache problems with threads.) Consider that Matlab does not even have threads (or did not last time I checked). Yet it takes advantage of multi-core CPUs for numerical computing. It's not the high-level interface that matters, it's the low-level libraries. And Python is just that: a high-level glue language. For an outsider it does not look like a solution to the GIL mess or a true breakthrough for performance are around the corner (even though there seem to be many different attempts at working around these problems or helping with parts). Am I wrong? Yes you are. We don't do CPU intensive work in pure Python. We use Python to control C and Fortran libraries. That gives us the opportunity to multi-thread in C, release the GIL and multi-thread in Python, or both. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 9 Jul, 06:44, Stefan Behnel stefan...@behnel.de wrote: WRT a single machine, you should note that GPGPUs are a lot faster these days than even multi-core CPUs. And Python has pretty good support for GPUs, too. With OpenCL, Python is better than C for heavy computing. The Python or C/C++ program has to supply OpenCL code (structured text) to the OpenCL driver, which does the real work on GPU or CPU. Python is much better than C or C++ at processing text. There will soon be OpenCL drivers for most processors on the market. But OpenCL drivers will not be pre-installed on Windows, as Microsoft has a competing COM-based technology (DirectX Compute, with an atrocious API and syntax). -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Saturday 03 July 2010 20:30:30 sturlamolden wrote: I was just looking at Debian's benchmarks. It seems LuaJIT is now (on median) beating Intel Fortran! That's amazing! Congrats to the Lua team! 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: [snip] The only comfort for CPython is that Ruby and Perl did even worse. Out of curiosity, does anyone know how the Unladen Swallow version of Python does by comparison? Rami Chowdhury Given enough eyeballs, all bugs are shallow. -- Linus' Law +1-408-597-7068 / +44-7875-841-046 / +88-01819-245544 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
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. 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. If it was easily mappable to a CPU integer, Python implementations could just do that and be fast. But its arbitrary size makes this impossible (or requires a noticeable overhead, at least). The floating point type is less of a problem, e.g. Cython safely maps that to a C double already. But the integer type is. So it's not actually surprising that Lua beats CPython (and the other dynamic languages) in computational benchmarks. It's also not surprising to me that a JIT compiler beats a static compiler. A static compiler can only see static behaviour of the code, potentially with an artificially constructed idea about the target data. A JIT compiler can see the real data that flows through the code and can optimise for that. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
* 2010-07-04 10:03 (+0200), Stefan Behnel wrote: 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. If it was easily mappable to a CPU integer, Python implementations could just do that and be fast. But its arbitrary size makes this impossible (or requires a noticeable overhead, at least). The floating point type is less of a problem, e.g. Cython safely maps that to a C double already. But the integer type is. You may be right. I'll just add that Common Lisp's integers are of arbitrary size too but programmer can declare them as fixnums. Such declarations kind of promise that the numbers really are between most-negative-fixnum and most-positive-fixnum. Compiler can then optimize the code to efficient machine instructions. I guess Python might have use for some sort of (defun foo (variable) (declare (type fixnum variable)) ...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sun, Jul 4, 2010 at 5:03 PM, Stefan Behnel stefan...@behnel.de wrote: 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. 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. If it was easily mappable to a CPU integer, Python implementations could just do that and be fast. But its arbitrary size makes this impossible (or requires a noticeable overhead, at least). The floating point type is less of a problem, e.g. Cython safely maps that to a C double already. But the integer type is. 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... Making 50 % of python fast is easy (in the sense that it has been done). I would not be surprised if it is exponentially harder the closer you get to 100 %. Having a small language means that the interpreter is small - small enough to be kept in L1, which seems to matter a lot (http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0). If you are interested in facts and technical details (rather than mere speculations), this thread is interesting http://lambda-the-ultimate.org/node/3851. It has participation of LuaJIT author, Pypy author and Brendan Eich :) It's also not surprising to me that a JIT compiler beats a static compiler. A static compiler can only see static behaviour of the code, potentially with an artificially constructed idea about the target data. A JIT compiler can see the real data that flows through the code and can optimise for that. Although I agree that in theory, it is rather obvious that a JIT compiler can do many things that static analysis cannot, this is the first time it has happened in practice AFAIK. Even hotspot was not faster than fortran and C, and it has received tons of work by people who knew what they were doing. The only example of a dynamic language being as fast/faster than C that I am aware of so far is Staline, the aggressive compiler for scheme (used in signal processing in particular). David -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 04 Jul 2010 04:15:57 GMT Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Need is a bit strong. There are plenty of applications where if your code takes 0.1 millisecond to run instead of 0.001, you won't even notice. Or applications that are limited by the speed of I/O rather than the CPU. Which is 99% of the real-world applications if you factor out the code already written in C or other compiled languages. That's the point of Python after all. You speed up programming rather than programs but allow for refactoring into C when necessary. And it's not call CPython for nothing. off-the-shelf benchmarks are fun but mostly useless for choosing a language, priogram, OS or machine unless you know that it checks the actual things that you need in the proportion that you need. But I'm nitpicking... this is a nice result, the Lua people should be proud, and I certainly wouldn't say no to a faster Python :) Ditto, ditto, ditto and ditto. It's not like this is a race, and speed is not the only thing which a language is judged by. Otherwise you'd be programming in C, not Python, right? Or assembler. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain da...@druid.net wrote: On 04 Jul 2010 04:15:57 GMT Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Need is a bit strong. There are plenty of applications where if your code takes 0.1 millisecond to run instead of 0.001, you won't even notice. Or applications that are limited by the speed of I/O rather than the CPU. Which is 99% of the real-world applications if you factor out the code already written in C or other compiled languages. This may be true, but there are areas where the percentage is much lower. Not everybody uses python for web development. You can be a python fan, be reasonably competent in the language, and have good reasons to wish for python to be one order of magnitude faster. 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. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
sturlamolden sturlamol...@yahoo.no wrote in message news:daa07acb-d525-4e32-91f0-16490027c...@w12g2000yqj.googlegroups.com... 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 LuaJIT1.96 Java 6 -server2.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. I didn't see the same figures; LuaJIT seem to be 4-5 times as slow as one of the C's, on average. Some benchmarks were slower than that. But I've done my own brief tests and I was quite impressed with LuaJIT which seemed to outperform C on some tests. I'm developing my own language and LuaJIT is a new standard to beat for this type of language. However, Lua is quite a lightweight language with minimalist data types, it doesn't suit everybody. I suspect also the Lua JIT compiler optimises some of the dynamicism out of the language (where it can see, for example, that something is always going to be a number, and Lua only has one numeric type with a fixed range), so that must be a big help. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sun, 4 Jul 2010 23:46:10 +0900 David Cournapeau courn...@gmail.com wrote: On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain da...@druid.net wrote: Which is 99% of the real-world applications if you factor out the code already written in C or other compiled languages. This may be true, but there are areas where the percentage is much lower. Not everybody uses python for web development. You can be a python fan, be reasonably competent in the language, and have good reasons to wish for python to be one order of magnitude faster. I wish it was orders of magnitude faster for web development. I'm just saying that places where we need compiled language speed that Python already has that in C. But, as I said in the previous message, in the end it is up to you to write your own benchmark based on the operations you need and the usage patterns you predict that it will need as well. If your application needs to calculate Pi to 100 places but only needs to do it once there is no need to include that in your benchmark a million times. A language that is optimized for calculating Pi shouln't carry a lot of weight for you. 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. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sat, 3 Jul 2010 20:30:30 -0700 (PDT) sturlamolden sturlamol...@yahoo.no wrote: CPython 64.6 By the way, I assume that that's Python 2.x. I wonder how Python 3.1 would fare. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Mon, Jul 5, 2010 at 12:00 AM, D'Arcy J.M. Cain da...@druid.net wrote: On Sun, 4 Jul 2010 23:46:10 +0900 David Cournapeau courn...@gmail.com wrote: On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain da...@druid.net wrote: Which is 99% of the real-world applications if you factor out the code already written in C or other compiled languages. This may be true, but there are areas where the percentage is much lower. Not everybody uses python for web development. You can be a python fan, be reasonably competent in the language, and have good reasons to wish for python to be one order of magnitude faster. I wish it was orders of magnitude faster for web development. I'm just saying that places where we need compiled language speed that Python already has that in C. Well, I wish I did not have to use C, then :) For example, as a contributor to numpy, it bothers me at a fundamental level that so much of numpy is in C. Also, there are some cases where using C for speed is very difficult, because the marshalling cost almost entirely alleviate the speed advantages - that means you have to write in C more than you anticipated. Granted, those may be quite specific to scientific applications, and cython already helps quite a fair bit in those cases. But, as I said in the previous message, in the end it is up to you to write your own benchmark based on the operations you need and the usage patterns you predict that it will need as well. If your application needs to calculate Pi to 100 places but only needs to do it once there is no need to include that in your benchmark a million times. I would question the sanity of anyone choosing a language because it can compute Pi to 100 places very quickly :) I am sure google search would beat most languages if you count implementation + running time anyway. 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 hope I did not turn anyone off - but it is definitely not the same set of tradeoff as python. LUA runtime is way below 1 Mb, for example, which is one reason why it is so popular for video games. The following presentation gives a good overview (by LUA creator): http://www.stanford.edu/class/ee380/Abstracts/100310-slides.pdf To go back to the original topic: a good example is numeric types. In python, you have many different numerical types with different semantics. In LUA, it is much simpler. This makes implementation simpler, and some aggressive optimizations very effective. The fact that a LUA interpreter can fit in L1 is quite impressive. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 16:47, bart.c ba...@freeuk.com wrote: I suspect also the Lua JIT compiler optimises some of the dynamicism out of the language (where it can see, for example, that something is always going to be a number, and Lua only has one numeric type with a fixed range), so that must be a big help. Python could do the same, replace int and float with a long double. It is 80 bit and has a 64 bit mantissa. So it can in theory do the job of all floating point types and integers up to 64 bit (signed and unsigned). A long double can 'duck type' all the floating point and integer types we use. There is really no need for more than one number type. For an interpreted language, it's just a speed killer. Other number types belong in e.g. the ctypes, array, struct and NumPy modules. Speed wise a long double (80 bit) is the native floating point type on x86 FPUs. There is no penalty memory-wise either, wrapping an int as PyObject takes more space. For a dynamic language it can be quite clever to just have one 'native' number type, observing that the mantissa of a floating point number is an unsigned integer. That takes a lot of the dynamicity out of the equation. Maybe you like to have integers and floating point types in the 'language'. But that does not mean it should be two types in the 'implementation' (i.e. internally in the VM). The implementation could duck type both with a suffciently long floating point type, and the user would not notice in the syntax. MATLAB does the same as Lua. Native number types are always double, you have to explicitly create the other. Previously they did not even exist. Scientists have been doing numerical maths with MATLAB for decades. MATLAB never prevented me from working with integers mathematically, even if I only worked with double. If I did not know, I would not have noticed. a = 1; % a is a double a = 1 + 1; % a is a double and exactly 2 a = int32(1); Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 10:03, Stefan Behnel stefan...@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. Sturla If it was easily mappable to a CPU integer, Python implementations could just do that and be fast. But its arbitrary size makes this impossible (or requires a noticeable overhead, at least). The floating point type is less of a problem, e.g. Cython safely maps that to a C double already. But the integer type is. So it's not actually surprising that Lua beats CPython (and the other dynamic languages) in computational benchmarks. It's also not surprising to me that a JIT compiler beats a static compiler. A static compiler can only see static behaviour of the code, potentially with an artificially constructed idea about the target data. A JIT compiler can see the real data that flows through the code and can optimise for that. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 14:29, David Cournapeau courn...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Mon, Jul 5, 2010 at 1:12 AM, sturlamolden sturlamol...@yahoo.no wrote: On 4 Jul, 10:03, Stefan Behnel stefan...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 09:12, Rami Chowdhury rami.chowdh...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 18:34, David Cournapeau courn...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 19:02, Stefan Behnel stefan...@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 2to325.13 s 24.87 s 1.01x faster django 1.08 s0.68 s 1.59x faster html5lib14.29 s 13.20 s 1.08x faster nbody0.51 s0.28 s 1.84x faster rietveld 0.75 s0.55 s 1.37x faster slowpickle 0.75 s0.55 s 1.37x faster slowspitfire 0.83 s0.61 s 1.36x faster slowunpickle 0.33 s0.26 s 1.26x faster spambayes0.31 s0.34 s 1.10x slower -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
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 2to325.13 s 24.87 s 1.01x faster django 1.08 s0.68 s 1.59x faster html5lib14.29 s 13.20 s 1.08x faster nbody0.51 s0.28 s 1.84x faster rietveld 0.75 s0.55 s 1.37x faster slowpickle 0.75 s0.55 s 1.37x faster slowspitfire 0.83 s0.61 s 1.36x faster slowunpickle 0.33 s0.26 s 1.26x faster spambayes0.31 s0.34 s 1.10x slower Ok, so, which of those do you care about? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
D'Arcy J.M. Cain da...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 19:51, Stefan Behnel stefan...@behnel.de wrote: Ok, so, which of those do you care about? I have already said I don't care about unladen swallow. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 12:30 am, sturlamolden sturlamol...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 4:51 pm, Luis M. González luis...@gmail.com wrote: On Jul 4, 12:30 am, sturlamolden sturlamol...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 7/4/2010 12:51 PM, Luis M. González wrote: Looking at median runtimes, here is what I got: gcc 1.10 LuaJIT1.96 Java 6 -server2.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. It's embarrassing that Javascript is now 9x faster than Python. Javascript has almost all the dynamic problems that make CPython slow, but they've been overcome in the Javascript JIT compiler. Here's how the Javascript V8 system does it: http://code.google.com/apis/v8/design.html They get rid of unnecessary dictionary lookups for attributes by automatically creating hidden classes which, in Python terms, use slots. If an attribute is added to an object, another hidden class is created with that attribute. Each such class is hard-compiled to machine code while the program is running. So attribute access never requires a dictionary lookup. Adding a new, not-previously-used attribute is a relatively expensive operation, but with most programs, after a while all the new attributes have been added and the program settles down to efficient operation. That's in Google's Chrome browser right now. The Unladen Swallow people 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 7/4/10 9:21 AM, sturlamolden wrote: On 4 Jul, 14:29, David Cournapeau courn...@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
Lua is faster than Fortran???
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 LuaJIT1.96 Java 6 -server2.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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sat, 03 Jul 2010 20:30:30 -0700, sturlamolden wrote: 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? By being clever, using Just In Time compilation as much as possible, and almost certainly using masses of memory at runtime. (The usual trade-off between space and time.) See the PyPy project, which aims to do the same thing for Python as Lua have done. Their ultimate aim is to beat the C compiler and be faster than C. So far they've got a bit to go, but they're currently about twice as fast as CPython. And what about all those arguments that dynamic languages have to be slow? They're bullshit, of course. It depends on the nature of the dynamicism. Some things are inherently slow, but not everything. Fast, tight, dynamic: pick any two. If this keeps up we'll need a Python to Lua bytecode compiler very soon. Need is a bit strong. There are plenty of applications where if your code takes 0.1 millisecond to run instead of 0.001, you won't even notice. Or applications that are limited by the speed of I/O rather than the CPU. But I'm nitpicking... this is a nice result, the Lua people should be proud, and I certainly wouldn't say no to a faster Python :) [...] The only comfort for CPython is that Ruby and Perl did even worse. It's not like this is a race, and speed is not the only thing which a language is judged by. Otherwise you'd be programming in C, not Python, right? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 06:15, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Need is a bit strong. There are plenty of applications where if your code takes 0.1 millisecond to run instead of 0.001, you won't even notice. Or applications that are limited by the speed of I/O rather than the CPU. But I'm nitpicking... this is a nice result, the Lua people should be proud, and I certainly wouldn't say no to a faster Python :) Need might be too strong, sorry. I'm not a native speaker of English :) Don't read this as a complaint about Python being too slow. I don't care about milliseconds either. But I do care about libraries like Python's standard library, wxPython, NumPy, and matplotlib. And when I need C, C++ or Fortran I know where to fint it. Nobody in the scientific community would be sad if Python was so fast that no C or Fortran would have to be written. And I am sure Google and many other users of Python would not mind either. And this is kind of a proof that it can be. Considering that Lua is to Python what C is to C++ (more or less), it means that it is possible to make Python run very fast as well. Yes the LuaJIT team should be proud. Making a scripting language run faster than Fortran on CPU-bound work is a superhuman result. -- http://mail.python.org/mailman/listinfo/python-list
