Damien Morton wrote:
> Christian Tismer wrote:
> So what I would like to try is to merge all opcodes
> which have exactly the same pattern into one case,
> which then does the common preparation stuff and
> postprocessing including error handling, but internally
> dispatches on the function to be called.
>
>
> I tried this on the 2.3a2 source, modifying it to implement your idea.
>
> This was implemented on top of the LOAD_FAST_n, etc, changes.
>
> No luck - it makes the code slower by nearly 5%, decreasing a base 22300
> PyStones to 21100 PyStones. That is, the idea of using function pointers. I
> imagine that a case statement would be even slower.
Too bad. Hmm. Would you mind to send me the source code?
I'd like to see what code is generated.
> I didnt implement the table of function pointers as one monolithic table, as
> the unary and binary functions have different signatures.
They could live in the same table, but probably this
doesn't change memory layout at all.
A case statement might or might not be slower, a branch
might become a little more predictable than though
a function table.
And then, five percent is not bad. Did you measure
how much code you saved in the binary?
thanks - 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