Re: [pypy-svn] r13639 - pypy/dist/pypy/translator/goal
You may be happy to know, on my machine, running cygwin, I get a factor of 2000 for the fast mode! Sounds like you are quite a long way towards your goal! .... (pypy.rpython.exceptiondata:109) ll_pyexcclass2exc__PyObjectPtr -> SomePtr(ll_ptrtype=<ptr(gc) to GcStruct object { typeptr: ptr() to S truct object_vtable { parenttypeptr: ptr() to Struct object_vtable { ... }, rtti: ptr() to RuntimeTypeInfo (opaque), name: ptr() to Arr ay of Char } }>) Back-end optimizations... ------------------------------------------------------------ Generating and compiling C code... Running! translated rpystone.pystones/fast time for 1000000000 passes = 2.16684 This machine benchmarks at 4.61501e+008 translated rpystone/fast pystones/second CPython: rpystone.pystones/fast time for 50000 passes = 0.215902 This machine benchmarks at 231587 rpystone/fast pystones/second ------------------------------------------------------------ Done. --Return--
c:\documents and settings\youngb\dist\pypy\translator\goal\translate_pypy.py(474)debug()->None -> func(*args) (Pdb) 4.61e8/231587 1990.6125991528022 (Pdb)
pypy-svn-bounces@codespeak.net wrote on 20/06/2005 23:14:26:
Author: tismer Date: Tue Jun 21 00:14:25 2005 New Revision: 13639
Modified: pypy/dist/pypy/translator/goal/targetrpystone.py pypy/dist/pypy/translator/goal/targetrpystone2.py Log: did some testing with the newly generated code. At first glance, it looks great, if we can trust the timing. For "slow" mode, I get a factor of 43. For "fast"mode, I get 250 or more, and I bumped the iterations to 10**9. But real run-time seems to be several seconds, so I think we can't trust these results. Something must be wrong with the dry-running. Will look abit deeper when on the train.
Modified: pypy/dist/pypy/translator/goal/targetrpystone.py
==============================================================================
--- pypy/dist/pypy/translator/goal/targetrpystone.py (original) +++ pypy/dist/pypy/translator/goal/targetrpystone.py Tue Jun 21 00:14:25 2005 @@ -1,6 +1,6 @@ import targetrpystonex
-LOOPS = 150000 +LOOPS = 2000000
# targetrpystonex.rpystone.setslow(False)
Modified: pypy/dist/pypy/translator/goal/targetrpystone2.py
==============================================================================
--- pypy/dist/pypy/translator/goal/targetrpystone2.py (original) +++ pypy/dist/pypy/translator/goal/targetrpystone2.py Tue Jun 21 00:14:25 2005 @@ -1,7 +1,7 @@ import targetrpystonex
-LOOPS = 1000000 +LOOPS = 1000000000 #10**9
targetrpystonex.rpystone.setslow(False)
_______________________________________________ pypy-svn mailing list pypy-svn@codespeak.net http://codespeak.net/mailman/listinfo/pypy-svn
Hi Ben! On Tue, Jun 21, 2005 at 09:33:50AM +0100, Ben.Young@risk.sungard.com wrote:
Sounds like you are quite a long way towards your goal!
That's great to impress the crowds indeed :-) But the so-called fast pystone is really not representant of anything at all; it's also extremely machine-dependent, for unknown reasons. The other pystone for example gets a speed-up of anywhere between 13 and 40 on various hardware. Which means that there is still some work to be done... A bientot, Armin
Armin Rigo wrote:
Hi Ben!
On Tue, Jun 21, 2005 at 09:33:50AM +0100, Ben.Young@risk.sungard.com wrote:
Sounds like you are quite a long way towards your goal!
That's great to impress the crowds indeed :-) But the so-called fast pystone is really not representant of anything at all;
Why so negative? This is a bit much of neglection. I've been working with the two rpystone flavors for quite some time, when the old genc code was active, and I have some feeling about it. It feels very different, now. Sure, it is true that there is no real measurement posible at the moment. But in comparison with the former version, chings have changed absolutely dramatically, IMHO: On May 11th, I measured a speed gain of 11-12 on my windows machine in "fast" mode. This is nothing, compared with the current performance, which seems to be at least an order of magnitude better. Without hard facts, this at least tells us that we are generating code that enables many optimizations which were not possible at that time. And this is a very good result.
it's also extremely machine-dependent, for unknown reasons. The other pystone for example gets a speed-up of anywhere between 13 and 40 on various hardware. Which means that there is still some work to be done...
If you meant "platform/compiler dependent", I agree. The timings are not accurate because the code runs too fast. If fast mode is enabled, it is quite likely that some compilers optimize almost everything away. I think dropping fastmode makes sense; it was only created to see how far the old genc gets, without all the non-supported data types. -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
participants (3)
-
Armin Rigo -
Ben.Young＠risk.sungard.com -
Christian Tismer