Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
You're talking as if this were only theoretical. It is not. The state
of the art in compiler techniques has advanced a lot since the old
days of the Pascal P-Machine. Parakeet, for example[2], compiles
numeric functions to optimized
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable
challenge but not impossible in principle.
Or in
Steven D'Aprano st...@pearwood.info:
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
I'm having a hard time finding information on how well it performs wrt
Java, for example. Did PyPy truly find the Philosophers' Stone?
[...] do you mean, how does PyPy compare with insert name of
Marko Rauhamaa ma...@pacujo.net writes:
Alain Ketterlin al...@dpt-info.u-strasbg.fr:
The real nice thing that makes Julia a different language is the
optional static typing, which the JIT can use to produce efficient code.
It's the only meaningful difference with the current state of python.
Ian Kelly ian.g.ke...@gmail.com wrote:
Also numba, which is reminiscent of psyco, but with more features and
Python 3 support.
For numerical computing with NumPy, Numba tends to give performance
comparable to -O2 in C. This is because it is very easy to do type
inference in most scientific
On 5/13/14 12:48 AM, Steven D'Aprano wrote:
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
fast too), and there are zillions of lines of code
On Tuesday 13 May 2014 01:48:43 Steven D'Aprano did opine
And Gene did reply:
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well
(its fast too
On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
People who write buggy self-modifying code aren't paying attention.
[...]
IMO, people who bad-mouth self-modifying code are folks who don't have
the patience to do it right, because stable self-modifying code CAN most
certainly be done.
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano st...@pearwood.info
wrote:
Self-modifying code is a nightmare inside the head of a Lovecraftian
horror. There's a reason why almost the only people still using self-
modifying code are
On Tue, May 13, 2014 at 7:34 PM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano st...@pearwood.info
wrote:
Self-modifying code is a nightmare inside the head of a Lovecraftian
horror.
On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
Actually, even the file system can do some of this to you. I was
checking lsof on one of my Linux systems a little while ago, and found
that I had half a dozen old versions of a program, all with the same
file name, all
On Tue, May 13, 2014 at 8:44 PM, Rustom Mody rustompm...@gmail.com wrote:
On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
Actually, even the file system can do some of this to you. I was
checking lsof on one of my Linux systems a little while ago, and found
that I had half
In article 5371c834$0$11109$c3e8...@news.astraweb.com,
Steven D'Aprano st...@pearwood.info wrote:
And after 15 years, I daresay that includes you.
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
On Tue, May 13, 2014 at 9:16 PM, Roy Smith r...@panix.com wrote:
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
because nobody knows how it works anymore and everybody is afraid to
touch it :-)
And
On Tuesday 13 May 2014 03:22:28 Steven D'Aprano did opine
And Gene did reply:
On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
People who write buggy self-modifying code aren't paying attention.
[...]
IMO, people who bad-mouth self-modifying code are folks who don't
have the
On 13/05/2014 12:21, Chris Angelico wrote:
On Tue, May 13, 2014 at 9:16 PM, Roy Smith r...@panix.com wrote:
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
because nobody knows how it works anymore and
++
and FORTRAN speeds (even though dynamic) because it is compiling
on-the-fly.
JITing by itself has little impact on performance (as unladden-swallow
has shown for python). For the JIT to produce code as fast as a
Fortan/C/C++ compiler would, two conditions must be met: 1) the JIT has
to have as much
Alain Ketterlin al...@dpt-info.u-strasbg.fr:
The real nice thing that makes Julia a different language is the
optional static typing, which the JIT can use to produce efficient code.
It's the only meaningful difference with the current state of python.
I'm guessing the two main performance
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle.
Or in practice.
http://pypy.org/
And it's predecessor: http://psyco.sourceforge.net/
--
Steven D'Aprano
On Tue, May 13, 2014 at 6:10 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle.
Or in practice.
http://pypy.org/
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle.
Or in practice.
http://pypy.org/
I'm having a hard time finding
, and
the overhead is removed.
But then, you're not too far from Fortran, or C/C++.
The following code will produce over 100,000 digits of π (pi) in less
than 2 seconds on a low-end processor, like my mac mini dual core
2Ghz:
You seem to be discovering the power of the libraries that are behind
all this (MPFR
On 12/05/2014 03:28, Steven D'Aprano wrote:
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote:
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering
On 2014-05-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
The F and J keys have F and J printed on them instead of G and
K. They're also in slightly different positions, offset one
On Sun, 11 May 2014 20:14:14 -0400, Roy Smith wrote:
In article mailman.9900.1399852263.18130.python-l...@python.org,
MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article
part obviously disappears, and
the overhead is removed.
Julia is dynamic (depending on how far you want to go with that)
but what makes it fast is the JIT. It is almost accomplishing C/C++ and
FORTRAN speeds (even though dynamic) because it is compiling on-the-fly.
But then, you're
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
fast too), and there are zillions of lines of code cranking away on huge
linear arrays. Enter
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano st...@pearwood.info wrote:
Self-modifying code is a nightmare inside the head of a Lovecraftian
horror. There's a reason why almost the only people still using self-
modifying code are virus writers, and the viruses they create are
notorious for
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
uhm, yeeah!
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRAN.
Julia
On Sunday, May 11, 2014 11:47:55 AM UTC+5:30, Mark H. Harris wrote:
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRAN.
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
steroids. Its amazing as a dynamic
On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote:
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
uhm, yeeah!
'Julia' is going to give everyone a not so small run
On Sun, May 11, 2014 at 07:09:27AM +, Steven D'Aprano wrote:
On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote:
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
Tomasz Rola rto...@ceti.pl:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath.
I have seen a glimpse of the so-called scientific computing and Fortran
programming. I can't help but think
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola rto...@ceti.pl wrote:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath. Something may look like cool and great, but wait ten years and
see if after
Mark H Harris harrismh...@gmail.com writes:
On 5/10/14 8:42 AM, Roy Smith wrote:
http://tinyurl.com/mr54p96
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRAN.
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together
In article 871tw0s2kl@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Tomasz Rola rto...@ceti.pl:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath.
I have seen a glimpse
On Mon, May 12, 2014 at 02:42:13AM +1000, Chris Angelico wrote:
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola rto...@ceti.pl wrote:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath. Something
On Mon, May 12, 2014 at 4:04 AM, Tomasz Rola rto...@ceti.pl wrote:
And the pipe
extention is one of the things I'd consider - as well as other
similar means, like SOAP or REST.
Yep. My point was, keep the processes separate and it's easy. There
are myriad ways of doing the glue.
ChrisA
--
On Mon, May 12, 2014 at 3:51 AM, Roy Smith r...@panix.com wrote:
It is fine. Computers are tools. The sign of a good tool is that you
can pick it up and use it without having to read the instruction manual.
I can jump into pretty much any car, start the engine, and drive it,
without any
On 05/11/2014 10:51 AM, Roy Smith wrote:
In article 871tw0s2kl@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Tomasz Rola rto...@ceti.pl:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold
On Mon, May 12, 2014 at 4:05 AM, Ethan Furman et...@stoneleaf.us wrote:
For the most part cars are very similar, yet in some circumstances (such as
a vehicle in front of you suddenly stopping) the exact details (such as the
precise location and size and shape of the brake pedal) become
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to make it possible to play without having to
look at your fingers (even when jumping your hands
On 5/11/14 12:05 PM, Alain Ketterlin wrote:
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
steroids. Its amazing as a dynamic language, and its fast, like
lightning fast as well as multiprocessing (parallel processing) at its
core. Its astounding, really.
Hmmm...
Its
On Mon, May 12, 2014 at 4:54 AM, Mark H Harris harrismh...@gmail.com wrote:
The following code will produce over 100,000 digits of π (pi) in less than 2
seconds on a low-end processor, like my mac mini dual core 2Ghz:
julia prec=524288
524288
julia with_bigfloat_precision(prec) do
On 5/11/14 1:59 PM, Chris Angelico wrote:
julia prec=524288
524288
julia with_bigfloat_precision(prec) do
println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
end
Would it be quicker (and no less accurate) to represent pi as
atan(BigFloat(1))*4 instead? That's how I
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to make it possible to play without having to
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to
development -- it makes a grand high-level assembly language
for low-level programming by experts where fine control and efficiency is
more important than simplicity and programmer efficiency. Fortran is
excellent for long-lasting numeric work, and Inform-7 is excellent for
writing interactive fiction
In article mailman.9900.1399852263.18130.python-l...@python.org,
MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering practices. In
my neck of the woods some years ago people were killed when standing at
a bus stop, because the
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
Speaking of which, here's a trivia question. Without looking at your
keyboard, describe how the F and J keys (assuming a US-English key
layout)
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote:
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering practices. In
my neck of the woods some years ago
On 05/11/2014 09:11 PM, Steven D'Aprano wrote:
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
Certainly not. However they may be different where *you* are :-P
I'm using an IBM keyboard, model SK-8820.
Mine have an little ridge on the keytop of those keys.
I've seen keyboards with
On 05/11/2014 02:54 PM, Mark H Harris wrote:
julia sin(BigFloat(π/4))
7.0710678118654750275194295621751674626154323953749278952436611913748
20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of precision.
Using Python 3.2,
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
julia sin(BigFloat(π/4))
7.0710678118654750275194295621751674626154323953749278952436611913748
20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of
On 5/11/14 11:10 PM, Mark H Harris wrote:
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
julia sin(BigFloat(π/4))
7.0710678118654750275194295621751674626154323953749278952436611913748
20215180412e-01 with 256 bits of precision
That answer doesn't
On Mon, May 12, 2014 at 2:26 PM, Mark H Harris harrismh...@gmail.com wrote:
Having said that, the accuracy was not my point; in the first place. My
point is that the sin() function is built-in...
So what? Built-in just means that there's no namespacing of
mathematical functions.
ChrisA
--
languages is a failing strategy. Better to be concrete: C, Pascal,
Algol, Fortran, VB (I think) are good examples of the value in a box at
a fixed location model. Of those, Algol, Pascal and Fortran are either
obsolete or legacy, and C is by far the most well-known by people here
On 5/10/2014 9:42 AM, Roy Smith wrote:
In article mailman.9805.1399597367.18130.python-l...@python.org,
Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
Obsolete and Legacy? Fortran still receives regular standards updates
(currently 2008, with the next revision due in 2015).
Ars
,NREC):
f.write(U[i,:,:],V[i,:,:])
f.close()
But the issue is that f.write do not allow multiple values( it allows one by
one so throws an error with above code ) on same write statement like in the
fortran code. experts may please advice if there a solution for this?
Can you just call
Thank you,
But it wont allow to write it in unformatted way so
that the fortran code can read
with
open(11,file=input.bin)
read(11) IWI,JWI,XFIN,YFIN,DXIN,DYIN,NREC,WDAY
with best regards,
sudheer
On Thu, Nov 14, 2013 at 7:48 PM, Oscar Benjamin
oscar.j.benja
Op 14-11-13 01:53, Sudheer Joseph schreef:
Hi,
I need to write a binary file exactly as written by fortran code
below to be read by another code which is part of a model which is not
advisable to edit.I would like to use python for this purpose as python has
mode flexibility
Hi,
I need to write a binary file exactly as written by fortran code below
to be read by another code which is part of a model which is not advisable to
edit.I would like to use python for this purpose as python has mode flexibility
and easy coding methods.
character(40) :: TITLE
Hi Sudheer,
Fortan binary format is not portable, and it's hard to work with it
with different langages, compilers, architectures...
In you're Python code, you also use NetCDF, which solve all these problems.
I would suggest to use only NetCDF files in both Python and Fortran code. (So
never
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
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
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
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
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
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
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
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
101 - 200 of 385 matches
Mail list logo
