damien morton wrote:
>>From: M.-A. Lemburg [mailto:mal@lemburg.com]
>>
>>Back in the 1.5.2 days I played a lot with the ceval loop and
>>the best results I got came from:
>>
>>a) moving the LOAD_FAST opcode out of the switch
>
>
> Are you suggesting a test for LOAD_FAST before the switch,
>
> e.g.
> if (opcode == LOAD_FAST) {
> // load fast
> }
> else switch (opcode) {
> // body
> }
Yes.
>>b) splitting the switch statement in two: the first one for
>> more commonly used opcodes, the second one for less often
>> used opcodes
>
>
> Are you suggesting something like:
>
> switch (opcode) {
> case COMMON_OP:
> case COMMON_OP:
> ...
> default:
> switch (opcode) {
> case UNCOMMON_OP:
> case UNCOMMON_OP:
> }
Yes, except that in the default case the code is placed after the
first switch.
switch (opcode) {
case COMMON_OP:
goto nextInstruction;
case COMMON_OP:
...
goto nextInstruction;
default:
;
}
switch (opcode) {
case UNCOMMON_OP:
case UNCOMMON_OP:
}
goto nextInstruction;
> Or something like this:
>
> switch (opcode) {
> case COMMON_OP:
> case COMMON_OP:
> ...
> default:
> handle_uncommon_ops();
> }
That's hard to do because the loop has so many variables
to pass into handle_uncommon_ops(). I haven't tried
it though (or at least I don't remember trying it :-),
so perhaps this is even better.
>>c) ordering cases in the switch statements by usage frequency
>> (using average opcode usage frequencs obtained by
>> instrumenting the interpreter)
>
> I might try a little simulated annealing to generate layouts with high
> frequency opcodes near the front and coorcurring opcodes near each
> other.
I did that by hand, sort of :-) The problem is that the
scoring phases takes rather long, so you better start with
a good guess.
>>The last point is probably compiler dependent. GCC has the
>>tendency to use the same layout for the assembler code as you
>>use in the C source code, so placing often used code close to
>>the top results in better locality (at least on my machines).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Feb 28 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 32 days left
EuroPython 2003, Charleroi, Belgium: 116 days left
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