Andrew McNamara wrote: >>The general problem with the ceval switch statement is that it >>is too big. Adding new opcodes will only make it bigger, so I doubt >>that much can be gained in general by trying to come up with new >>do-everything-in-one-opcode cases. > > [...] > >>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). > > My experience with gcc (on x86) is that it uses a lookup table > for contiguous switch statements rather than a long chain of > compares/branches. A quick look at the assembler output from ceval.c > suggests it's using a lookup table. Right, but the code for the case implementations itself is ordered (more or less) in the order you use in the C file. At least that was the case at the time (which must have been GCC 2.95.x or even earlier). > What architecture did you observe > this on? Linux. -- 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