[Types-sig] Low-hanging fruit: recognizing builtins

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [M.-A. Lemburg]
> > BTW, instead of adding oodles of new byte code, how about
> > grouping them... e.g. instead of UNARY_LEN, BUILD_RANGE, etc.
> > why not have a CALL_BUILTIN which takes an index into
> > a predefined set of builtin functions.
> 
> It's another tradeoff.  UNARY_LEN is simple enough that the code for
> builtin_len could be put in the case stmt inline, but skipping the argument
> check.  Read it out of a table instead, and you're back to Yet Another
> Function call, or an embedded switch stmt in CALL_BUILTIN's implementation.

Sure its a tradeoff, but it has the advantage of allowing to
extend it later without adding too much cruft to the inner loop.
What it basically does is avoid the global *and* local lookups
by replacing them with a C array index lookup.

Of course, for very common things such as len and range some
other strategy might be worth persuing.
 
> > ...
> > Note that the loop as it is built now is already too large
> > for common Intel+compatible based CPUs.
> 
> I assume this is Flowery Language for your particularly lame AMD K6 <wink --
> ah, the satsifaction of being a Pure Wintel Guy!>.

The performance improvement mentioned below is not really
noticable on machines with different architectures, e.g.
Sun SPARC. That's where I drew my conclusion from. But then,
I tested a few years ago, so perhaps the new Pentiums and
Athlon don't gripe about the size of the inner loop anymore.

BTW, just to make buying one of those new microwave
ovens more attractive: what is the pystone rating for
the new Athlon and Pentium III chips ?

> > Adding even more byte codes to the huge single loop would
> > probably result in a decrease of CPU cache hits. (I split the
> > Great Switch in two switch statements and got some good results
> > out of this: the first switch handles often used byte codes
> > while the second takes care of the more exotic ones.)
> 
> Good strategy!

Thanks :-)

We are getting a little off-topic here, I'm afraid, but it
was fun looking at old optimization strategies again...
I haven't touched that code in years.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    14 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/