Neil Schemenauer wrote:
> Christian Tismer wrote:
>
>>Where you really can save some time is to shortcut some
>>of the very short opcodes to not jump back to the ticker
>>counting code, but into a shorter circle.
>
>
> 2.2 -> 2.3 includes this optimization for some opcodes.
Oh! *blush*
I should read more of this :-)
>>Not trying to demoralize you completely, but there are
>>limits about what can be gathered by optimizing the
>>interpreter loop. There was once the p2c project, which
>>gave an overall improvement of 25-40 percent, by totally
>>removing the interpreter loop.
>
>
> Yes, but p2c was probably not nice to the icache. I doubt 25-40% is
> an upper bound. Memory bandwidth really sucks now (relatively
> speaking). I think reference counting is now starting to look like a
> smart design (in terms of performance). :-)
Yes, it created lots of code, and for sure, code repetition
can be helpful, if the relevant pieces are kept tightly together.
But I still doubt bigger improvements, since most of the time
is spent in the C library code. You need to optimize this
away, too.
ciao - chris
--
Christian Tismer :^) <mailto:tismer@tismer.com>
Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4