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 hard to believe. I could accept that PyPy can match the speed of Fortran in these cases, but exceeding seems highly unlikely. Was it a mistake, or do you have a reference that shows how PyPy can be faster than Fortran? I agree with the rest what you have said. Christian -- https://mail.python.org/mailman/listinfo/python-list
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 Fortran. PyPy faster than Fortran in a tight number-crunching loop? Sorry I find this very hard to believe. I could accept that PyPy can match the speed of Fortran in these cases, but exceeding seems highly unlikely. Was it a mistake, or do you have a reference that shows how PyPy can be faster than Fortran? I agree with the rest what you have said. Christian My apologies -- I went and looked it up, and it seems that the person who reported this got taught how to vectorise his Fortran code and some other tricks, and now his Fortran code runs between 2.5 and 3 times faster than PyPy for his numberical benchmarks. I seem to have got the initial news, and never heard about the correction Thank you for bringing this up. Laura -- https://mail.python.org/mailman/listinfo/python-list
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 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. Comparing Python, NumPy, Matlab, Fortran, etc. (2009) https://modelingguru.nasa.gov/docs/DOC-1762 Optimizing Python in the Real World: NumPy, Numba, and the NUFFT (2015) https://jakevdp.github.io/blog/2015/02/24/optimizing-python-with-numpy-and-numba/ -- https://mail.python.org/mailman/listinfo/python-list
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. Roger And for speed you may be better off with PyPy than with NumPy http://speed.pypy.org/timeline/ but, as is always the case when measuring the speed of things, 'it all depends on what you are doing'. Do you need to link to existing Fortran or C libraries? If the answer is no, and 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. If you are spending most of your time in matplotlib graphing your results, you will be unhappy with PyPy performance. pypy-...@python.org is a better place to discuss performance of PyPy, though while http://mail.scipy.org/mailman/listinfo/numpy-discussion is a better place to discuss numpy. scipy.org has been down all day, alas. But the Americans should be awake now and dealing with it. Laura -- https://mail.python.org/mailman/listinfo/python-list
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/listinfo/python-list
Re: Python speed
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 to Fortran: The Python programs were infinitely faster than Fortran because the probability I could have gotten equivelent Fortran programs to work before the data became moot was pretty much zero. On a more serious note, almost all of the heavy lifting in the programs I wrote (array operations, curve fitting, Delaunay triangulation, etc.) was all done by libraries written in Fortan and C. So I doubt the difference between Fortran and Python would have mattered (assuming I _could_ have written equivalent programs in Fortran). -- Grant -- https://mail.python.org/mailman/listinfo/python-list
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 constant in the code object. To force repeated string operation, one should either time from command line or do an operation, as with the example above. I notice that the first of 3 times is almost always higher for some reason. I am not an expert on this, but I suspect the problem may have something to do with CPU pipelines and cache. The first time the timer runs, the cache is empty, and you get a slightly higher time. Subsequently there are not as many CPU cache misses, and the code runs more quickly. Well, the default loop iteration count is 100, so warming up any caches might make a little difference at the very beginning but should rarely have a major impact on the overall running time, as each iteration only changes the final result by 1/100 of its runtime. However, it's best to run timeit as a main program (python -m timeit), because the way it works then is that it first runs the code a couple of times to see how often it should repeat it in a loop to get meaningful results. Only *then* it starts benchmarking it. That initial testing phase should usually be enough to warm up any caches, so that you'd get better results. You can still get the results of all repeated runs if you pass -v. Stefan -- http://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 problem. This is true for every coding scheme. That's why we have, today, all these coding schemes, coding scheme: == set of characters; != set of encoded characters. This doesn't make any sense to me. What do you think this means? Oh, and the actual reason we have all these coding schemes is for historical reasons. Just about every PC manufacturer invented their own encoding for whatever characters they cared about. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
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.2573893570572636, 0.24261832285651508, 0.24259548003601594]
On my win system, I get a lower time for this:
[0.16579443757208878, 0.1475787649924598, 0.14970205670637426]
Py323
timeit.repeat({1:'abc需'})
[0.11000708521282831, 0.0994753634273593, 0.09901023634051853]
While I get the same time for 3.2.3.
[0.11759353304428544, 0.0948244802968, 0.09532802044164157]
It seems that something about Jim's machine does not like 3.3.
*nix will probably see even less of a difference. Times are in
microseconds, so few programs will ever notice the difference.
In the meanwhile ... Effort was put into reducing startup time for 3.3
by making sure that every module imported during startup actual needed
to be imported, and into speeding up imports.
The startup process is getting a deeper inspection for 3.4
http://python.org/dev/peps/pep-0432/
'Simplifying the CPython startup sequence'
with some expectation for further speedup.
Also, a real-world benchmark project has been established.
http://speed.python.org/
Some work has already been done to port benchmarks to 3.x, but I suspect
there is more to do and more volunteers needed.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
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 412 [1] causes a slow down in the dict instantiation code, see [2].
$ for PY in python2.7 python3.2 python3.3 ./python; do cmd=$PY -R -m
timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'; echo $cmd; eval
$cmd; done
python2.7 -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.163 usec per loop
python3.2 -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.139 usec per loop
python3.3 -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.663 usec per loop
./python -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.382 usec per loop
(./python is a patched 3.3 dev version)
Christian
[1] http://www.python.org/dev/peps/pep-0412/
[2] http://bugs.python.org/issue16465
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Speed
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
timeit.repeat({1:'abc需'})
[0.11000708521282831, 0.0994753634273593, 0.09901023634051853]
While I get the same time for 3.2.3.
[0.11759353304428544, 0.0948244802968, 0.09532802044164157]
It seems that something about Jim's machine does not like 3.3.
*nix will probably see even less of a difference. Times are in microseconds,
so few programs will ever notice the difference.
Running the same tests in IDLE on my Windows XP laptop, I see similar
results to what jmf reports. But from what Christian posted, it
sounds like this regression may have more to do with PEP 412 than PEP
393.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Speed
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, 0.1475787649924598, 0.14970205670637426]
Py323
timeit.repeat({1:'abc需'})
[0.11000708521282831, 0.0994753634273593, 0.09901023634051853]
While I get the same time for 3.2.3.
[0.11759353304428544, 0.0948244802968, 0.09532802044164157]
It seems that something about Jim's machine does not like 3.3.
*nix will probably see even less of a difference. Times are in microseconds,
so few programs will ever notice the difference.
Running the same tests in IDLE on my Windows XP laptop, I see similar
results to what jmf reports.
Whereas I run win 7 on a pentium i7 desktop. For this, I suspect the
processor difference more than the OS. To really investigate, one should
separately time string creation from dict creation with a pre-built string.
repeat('pass') # .013 to .02 on both
repeat('abc需') # same, untimeable
repeat('abc需'*10) # .12 versus .14 on 3.2 and 3.3
repeat({1:s}, s='abc需') # .10 versus .14
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 string operation, one should either time from
command line or do an operation, as with the example above. I notice
that the first of 3 times is almost always higher for some reason.
But from what Christian posted, it
sounds like this regression may have more to do with PEP 412 than PEP
393.
That change traded a space saving and for a small initial time cost.
Christian also showed that initial cost has since been cut. There may be
more internal dict tweaks before 3.4.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
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 repeated string operation, one should either time from command line or do an operation, as with the example above. I notice that the first of 3 times is almost always higher for some reason. I am not an expert on this, but I suspect the problem may have something to do with CPU pipelines and cache. The first time the timer runs, the cache is empty, and you get a slightly higher time. Subsequently there are not as many CPU cache misses, and the code runs more quickly. Or, I could be talking out of my arse. Once upon a time CPUs were simple enough for me to understand what make code faster or slower, but no more... -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Speed
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 benchmarks.
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.repeat({1:'abc需'})
[0.11000708521282831, 0.0994753634273593, 0.09901023634051853]
While I get the same time for 3.2.3.
[0.11759353304428544, 0.0948244802968, 0.09532802044164157]
It seems that something about Jim's machine does not like 3.3.
*nix will probably see even less of a difference. Times are in
microseconds, so few programs will ever notice the difference.
In the meanwhile ... Effort was put into reducing startup time for 3.3
by making sure that every module imported during startup actual needed
to be imported, and into speeding up imports.
The startup process is getting a deeper inspection for
3.4http://python.org/dev/peps/pep-0432/
'Simplifying the CPython startup sequence'
with some expectation for further speedup.
Also, a real-world benchmark project has been
established.http://speed.python.org/
Some work has already been done to port benchmarks to 3.x, but I suspect
there is more to do and more volunteers needed.
--
Terry Jan Reedy
-
Terry,
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.
This not even a unicode problem. This is true for every coding
scheme. That's why we have, today, all these coding schemes, coding
scheme: == set of characters; != set of encoded characters.
jmf
--
http://mail.python.org/mailman/listinfo/python-list
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 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. I've been using it, and the only major issue I've got is the long shutdown times, which is caused by backing up a copy of _Everything_ to disk, so that upgrades can happen cleanly - sure that's going to be fixed though. Startup time is a bit slow too, but it's designed to be left open all the time, and it's fairly zippy once it's open IMO. Tim Wintle -- http://mail.python.org/mailman/listinfo/python-list
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 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. Here's the somewhere: http://blog.chandlerproject.org/2008/05/21/rick-rawson-on-why-i-use-chandler-and-what-would-make-me-stop/ QQQ Alex, you’re right that VM usage is a big factor, although there are cases where the CPU is doing too much, too. So far as why this is, there are many contributions. The biggest one is that architectural decisions taken early on in the project meant that way too much data is being persisted. For example, the app persists all schema and GUI layout information, leading to on-disk and mapped memory bloat. (There is also redundancy in the data stored on disk that leads to more of this kind of bloat). QQQ -- http://mail.python.org/mailman/listinfo/python-list
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 chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
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 understanding was the Philip Eby's oft-quoted Python Is Not Java[1] post was a direct response to how he saw the Chandler project being developed: I was recently looking at the source of a wxPython-based GUI application, about 45.5KLOC in size, not counting the libraries used (e.g. Twisted). The code was written by Java developers who are relatively new to Python, and it suffers from some performance issues (like a 30-second startup time). In examining the code, I found that they had done lots of things that make sense in Java, but which suck terribly in Python. Not because Python is slower than Java, but because there are easier ways to accomplish the same goals in Python, that wouldn't even be possible in Java. [1]: http://dirtsimple.org/2004/12/python-is-not-java.html -- http://mail.python.org/mailman/listinfo/python-list
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 McGuire wrote: Yipes, have you read the book (Dreaming in Code)? Chandler's problems were much more organizational than technical. This discussion makes me curious about a couple things. 1. It is hard to see how Python could make a slow email client. Is that the actual claim? Where is the demand for computational speed coming from? 2. This is especially true for IMAP, where it seems any computationally intensive work (e.g., sorting very large mailboxes) will be done on the server. 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? Thanks, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
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 options yet, so that may produce a faster build, but I am probably satisfied with what Sun Studio has given me for now. Cheers, Chris [EMAIL PROTECTED] wrote: I noticed that speed difference, too. After running ./configure, I edited the resulting Makefile to pass -march=athlon-mp to the C compiler. ./configure seems to ignore CFLAGS, for example, so I just edited Makefile to suit my environment. You should set the values appropriate for you system, of course. I've also compiled Python using the Sun Studio compiler. Some tests were faster, some tests were slower. -- http://chrismiles.info/ -- http://mail.python.org/mailman/listinfo/python-list
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 Solaris 10 (x86)? Here are some pybench/pystone results, and I include the same comparison of Python2.4.3 running on CentOS 4.3 on the same hardware (which is what prompted me to find a faster Python build in the first place). Python 2.4.3: System pybench Pystone (pystones/s) Sol10 my build 3836.00 ms 37313.4 Sol10 sunfreeware3235.00 ms 43859.6 CentOS 3569.00 ms 44247.8 My build: Python 2.4.3 (#1, Oct 15 2006, 16:00:33) [GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] on sunos5 sunfreeware.com build: Python 2.4.3 (#1, Jul 31 2006, 05:14:51) [GCC 3.4.6] on sunos5 My build on CentOS 4.3: Python 2.4.3 (#1, Jul 19 2006, 17:52:43) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 is the difference purely gcc minor version? -- http://chrismiles.info/ -- http://mail.python.org/mailman/listinfo/python-list
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 build options are for Solaris 10 (x86)? Here are some pybench/pystone results, and I include the same comparison of Python2.4.3 running on CentOS 4.3 on the same hardware (which is what prompted me to find a faster Python build in the first place). Python 2.4.3: System pybench Pystone (pystones/s) Sol10 my build 3836.00 ms 37313.4 Sol10 sunfreeware3235.00 ms 43859.6 CentOS 3569.00 ms 44247.8 My build: Python 2.4.3 (#1, Oct 15 2006, 16:00:33) [GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] on sunos5 sunfreeware.com build: Python 2.4.3 (#1, Jul 31 2006, 05:14:51) [GCC 3.4.6] on sunos5 My build on CentOS 4.3: Python 2.4.3 (#1, Jul 19 2006, 17:52:43) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 is the difference purely gcc minor version? I noticed that speed difference, too. After running ./configure, I edited the resulting Makefile to pass -march=athlon-mp to the C compiler. ./configure seems to ignore CFLAGS, for example, so I just edited Makefile to suit my environment. You should set the values appropriate for you system, of course. I've also compiled Python using the Sun Studio compiler. Some tests were faster, some tests were slower. casevh -- http://chrismiles.info/ -- http://mail.python.org/mailman/listinfo/python-list
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 browsing through the categories in python.org's module search engine. Disclaimer (:P): The majority of generalizations have some amount of exceptions, the java crack above was just my opinion - it was not really intended to offend any java addicts out there (the poor, miss-guided souls). While java is much slower than Python in developer-time (e.g. the time it takes to generate a working app, and the number of lines involved), (good) Java code running on the hotspot (JIT) VM is usually at least an order of magnitude faster than the equivalent Python code, if not faster. What's dog slow in Java is primarily the VM startup, and then the memory bloating, but as far as execution speed goes, pure Java code is much faster than pure Python much more often than the opposite (now that may change with Pypy, but Pypy is not done yet) Xavier -- http://mail.python.org/mailman/listinfo/python-list
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. Now, while it's certainly possible to implement exactly what Python does in C++ (both are turing complete, ...), the normal and idiomatic way is to have APIs that care about object ownership. Your discussion is interesting but a bit misleading, because most function calls in C++ don't involve ownership issues. Most parameters are passed by value (for reasonably small things, copying on a warm stack is bloody fast!) or by const reference, with the understanding that the callee doesn't steal or borrow a reference to the object. Or, the whole thing is inlined. Yes, it sometimes happens that you have to have weirder things happen to your objects -- but only to a tiny fraction of them, not all of them as in Python. I cannot see how that would make Python, in general, faster than C++. The normal idiomatic way is relevant, as third-party libraries usually force one to develop this way. I never use third-party C++ libraries, but I can see how an overly complex, obsolete and badly designed API (MFC, anone? Or CORBA monstrosities.) could complicate this a lot. /This/ is an area where C++ and similar languages lose to Python -- you have to be an expert to write reusable C++ APIs which don't suck! /Jorgen -- // Jorgen Grahn grahn@Ph'nglui mglw'nafh Cthulhu \X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
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=nbodylang=all http://shootout.alioth.debian.org/gp4/benchmark.php?test=spectralnormlang=all So maybe PyPy can become quite fast too. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
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 in python.org's module search engine. Disclaimer (:P): The majority of generalizations have some amount of exceptions, the java crack above was just my opinion - it was not really intended to offend any java addicts out there (the poor, miss-guided souls). On 11/29/05, Krystian [EMAIL PROTECTED] 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. best regards krystian -- http://mail.python.org/mailman/listinfo/python-list -- James Tanis [EMAIL PROTECTED] http://pycoder.org -- http://mail.python.org/mailman/listinfo/python-list
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. Faster than assembly? LOL... :) 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 will be more likely to be fast because the code generator can provide the appropriate optimizations. OTOH, you can almost certainly take automatically generated assembly code and make optimizations the code generator wasn't able to, thanks to knowing more about the real semantics of the program. Well, it's easy enough to prove. Take one aspect of Python: Automatic memory management via reference counting. Now, while it's certainly possible to implement exactly what Python does in C++ (both are turing complete, ...), the normal and idiomatic way is to have APIs that care about object ownership. The normal idiomatic way is relevant, as third-party libraries usually force one to develop this way. Now, APIs with a static object ownership relationship are the norm in C++ land. By this I mean, that a function like: obj *func(obj2 *o2, obj3 *o3) has a static behaviour when it comes to object ownership. Either it always takes care of o2, which means that it has to free it anyway, which means that a caller that wants to keep it has to copy it, or it never takes care of o2, which means that an implementation of func that needs to keep a copy of o2 needs to copy it. Now the obvious answer is, use a reference counting pointer type. Problem here: It's probably an external reference counter, or it is not generic: [refptr] count ptr --- [object] data Which means two objects to allocate, two levels of indirection, etc. And it might not work in many contexts where there is already existing code that needs to interface with it. Even more difficult is the task to use an inobject refcounter. In Python on the other hand, def func(o2, o3): func can keep a o2 or not, and nobody cares. Actually the fact if o2 is kept or not, might be runtime dependant. To summerize, in complex applications, the better runtime fundation of languages like Python might lead to situations where Python is faster then C/C++. If one takes additionally the developer-costs into this comparisation (which is a relevant metric in 95% of code developed), the Python solution has the additional benefit, that it allows us to implement more complicated and faster algorithms, because the language is so much higher level and more productive. OTOH, almost languages are turing-complete, meaning that you can do anything you can do in Python in C, C++ or Assembler. Just don't tell me that it is usual to write self-modifying assembler programs that create an optimized piece of code for combinations of argument types, like Psyco does. Andreas signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- http://mail.python.org/mailman/listinfo/python-list
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 less reason to use assembler language with each passing year. I've answered this question elsewhere in the thread. /David -- http://mail.python.org/mailman/listinfo/python-list
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 talking about the best-case capabilities of a language. Writing programs in other languages can be hard as well, not to mention writing a compiler for any language that produces as good as best assembly code, that is, optimal code. /David -- http://mail.python.org/mailman/listinfo/python-list
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 Half Life 2 in pure Python. True, but so what? So nothing. I was just commenting on the correspondance chess comment... with a valid observation. Why did you suddenly change the discussion to require pure Python? Because that's the only meaningful thing to discuss. If we're allowed to use Python as a thin layer above C (a very important, practical and cool feature), then we're measuring the speed of C, not Python. What would be the point of that? I can already answer how fast that notion of Python is: as fast as C. And are you not allowed to use any of the performance-boosting techniques available for Python, like Pyrex or Psyco? Of course. Why such restrictions, when these are things Python programs use on a daily basis: these are *part* of Python, as much as the -O switch on the compiler is part of C/C++. Because we're then measuring the speed of C, not Python. But if you want to convey the point that Python can be used for arbitrarily performance hungry problems, you're right. Just code the fast parts in C or assembly language and apply a thin layer of Python on top. Lather, rinse, repeat. Okay, let's compare a pure Python program (if you can define it in any meaningful, practical way) with a pure Java program, running on a non-JIT interpreter and with optimizations turned off (because, of course, those optimizations are umm... somehow.. not pure...?). Says who? And why are you comparing to Java now? Java sucks. Judging by the other posts in this thread, the gauntlet is down: Python is faster than Java. I don't disagree with that. Let those who believe otherwise prove their point with facts, and without artificially handcuffing their opponents with non-real-world purity requirements. You are the one getting theoretical and academic. I was just commenting on the chess comment above, because it is a field that I have extensive knowledge in. To make a real-word challenge to make my point obvious: Write a chess program in Python and win more than 50% out of 100 games against a good chess program (Crafty, Fritz, Chess Tiger etc.) playing on the same hardware. In fact, just win one. Now, if you write the fast parts in C, you obviously can solve this problem, and easily. But then there is no reason to discuss Python's speed ever. Just say as fast as C and code everything in C and make a hookup in Python. In fact, why not just code it in C then? /David -- http://mail.python.org/mailman/listinfo/python-list
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 to have any meaning, then we're talking about algorithmic or calculative code with native Python constructs, not Python as a layer on another langauge. In that case, we're measuring the speed of the other language, not Python. And FWIW, I'd like to see any similar game in pure Java !-) Me too :) /David -- http://mail.python.org/mailman/listinfo/python-list
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. Python makes it easy to implement algorithms. that was of course the point here (and your work with DecInt is an excellent illustration of this principle). /F -- http://mail.python.org/mailman/listinfo/python-list
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 http://www.abrahamjoffe.com.au/ben/canvascape/ can run at a reasonably speed, yes. -- http://mail.python.org/mailman/listinfo/python-list
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-announce-list/2005-November/004519.html Pure Python division is 16x slower than GMP but can actually be faster in some instances; for example, dividing a 2,000,000 digit number by an 800,000 digit number /F -- http://mail.python.org/mailman/listinfo/python-list
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 support the use of the standard python library and many, many exciting enhancements. The main difference between these two projects is that while PYPY aims to support 100% of python semantics including (all its dynamic features) on top of a virtual machine. It uses type inference for static compilation and just-in-time techniques. On the other hand, Shed Skin is purely a static compiler that translates python to c++ and then compiles to a stand alone executable. It will never support the most dynamic features of Python, but in most cases, it only requires to restrict our coding style a little bit to avoid these features and produce highly optimized code. http://shedskin.sf.net http://shed-skin.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
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 purpose programming language. That's why all GMPYs and alike are written in Java - now wrappers to C-libraries. Python, by design, is glue language. Python program is assembly of C extensions and buildins wrapped in Python sintax. IHMO real life benchmark yuo are critisizing represents real life situation. 1.1.3 What is Python good for? Python is a high-level general-purpose programming language that can be applied to many different classes of problems. http://www.python.org/doc/faq/general.html#what-is-python-good-for -- http://mail.python.org/mailman/listinfo/python-list
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, and without artificially handcuffing their opponents with non-real-world purity requirements. That form of argument is listed as one of the principal forms of illogical thinking in Being Logical D.Q.McInerny - An Inability to Disprove Does Not Prove Good thing this is the form of argument *against* which I was arguing, rather than that which I choose to use myself. (Read very carefully, if you really think I was saying otherwise, and point out exactly where I made any such claims for my own part. In fact, I was referencing the arguments of others -- who *were* supporting their arguments with facts, as near as I can tell -- and I was calling on the opposition to do the same, and without changing the rules mid-discussion.) The fact that there is no concrete proof against a position does not constitute an argument in favour of the position. I cannot claim to be right simply because you can't prove me to be wrong. Isn't that what I was saying? That those who claim Python isn't faster were not supporting their arguments with actual facts? -Peter *Python is faster than Java. Let those who believe otherwise prove their point with facts* We must be looking at different threads :-) afaict the only posting that provided something like facts was http://groups.google.com/group/comp.lang.python/msg/309e439697279060 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? Is there such an animal? I only know about Java's BigInteger. Google. http://dev.i2p.net/javadoc/net/i2p/util/NativeBigInteger.html And if there is, it just proves my point that benchmarks are worthless. How so? -- http://mail.python.org/mailman/listinfo/python-list
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: 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 you saying that reuse of code written in languages other than Java is NOT important to Java? I think that's a reasonable proposition; I'm just having trouble following your paragraph. -- http://mail.python.org/mailman/listinfo/python-list
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 problem: True. But you can always recode the assembler to make it faster than the HLL for the case at hand, possibly making it worse in other cases. http://mail.python.org/pipermail/python-announce-list/2005-November/004519.html Pure Python division is 16x slower than GMP but can actually be faster in some instances; for example, dividing a 2,000,000 digit number by an 800,000 digit number This isn't the case I outlined, though. This is general-purpose assembler package, not assembler code designed specifically for dividing a 2,000,000 digit number by an 800,000 digit number. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
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 alike ... Are you saying that reuse of code written in languages other than Java is NOT important to Java? I think that's a reasonable proposition; I'm just having trouble following your paragraph. replace now with not or perhaps instead of being implemented as, and it may become a bit easier to parse. 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 appropriate, you're not really using Python as it's supposed to be used) /F -- http://mail.python.org/mailman/listinfo/python-list
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 sentence, That's why all 'GMPYs' and alike ... Are you saying that reuse of code written in languages other than Java is NOT important to Java? I think that's a reasonable proposition; I'm just having trouble following your paragraph. replace now with not or perhaps instead of being implemented as, and it may become a bit easier to parse. 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 appropriate, you're not really using Python as it's supposed to be used) /F If you can't use C where appropriate, you're not really using Python as it's supposed to be used? :-) -- http://mail.python.org/mailman/listinfo/python-list
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 where appropriate, you're not really using Python as it's supposed to be used) If you can't use C where appropriate, you're not really using Python as it's supposed to be used? :-) who's talking about C ? and what's the connection between C and smart algorithms ? /F -- http://mail.python.org/mailman/listinfo/python-list
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 cannot use smart algorithms and extensions where appropriate, you're not really using Python as it's supposed to be used) If you can't use C where appropriate, you're not really using Python as it's supposed to be used? :-) who's talking about C ? and what's the connection between C and smart algorithms ? /F [EMAIL PROTECTED] wrote: Python program is assembly of C extensions and buildins wrapped in Python sintax. -- http://mail.python.org/mailman/listinfo/python-list
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 algorithms. -- http://mail.python.org/mailman/listinfo/python-list
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 is a thin layer of glue poured over binary C modules, it does not take very many instructions before one hits the fastest speed that the platform can go at. I would test it, then worry about it. i would like to use Python as a language for writing games. From the speed requirement: Is that correspondance chess by any chance?? -- 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 Life 2 in pure Python. /David -- http://mail.python.org/mailman/listinfo/python-list
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
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. But whatever, the pypy-team is formed out of some more people of his calibre and founded by the European Union to provide butter by the fish, say, to produce real code that may deliver that promise. 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 implementation of Python; and also reports that PyPy is only 18 times slower then CPython. For the time being, my Python programs just sit and wait for database, network, user input or the acting of COM-Applications like Excel or Winword. Sometimes I even have 3 threads, one to wait for user, one for database and one to wait for Excel - boy, I wait fast! But on the other hand, I do no real world applications like triple mersenne first person shooters, only business software like the one which in earlier time was written in COBOL or carved into cave walls. Less challenge, higher reward. Harald -- http://mail.python.org/mailman/listinfo/python-list
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
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 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 will be more likely to be fast because the code generator can provide the appropriate optimizations. OTOH, you can almost certainly take automatically generated assembly code and make optimizations the code generator wasn't able to, thanks to knowing more about the real semantics of the program. STeVe -- http://mail.python.org/mailman/listinfo/python-list
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 correct, it will be more likely to be fast because the code generator can provide the appropriate optimizations. I think this is just a restatement of existing motivations for using high-level languages and compilers. My impression is that PyPy takes inspiration from work which showed that run-time knowledge can sometimes produce code that is better optimised than that produced by a compiler. That said, when everyone starts showing off their favourite benchmarks, it might be more interesting not to parade some festival of arithmetic yet again. Where more recent versions of the Java virtual machines have improved is in their handling of object memory allocation, amongst other things, and merely scoffing that Java is slow (by pulling specific/specialised extension packages out of the hat) fails to acknowledge the potential for similar improvements (and others) in Python, especially where programs involving plain objects - as opposed to numbers, and where no conveniently available and wrapped C/C++ package exists for the task - are concerned. Paul -- http://mail.python.org/mailman/listinfo/python-list
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 was saying something totally different. Here is a paper of Armin explaining his psycology: http://psyco.sourceforge.net/theory_psyco.pdf Heck, Python has at least one programmer who is computer scientist and knows how to draw commutative diagrams :) -- http://mail.python.org/mailman/listinfo/python-list
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 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 will be more likely to be fast because the code generator can provide the appropriate optimizations. OTOH, you can almost certainly take automatically generated assembly code and make optimizations the code generator wasn't able to, thanks to knowing more about the real semantics of the program. Yeah, but the other important part of the claim has to do with just that: the real [runtime] semantics of the program. Hand optimization happens before runtime, obviously, whereas the HLL-assembly conversion can happen once the program is running and more info is known about the actual sets of data being operated on, the frequence of function calls, i.e. where the need for optimization actually exists. The optimization could even happen multiple times to adapt over time, or to allow multiple optimizations for different classes of data so that the code that actually executes is highly specialized. So, yeah, knowledge of the runtime behavior can allow a hand-optimized version to run faster than a static, automatically-generated version, but knowledge of the runtime behavior could also allow a dynamic code generator to even beat the hand-optimized version. -Dave -- http://mail.python.org/mailman/listinfo/python-list
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 effectively a command to copy X bytes from left to right; but a specific version of that CPU did this command slower then a loop in certain situations. Some newer generations of that CPU and even some competitors CPU had that command implented correctly, and it was indeed faster than the loop. Now: is it rather likely that for a single programm a programmer is able to get it right for all CPUs? It even gets more complicated. The human mind is able to consider a certain amount of things at once, sth. like on-chip-cache or short-term-memory. Now with an ever growing complexity of processors, with cache lines, partyparallelexecution, branchprediction, out of order execution, multilevelcaching, hypermetathreading ... it may be that the usual availaible human brain is no longer capable of really knowing what happens. My guess is that the average code speed of a Rigopy could indeed be higher than the average code speed of the average assembler programmer. Harald -- http://mail.python.org/mailman/listinfo/python-list
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 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 reason to use assembler language with each passing year. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
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 reference implementation of Python; and also reports that PyPy is only 18 times slower then CPython. well, currently PyPy is around 9-11 times slower than CPython. Since a few weeks ago we are now able to switch stacklessness on and off at compile time to be able to have an interpreter that supports very deeply recursive algorithms, if that is needed. Cheers, Carl Friedrich Bolz -- http://mail.python.org/mailman/listinfo/python-list
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 would also like to see Half Life 2 in pure Python. True, but so what? Why did you suddenly change the discussion to require pure Python? And please define pure Python, given that the interpreter and many builtins, not to mention many widely used extension modules, are coded in C? And are you not allowed to use any of the performance-boosting techniques available for Python, like Pyrex or Psyco? Why such restrictions, when these are things Python programs use on a daily basis: these are *part* of Python, as much as the -O switch on the compiler is part of C/C++. Okay, let's compare a pure Python program (if you can define it in any meaningful, practical way) with a pure Java program, running on a non-JIT interpreter and with optimizations turned off (because, of course, those optimizations are umm... somehow.. not pure...?). 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. -Peter -- http://mail.python.org/mailman/listinfo/python-list
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 generation of CPUs which had effectively a command to copy X bytes from left to right; but a specific version of that CPU did this command slower then a loop in certain situations. Some newer generations of that CPU and even some competitors CPU had that command implented correctly, and it was indeed faster than the loop. Now: is it rather likely that for a single programm a programmer is able to get it right for all CPUs? It even gets more complicated. The human mind is able to consider a certain amount of things at once, sth. like on-chip-cache or short-term-memory. Now with an ever growing complexity of processors, with cache lines, partyparallelexecution, branchprediction, out of order execution, multilevelcaching, hypermetathreading ... it may be that the usual availaible human brain is no longer capable of really knowing what happens. global optimizers for non-C languages can sometimes produce faster code than human C coders, also when those optimizers use C as an intermediate language... /F -- http://mail.python.org/mailman/listinfo/python-list
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 would also like to see Half Life 2 in pure Python.
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.
And FWIW, I'd like to see any similar game in pure Java !-)
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
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 correct, it will be more likely to be fast because the code generator can provide the appropriate optimizations. I think this is just a restatement of existing motivations for using high-level languages and compilers. My impression is that PyPy takes inspiration from work which showed that run-time knowledge can sometimes produce code that is better optimised than that produced by a compiler. That said, when everyone starts showing off their favourite benchmarks, it might be more interesting not to parade some festival of arithmetic yet again. Where more recent versions of the Java virtual machines have improved is in their handling of object memory allocation, amongst other things, and merely scoffing that Java is slow (by pulling specific/specialised extension packages out of the hat) fails to acknowledge the potential for similar improvements (and others) in Python, especially where programs involving plain objects - as opposed to numbers, and where no conveniently available and wrapped C/C++ package exists for the task - are concerned. Paul -- 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, they arise either from specific situations or from general observations gained from running programs written only in Python (from the author's perspective, without having written C/Pyrex/Boost extensions). And please define pure Python, given that the interpreter and many builtins, not to mention many widely used extension modules, are coded in C? From the point of view of an application developer, a pure Python solution could be one where they only wrote Python code. Of course, I can claim to deliver various solutions in pure Python, knowing that some extension module that I didn't write will be doing all the hard work, but it's useful to think of deployment complications: how easy would it be for me to deploy my application on some obscure platform that Python runs on? A pure Python solution would have limited extension module dependencies and thus be relatively easy to deploy, whereas a reliance on a module that hasn't been ported to RISC OS, for example, would severely impair portability. And are you not allowed to use any of the performance-boosting techniques available for Python, like Pyrex or Psyco? Well, from the point of view of an application developer, writing Pyrex isn't quite the same as writing Python. There are variants of Java that change the semantics of the language in order to achieve better performance or certain run-time guarantees, but no-one would honestly claim that they would be writing pure Java if they were really coding for those variants. Psyco is admittedly a tool that provides improved performance with compatible semantics within the Python toolset. I'm not familiar with its effect on all kinds of programs, however, but if performance was a critical factor for a system, I wouldn't begrudge anyone from using Psyco. [...] Okay, let's compare a pure Python program (if you can define it in any meaningful, practical way) with a pure Java program, running on a non-JIT interpreter and with optimizations turned off (because, of course, those optimizations are umm... somehow.. not pure...?). This remark is somewhat ridiculous given that the Java virtual machine is suitably designed/specified to permit just-in-time complication. Running Java programs on some interpreter seems like an arbitrary and absurd exercise, especially when, by engaging in the process of writing Java, one has already abandoned some high-level language semantics in order to exploit the performance benefits of the virtual machine architecture. Sure, Python-oriented systems can be faster than Java-oriented systems, or indeed many other kinds of systems, but such posturing on the notion of purity would seem to suggest a denial of any need for an investigation into the benefits of improved run-time performance for programs written in Python - a view which contradicts the work done by the most prominent project in this field, whilst reinforcing various community perceptions and attitudes that unjustifiably consign worthwhile work on this topic to the fringes. Paul -- http://mail.python.org/mailman/listinfo/python-list
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
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 more likely to be correct, it will be more likely to be fast because the code generator can provide the appropriate optimizations. I think this is just a restatement of existing motivations for using high-level languages and compilers. My impression is that PyPy takes inspiration from work which showed that run-time knowledge can sometimes produce code that is better optimised than that produced by a compiler. That said, when everyone starts showing off their favourite benchmarks, it might be more interesting not to parade some festival of arithmetic yet again. Where more recent versions of the Java virtual machines have improved is in their handling of object memory allocation, amongst other things, and merely scoffing that Java is slow (by pulling specific/specialised extension packages out of the hat) fails to acknowledge the potential for similar improvements (and others) in Python, especially where programs involving plain objects - as opposed to numbers, and where no conveniently available and wrapped C/C++ package exists for the task - are concerned. Paul For example, binary trees http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all -- http://mail.python.org/mailman/listinfo/python-list
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++ programs out there now. I would also like to see Half Life 2 in pure Python. True, but so what? Why did you suddenly change the discussion to require pure Python? And please define pure Python, given that the interpreter and many builtins, not to mention many widely used extension modules, are coded in C? And are you not allowed to use any of the performance-boosting techniques available for Python, like Pyrex or Psyco? Why such restrictions, when these are things Python programs use on a daily basis: these are *part* of Python, as much as the -O switch on the compiler is part of C/C++. Okay, let's compare a pure Python program (if you can define it in any meaningful, practical way) with a pure Java program, running on a non-JIT interpreter and with optimizations turned off (because, of course, those optimizations are umm... somehow.. not pure...?). 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. -Peter That form of argument is listed as one of the principal forms of illogical thinking in Being Logical D.Q.McInerny - An Inability to Disprove Does Not Prove The fact that there is no concrete proof against a position does not constitute an argument in favour of the position. I cannot claim to be right simply because you can't prove me to be wrong. -- http://mail.python.org/mailman/listinfo/python-list
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. That form of argument is listed as one of the principal forms of illogical thinking in Being Logical D.Q.McInerny - An Inability to Disprove Does Not Prove Good thing this is the form of argument *against* which I was arguing, rather than that which I choose to use myself. (Read very carefully, if you really think I was saying otherwise, and point out exactly where I made any such claims for my own part. In fact, I was referencing the arguments of others -- who *were* supporting their arguments with facts, as near as I can tell -- and I was calling on the opposition to do the same, and without changing the rules mid-discussion.) The fact that there is no concrete proof against a position does not constitute an argument in favour of the position. I cannot claim to be right simply because you can't prove me to be wrong. Isn't that what I was saying? That those who claim Python isn't faster were not supporting their arguments with actual facts? -Peter -- http://mail.python.org/mailman/listinfo/python-list
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, version 1 of the system doesn't have the command. Version 2 does, but it's no better than the obvious hand-coded loop. Version 3 finally makes it faster than the hand-coded loop, if you assume you have the instruction. If you have to test to see if you can use it, the hand-coded version is equally fast. Version 4 makes it faster even if you do the test, so you want to use it if you can. Of course, by then there'll be a *different* command that can do the same thing,j and is faster in some conditions. Dealing with this in assembler is a PITA. If you're generating code on the fly, you generate the correct version for the CPU you're running on, and that's that. It'll run at least as fast as hand-coded assembler on every CPU, and faster on some. If you wire everything down, you can always hand-code assembler that will be faster than HLL code (though even sharp programmers can miss tricks the compiler won't). But things don't stay wired down - the CPU gets upgraded, caches change size, pages change size, the data gets bigger, etc. Hand-tuned code doesn't deal well with such, whereas generated code can be made to do just that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
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 speed. Maybe there is even a special processor command to do that. Chances are, version 1 of the system doesn't have the command. Version 2 does, but it's no better than the obvious hand-coded loop. Version 3 finally makes it faster than the hand-coded loop, if you assume you have the instruction. If you have to test to see if you can use it, the hand-coded version is equally fast. Version 4 makes it faster even if you do the test, so you want to use it if you can. Of course, by then there'll be a *different* command that can do the same thing,j and is faster in some conditions. Dealing with this in assembler is a PITA. If you're generating code on the fly, you generate the correct version for the CPU you're running on, and that's that. It'll run at least as fast as hand-coded assembler on every CPU, and faster on some. Actually I think the post you quote went on to make a similar point. 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 processors. http://seattlepi.nwsource.com/business/250070_goto29.html (actually from the NY Times, apparently) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
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-real-world purity requirements. That form of argument is listed as one of the principal forms of illogical thinking in Being Logical D.Q.McInerny - An Inability to Disprove Does Not Prove Good thing this is the form of argument *against* which I was arguing, rather than that which I choose to use myself. (Read very carefully, if you really think I was saying otherwise, and point out exactly where I made any such claims for my own part. In fact, I was referencing the arguments of others -- who *were* supporting their arguments with facts, as near as I can tell -- and I was calling on the opposition to do the same, and without changing the rules mid-discussion.) The fact that there is no concrete proof against a position does not constitute an argument in favour of the position. I cannot claim to be right simply because you can't prove me to be wrong. Isn't that what I was saying? That those who claim Python isn't faster were not supporting their arguments with actual facts? -Peter *Python is faster than Java. Let those who believe otherwise prove their point with facts* We must be looking at different threads :-) afaict the only posting that provided something like facts was http://groups.google.com/group/comp.lang.python/msg/309e439697279060 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? -- http://mail.python.org/mailman/listinfo/python-list
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 processors. http://seattlepi.nwsource.com/business/250070_goto29.html (actually from the NY Times, apparently) Goto No Longer Considered Harmful ? ;-) -- http://mail.python.org/mailman/listinfo/python-list
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/listinfo/python-list
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 their opponents with non-real-world purity requirements. That form of argument is listed as one of the principal forms of illogical thinking in Being Logical D.Q.McInerny - An Inability to Disprove Does Not Prove Good thing this is the form of argument *against* which I was arguing, rather than that which I choose to use myself. (Read very carefully, if you really think I was saying otherwise, and point out exactly where I made any such claims for my own part. In fact, I was referencing the arguments of others -- who *were* supporting their arguments with facts, as near as I can tell -- and I was calling on the opposition to do the same, and without changing the rules mid-discussion.) The fact that there is no concrete proof against a position does not constitute an argument in favour of the position. I cannot claim to be right simply because you can't prove me to be wrong. Isn't that what I was saying? That those who claim Python isn't faster were not supporting their arguments with actual facts? -Peter *Python is faster than Java. Let those who believe otherwise prove their point with facts* We must be looking at different threads :-) afaict the only posting that provided something like facts was http://groups.google.com/group/comp.lang.python/msg/309e439697279060 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? Is there such an animal? I only know about Java's BigInteger. And if there is, it just proves my point that benchmarks are worthless. -- http://mail.python.org/mailman/listinfo/python-list
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 a language for writing games.best regardskrystian-- http://mail.python.org/mailman/listinfo/python-list-- And whoever does an atom's weight of evil will see it. -- 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 all GMPYs and alike are written in Java - now wrappers to C-libraries. Python, by design, is glue language. Python program is assembly of C extensions and buildins wrapped in Python sintax. IHMO real life benchmark yuo are critisizing represents real life situation. -- http://mail.python.org/mailman/listinfo/python-list
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: 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. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck. --USENET schmuck (aka Robert Kern) -- http://mail.python.org/mailman/listinfo/python-list
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=alllang=javalang2=pythonsort=fullcpu could you take an attitude with regard to this benchmark? Take a look at PyGame. on my way :) best k -- http://mail.python.org/mailman/listinfo/python-list
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.debian.org/benchmark.php?test=alllang=javalang2=pythonsort=fullcpu could you take an attitude with regard to this benchmark? Benchmarks are worthless. By that I mean they have no value to me. What matters is the performance on real problems, such as generating the 1st 6th Generation Type [1,2] Mersenne Hailstone Collatz sequence. That's a BIG number and needs BIG arithmetic to solve. Java has a BigInteger module and can solve it in less than 10 minutes: C:\Python23\user\pyjavajava Collatz 2 177149 1 Processing time: 571690 x/2 iterations: 1531812 3x+1 iterations: 854697 The arguments evaluate to 2**177149-1. And because this is a Mersenne number, the sequence diverges until it's over 28 bits before converging to 1 bit after 2386509 iterations. But is 571 seconds a reasonable amount of time for such a difficult problem? Compare it to Python with the GMPY module: C:\Python23\user\pyjavacollatz.py 2 177149 1 r1 1531812 r2 854697 in 72.986886 seconds Yes, it would appear that in this real world application Java is ridiculously slow. Of course, Python is doing the heavy lifting with GMPY which is a compiled C program with a Python wrapper. But so what? Maybe the reason I use Python is BECAUSE the math module is compiled C. Duh. With Python/GMPY I get the high level power I need for the algorithms without sacrificing the low level muscle I need for the heavy arithmetic. Take a look at PyGame. on my way :) best k -- http://mail.python.org/mailman/listinfo/python-list
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 serving throughput for the same hardware configuration versus even something that is mod_python based (but I believe the speed diff would be well under 100%). However, Python is just so much superior as a language (I was deep into PHP before I tried out Python and I always hate having to go back to PHP nowadays in the cases where it is unavoidable) that you will still want to use Python even if PHP requires lower server specs to handle the same throughput. Also, if you have a more complex application for which pooled variable reuse is an important performance-determining factor, Python-based server-side scripting solutions might offer better control of this aspect and may thus yield superior performance to a PHP-based one. The real problem with Python is not speed but _availability_. The number of hosting services out there supporting mod_php completely outstrips those supporting mod_python. Moreover, they are significantly cheaper, and offer a lot more features (Fantastico, etc...). The python-based hosting solutions out there tend to be dedicated to Python and thus do not offer these solutions. If this is not an issue (i.e. you will be running your own server), then I highly recommend going the Python route using something like Spyce (which is the closest thing to PHP in the Python world). -- 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 speed diff would be well under 100%). I have different experience. When I moved from PHP to Webware and I compared its performance with (similar scale) php appplications, my webware was almost 6 times faster! Application servers are always faster because they use compiled scripts stored in memory. They do not need to load files from filesystem nor parse them. PHP is faster only for trivial, useless benchmarks like Hello world. For bigger code Python is faster than PHP. The real problem with Python is not speed but _availability_. You have rigth here. -- JZ -- http://mail.python.org/mailman/listinfo/python-list
