Re: Python speed

On 2015-08-07, 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 to Fortran: The Py

Re: Python speed

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 Fortra

Re: Python speed

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 h

Re: Python speed

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 -- https://mail.python.org/mailman/l

Re: Python speed

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. >> >> R

Re: Python speed

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

Python speed

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

Re: Python Speed

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 pro

Re: Python Speed

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 const

Re: Python Speed

On 27 fév, 23:24, Terry Reedy 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 benchmarks. > >  > P

Re: Python Speed

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 repeate

Re: Python Speed

On 2/27/2013 7:15 PM, Ian Kelly wrote: On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy 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.14970205670

Re: Python Speed

On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy 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 >> timeit

Re: Python Speed

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

Python Speed

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需'}") > [0.25738

Re: Chandler, Python, speed

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 > arch

Re: Chandler, Python, speed

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" tha

Re: Chandler, Python, speed

On Mar 8, 8:05 am, "Ville M. Vainio" 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 understanding was the

Re: Chandler, Python, speed

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 chand

Re: Chandler, Python, speed

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 McGui

Re: Python speed on Solaris 10

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

Re: Python speed on Solaris 10

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 >

Python speed on Solaris 10

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 Sola

Re: python speed

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 brow

Re: python speed

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 categories

Re: python speed

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=nbody&lang=all http://shootout.alioth.debian.

Re: python speed

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. >

Re: python speed

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. >

Re: python speed

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 t

Re: python speed

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 Hal

Re: python speed

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 talk

Re: python speed

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

Re: python speed

[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.

Re: python speed

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

Re: python speed

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 > >> can

Re: python speed

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

Re: python speed

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 sentenc

Re: python speed

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 alik

Re: python speed

"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 p

Re: python speed

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: J

Re: python speed

[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

Re: python speed

[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 pu

Re: python speed

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 supp

Re: python speed

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: http://mail.python.org/pipermail/python-a

Re: python speed

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 can run at a reasonably speed, yes. -- http://mail.python.org/mailman/listinfo/python-list

Re: python speed

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

Re: python speed

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

Re: python speed

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

Re: python speed

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 -- http://mail.python.org/mailman/listin

Re: python speed

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 pro

Re: python speed

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-

Re: python speed

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 s

Re: python speed

"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

Re: python speed

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.

Re: python speed

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++ pr

Re: python speed

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 > >

Re: python speed

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

Re: python speed

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,

Re: python speed

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 corre

Re: python speed

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

Re: python speed

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

Re: python speed

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

Re: python speed

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 refer

Re: python speed

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

Re: python speed

>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 effective

Re: python speed

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 t

Re: python speed

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

Re: python speed

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 corre

Re: python speed

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 t

Re: python speed

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

Re: python speed

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 different.

Re: python speed

>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

Re: python speed

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 Li

Re: python speed

"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 i

Re: python speed

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: > http://shootout.alioth.

Re: python speed

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: http://shootout.alioth.debian.org/benchmark.php?test=al

Re: python speed

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.

python speed

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

Re: PHP vs. Python (speed-wise comparison)

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 sp

Re: PHP vs. Python (speed-wise comparison)

[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 servin