Am 07.08.2015 um 19:17 schrieb Laura Creighton:
you
really only are doing crunching, and your crunching is done
in loops which run for a significant amount of time -- then PyPy
is generally faster than Fortran.
PyPy faster than Fortran in a tight number-crunching loop? Sorry I find
this very
In a message of Fri, 07 Aug 2015 23:26:46 +0200, Christian Gollwitzer writes:
Am 07.08.2015 um 19:17 schrieb Laura Creighton:
you
really only are doing crunching, and your crunching is done
in loops which run for a significant amount of time -- then PyPy
is generally faster than Fortran.
PyPy
Can anyone compare PyNum calculation speed to Fortran?
This is for a number crunching program working with large files.
Roger
--
https://mail.python.org/mailman/listinfo/python-list
On Friday, August 7, 2015 at 10:08:37 AM UTC-4, roge...@gmail.com wrote:
Can anyone compare PyNum calculation speed to Fortran?
This is for a number crunching program working with large files.
Roger
Did you mean NumPy? It depends on the program. Here are two posts that compared
speeds.
In a message of Fri, 07 Aug 2015 09:57:26 -0700, beliavsky--- via Python-list w
rites:
On Friday, August 7, 2015 at 10:08:37 AM UTC-4, roge...@gmail.com wrote:
Can anyone compare PyNum calculation speed to Fortran?
This is for a number crunching program working with large files.
Roger
And
On Friday, August 7, 2015 at 8:08:37 AM UTC-6, roge...@gmail.com wrote:
Can anyone compare PyNum calculation speed to Fortran?
This is for a number crunching program working with large files.
Roger
Thanks for answering. This will help a lot.
Roger
--
On 2015-08-07, rogerh...@gmail.com rogerh...@gmail.com wrote:
Can anyone compare PyNum calculation speed to Fortran?
This is for a number crunching program working with large files.
Well I can tell you how the numerical analysis and data visualization
programs _I_ use to write would compare
Steven D'Aprano, 28.02.2013 08:05:
On Wed, 27 Feb 2013 21:11:25 -0500, Terry Reedy wrote:
There is a problem with timer overhead for sub-microsecond operations.
In interactive use, the code is compiled within a function that gets
called. The string 'abc需' should be stored as a constant in
On Wed, 27 Feb 2013 23:40:22 -0800, jmfauth wrote:
As long as you are attempting to work with a composite scheme not
working with a unique set of characters, not only it will not work
(properly/with efficiency), it can not work.
What's a composite scheme?
This not even a unicode problem.
On 2/27/2013 3:21 AM, jmfauth hijacked yet another thread:
Some are building, some are destroying.
We are still waiting for you to help build a better 3.3+, instead of
trying to 'destroy' it with mostly irrelevant cherry-picked benchmarks.
Py33
timeit.repeat({1:'abc需'})
Am 27.02.2013 23:24, schrieb Terry Reedy:
On 2/27/2013 3:21 AM, jmfauth hijacked yet another thread:
Some are building, some are destroying.
We are still waiting for you to help build a better 3.3+, instead of
trying to 'destroy' it with mostly irrelevant cherry-picked benchmarks.
PEP 412
On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy tjre...@udel.edu wrote:
Py33
timeit.repeat({1:'abc需'})
[0.2573893570572636, 0.24261832285651508, 0.24259548003601594]
On my win system, I get a lower time for this:
[0.16579443757208878, 0.1475787649924598, 0.14970205670637426]
Py323
On 2/27/2013 7:15 PM, Ian Kelly wrote:
On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy tjre...@udel.edu wrote:
Py33
timeit.repeat({1:'abc需'})
[0.2573893570572636, 0.24261832285651508, 0.24259548003601594]
On my win system, I get a lower time for this:
[0.16579443757208878,
On Wed, 27 Feb 2013 21:11:25 -0500, Terry Reedy wrote:
There is a problem with timer overhead for sub-microsecond operations.
In interactive use, the code is compiled within a function that gets
called. The string 'abc需' should be stored as a constant in the code
object. To force repeated
On 27 fév, 23:24, Terry Reedy tjre...@udel.edu wrote:
On 2/27/2013 3:21 AM, jmfauth hijacked yet another thread:
Some are building, some are destroying.
We are still waiting for you to help build a better 3.3+, instead of
trying to 'destroy' it with mostly irrelevant cherry-picked
On Sat, 2009-03-07 at 22:05 +, Ville M. Vainio wrote:
Alan G Isaac wrote:
3. Chandler is not really an email client. So specifically,
which of its functionalities is it slow, and what evidence
if any is there that Python is causing this?
I remember reading somewhere that the cause
Ville M. Vainio wrote:
Alan G Isaac wrote:
3. Chandler is not really an email client. So specifically,
which of its functionalities is it slow, and what evidence
if any is there that Python is causing this?
I remember reading somewhere that the cause of slowness is/was
architectural -
Alan G Isaac wrote:
3. Chandler is not really an email client. So specifically,
which of its functionalities is it slow, and what evidence
if any is there that Python is causing this?
I remember reading somewhere that the cause of slowness is/was
architectural - perhaps it was that chandler
On Mar 8, 8:05 am, Ville M. Vainio vivai...@gmail.com wrote:
I remember reading somewhere that the cause of slowness is/was
architectural - perhaps it was that chandler was persisting too much stuff
to disk, or something. In any case, this might help you google for more
detail.
My
On Mar 2, 1:11 am, Paul Rubin wrote:
Mitch Kapor (of Lotus 1-2-3 fame) spent a lot of money hiring
very sharp Python programmers to write an email client called
Chandler, but from what I understand, progress so far has been
disappointing, at least in part for performance reasons.
Paul
Since my post I have compiled Python 2.4.3 with Sun Studio 11 with
-fast option (on Solaris 10) which has produced the fastest version of
Python I've been able to test on this hardware, including the CentOS
Linux version (which I'm pleased about).
I haven't looked into more optimal gcc build
I have found that the sunfreeware.com build of Python 2.4.3 for Solaris
10 is faster than one I can build myself, on the same system.
sunfreeware.com doesn't bother showing the options they used to
configure and build the software, so does anyone know what the optimal
build options are for
Chris Miles wrote:
I have found that the sunfreeware.com build of Python 2.4.3 for Solaris
10 is faster than one I can build myself, on the same system.
sunfreeware.com doesn't bother showing the options they used to
configure and build the software, so does anyone know what the optimal
James Tanis wrote:
Quite honestly I've never heard of java being faster than.. well..
anything. Faster than Python? I really doubt it. Their are several
libraries for game programming specifically as well as opengl, sdl, as
well as several different audio systems/daemons.. I'd suggest
On Thu, 29 Dec 2005 00:41:58 +0100, Andreas Kostyrka [EMAIL PROTECTED] wrote:
[on research supposedly proving that Python is faster than C, Java and
Fortran and assembly]
Well, it's easy enough to prove.
Take one aspect of Python: Automatic memory management via reference
counting.
Now,
It seems that Java JDK 1.4 (-server) HotSpot compiler sometimes (in
this test, on this computer, etc.) can produce programs faster than C
and Fortran ones in n-body simulations and similar stuff:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbodylang=all
Quite honestly I've never heard of java being faster than.. well..
anything. Faster than Python? I really doubt it. Their are several
libraries for game programming specifically as well as opengl, sdl, as
well as several different audio systems/daemons.. I'd suggest browsing
through the
Am Mittwoch, den 30.11.2005, 08:15 -0700 schrieb Steven Bethard:
David Rasmussen wrote:
Harald Armin Massa wrote:
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
Faster
Steve Holden wrote:
Faster than assembly? LOL... :)
I don't see why this is so funny. A good C compiler with optimization
typically produces better code than an equivalent assembly language
program. As compilation techniques improve this gap is likely to widen.
There's less and less
Harald Armin Massa wrote:
Faster than assembly? LOL... :)
why not?
Because any program generated automatically by a compiler of any kind
can always be expressed in assembly langauge. That writing assembler for
many processors can be really hard to do well is beside the point. We're
talking
Peter Hansen wrote:
From the speed requirement: Is that correspondance chess by any chance??
Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
there now.
I would also like to see Half Life 2 in pure
bruno at modulix wrote:
There's nothing like pure Python. Python depends on a lot of libs,
most of them being coded in C++ or C (or assembly FWIW). The common
scheme is to use Python for the logic and low-level libs for the
critical parts.
I know. But if a discussion like this is to have
[EMAIL PROTECTED] wrote:
DecInt's division algorithm is completely general also. But I would
never claim that Python code is faster than assembler. I believe that
careful implementation of a good algorithm is more important than the
raw speed of the language or efficiency of the compiler.
Krystian wrote:
I would also like to see Half Life 2 in pure Python.
or even quake1, do you think it could have any chances to run
smoothly?
If http://www.abrahamjoffe.com.au/ben/canvascape/ can run at a
reasonably speed, yes.
--
http://mail.python.org/mailman/listinfo/python-list
Mike Meyer wrote:
If you wire everything down, you can always hand-code assembler that
will be faster than HLL code
but that doesn't mean that your hand-coded assembler will always be faster
than an HLL implementation that addresses the same problem:
Pypy is not the only promisory project we have for seeing Python
running like compiled languages.
Shed Skin is already a quite usable Python-to-C++ compiler which, in
version 0.5.1, can actually compile many python scripts to fully
optimized stand-alone executables.
Next version will probably
[EMAIL PROTECTED] wrote:
Isaac Gouy wrote:
Which stated Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper - but didn't seem to compare
that to GMPY with a Java wrapper?
You are missing the main idea: Java is by design a general purpose
[EMAIL PROTECTED] wrote:
Isaac Gouy wrote:
Peter Hansen wrote:
Isaac Gouy wrote:
Peter Hansen wrote:
Judging by the other posts in this thread, the gauntlet is down: Python
is faster than Java. Let those who believe otherwise prove their point
with facts, and without
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Isaac Gouy wrote:
Which stated Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper - but didn't seem to compare
that to GMPY with a Java wrapper?
You are missing the main idea: Java is by
Fredrik Lundh [EMAIL PROTECTED] writes:
Mike Meyer wrote:
If you wire everything down, you can always hand-code assembler that
will be faster than HLL code
but that doesn't mean that your hand-coded assembler will always be faster
than an HLL implementation that addresses the same problem:
Cameron Laird wrote:
You are missing the main idea: Java is by design a general purpose
programming language. That's why all GMPYs and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue
.
I don't understand the sentence, That's why all 'GMPYs' and alike ...
Are
Fredrik Lundh wrote:
Cameron Laird wrote:
You are missing the main idea: Java is by design a general purpose
programming language. That's why all GMPYs and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue
.
I don't understand the sentence, That's why
Isaac Gouy wrote:
and yes, the proposition matches my experiences. java heads prefer to do
everything in java, while us pythoneers happily mix and match whenever we
can... (which is why guoy's benchmarks says so little about Python; if you
cannot use smart algorithms and extensions where
Fredrik Lundh wrote:
Isaac Gouy wrote:
and yes, the proposition matches my experiences. java heads prefer to do
everything in java, while us pythoneers happily mix and match whenever we
can... (which is why guoy's benchmarks says so little about Python; if
you
cannot use smart
DecInt's division algorithm is completely general also. But I would
never claim that Python code is faster than assembler. I believe that
careful implementation of a good algorithm is more important than the
raw speed of the language or efficiency of the compiler. Python makes
it easy to implement
Krystian [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi
are there any future perspectives for Python to be as fast as java?
Sure, if/when Python becomes as water-logged with obtruse OO-layers as Java
is now.
Python is faster than Java.
Because Python per design generally is a
Frithiof Andreas Jensen wrote:
From the speed requirement: Is that correspondance chess by any chance??
Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
there now.
I would also like to see Half Life
I would also like to see Half Life 2 in pure Python.
or even quake1, do you think it could have any chances to run
smoothly? or maybe demoscene productions...
--
http://mail.python.org/mailman/listinfo/python-list
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
I am not wise enough to understand that proof.
Maybe I understood those papers totally wrong and he was saying
something totally
Harald Armin Massa wrote:
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
Faster than assembly? LOL... :)
/David
--
http://mail.python.org/mailman/listinfo/python-list
David Rasmussen wrote:
Harald Armin Massa wrote:
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
Faster than assembly? LOL... :)
I think the claim goes something along the lines
Steven Bethard wrote:
David Rasmussen wrote:
Faster than assembly? LOL... :)
Faster than physics? ;-)
I think the claim goes something along the lines of assembly is so hard
to get right that if you can automatically generate it from a HLL, not
only will it be more likely to be correct, it
Harald Armin Massa wrote:
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
I am not wise enough to understand that proof.
Maybe I understood those papers totally wrong and he was
Steven Bethard wrote:
David Rasmussen wrote:
Harald Armin Massa wrote:
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
Faster than assembly? LOL... :)
I think the claim goes
Faster than assembly? LOL... :)
why not? Of course, a simple script like copy 200 bytes from left to
right can be handoptimized in assembler and run at optimum speed.
Maybe there is even a special processor command to do that.
I learned that there was one generation of CPUs which had effectively
David Rasmussen wrote:
Harald Armin Massa wrote:
Dr. Armin Rigo has some mathematical proof, that High Level Languages
like esp. Python are able to be faster than low level code like
Fortran, C or assembly.
Faster than assembly? LOL... :)
I don't see why this is so funny. A good C
Hi!
Harald Armin Massa wrote:
And I could see real development just from watching the BDFL: 3 years
ago PyPy was 2000times slower then CPython, and Guido was joking and
that number is growing, this year there were not officially negated
romours that sometime maybe PyPy could be the reference
David Rasmussen wrote:
Frithiof Andreas Jensen wrote:
From the speed requirement: Is that correspondance chess by any chance??
Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
there now.
I would
Harald Armin Massa wrote:
Faster than assembly? LOL... :)
why not? Of course, a simple script like copy 200 bytes from left to
right can be handoptimized in assembler and run at optimum speed.
Maybe there is even a special processor command to do that.
I learned that there was one
David Rasmussen wrote:
Frithiof Andreas Jensen wrote:
From the speed requirement: Is that correspondance chess by any chance??
Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
there now.
I
Steven Bethard wrote:
David Rasmussen wrote:
Faster than assembly? LOL... :)
Faster than physics? ;-)
I think the claim goes something along the lines of assembly is so
hard
to get right that if you can automatically generate it from a HLL,
not
only will it be more likely to be correct, it
Peter Hansen wrote:
True, but so what? Why did you suddenly change the discussion to
require pure Python?
Well, comments about Python's speed usually come in the following two
forms: some Python-based solution isn't fast enough; programs written
in Python aren't fast enough. In other words,
On Wed, 2005-11-30 at 14:53, Paul Boddie wrote:
[...] the Java virtual machine
is suitably designed/specified to permit just-in-time complication.
+1 Freudian slip of the week :)
-Carsten Haese
--
http://mail.python.org/mailman/listinfo/python-list
Paul Boddie wrote:
Steven Bethard wrote:
David Rasmussen wrote:
Faster than assembly? LOL... :)
Faster than physics? ;-)
I think the claim goes something along the lines of assembly is so
hard
to get right that if you can automatically generate it from a HLL,
not
only will it be
Peter Hansen wrote:
David Rasmussen wrote:
Frithiof Andreas Jensen wrote:
From the speed requirement: Is that correspondance chess by any chance??
Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
Isaac Gouy wrote:
Peter Hansen wrote:
Judging by the other posts in this thread, the gauntlet is down: Python
is faster than Java. Let those who believe otherwise prove their point
with facts, and without artificially handcuffing their opponents with
non-real-world purity requirements.
That
Harald Armin Massa [EMAIL PROTECTED] writes:
Faster than assembly? LOL... :)
why not? Of course, a simple script like copy 200 bytes from left to
right can be handoptimized in assembler and run at optimum speed.
Maybe there is even a special processor command to do that.
Chances are, version
In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED]
wrote:
Harald Armin Massa [EMAIL PROTECTED] writes:
Faster than assembly? LOL... :)
why not? Of course, a simple script like copy 200 bytes from left to
right can be handoptimized in assembler and run at optimum speed.
Maybe
Peter Hansen wrote:
Isaac Gouy wrote:
Peter Hansen wrote:
Judging by the other posts in this thread, the gauntlet is down: Python
is faster than Java. Let those who believe otherwise prove their point
with facts, and without artificially handcuffing their opponents with
non-real-world
Donn Cave wrote:
I read yesterday morning in the paper that the Goto Basic Linear
Algebra Subroutines, by a Mr. Kazushige Goto, are still the most
efficient library of functions for their purpose for use in
supercomputing applications. Apparently hand-optimized assembler
for specific
Carsten Haese wrote:
On Wed, 2005-11-30 at 14:53, Paul Boddie wrote:
[...] the Java virtual machine
is suitably designed/specified to permit just-in-time complication.
+1 Freudian slip of the week :)
Well, I never said it was easy. ;-)
Paul
--
Isaac Gouy wrote:
Peter Hansen wrote:
Isaac Gouy wrote:
Peter Hansen wrote:
Judging by the other posts in this thread, the gauntlet is down: Python
is faster than Java. Let those who believe otherwise prove their point
with facts, and without artificially handcuffing their opponents
I did a small test some time ago and I think python is faster then java:
http://linuxlah.blogspot.com/2005/11/swap-speed-for-python-c-c-and-java.html
On 11/30/05, Krystian [EMAIL PROTECTED] wrote:
Hiare there any future perspectives for Python to be as fast as java? iwould like to use Python as
Isaac Gouy wrote:
Which stated Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper - but didn't seem to compare
that to GMPY with a Java wrapper?
You are missing the main idea: Java is by design a general purpose
programming language. That's why all
Hi
are there any future perspectives for Python to be as fast as java? i
would like to use Python as a language for writing games.
best regards
krystian
--
http://mail.python.org/mailman/listinfo/python-list
In article [EMAIL PROTECTED],
Krystian [EMAIL PROTECTED] wrote:
are there any future perspectives for Python to be as fast as java? i
would like to use Python as a language for writing games.
Why would we want Python to be as fast as Java when it's already faster?
Take a look at PyGame.
--
Hi
are there any future perspectives for Python to be as fast as java? i
would like to use Python as a language for writing games.
Why would we want Python to be as fast as Java when it's already faster?
hm... i came across this site:
Krystian wrote:
Hi
are there any future perspectives for Python to be as fast as java? i
would like to use Python as a language for writing games.
Why would we want Python to be as fast as Java when it's already faster?
hm... i came across this site:
[EMAIL PROTECTED] wrote:
Anyone know which is faster? I'm a PHP programmer but considering
getting into Python ... did searches on Google but didn't turn much up
on this.
Thanks!
Stephen
If you're talking about usage as a server side scripting
language, then PHP will likely give better page
Dnia Tue, 28 Dec 2004 02:54:13 +0800, Jon Perez napisa(a):
If you're talking about usage as a server side scripting
language, then PHP will likely give better page serving
throughput for the same hardware configuration versus
even something that is mod_python based (but I believe
the speed
80 matches
Mail list logo
