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
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.
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
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
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
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
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
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
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
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
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
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
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
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++
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
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
* 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
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
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
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
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
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,
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/
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
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
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,
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
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
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.
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
43 matches
Mail list logo
