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

[Tim Peters]

[M.-A. Lemburg]
> ...
> I haven't followed the thread too closely, but isn't there
> some way to tell the optimizer which modules to treat at
> what optimization level ?

No.  I'm trying to introduce a "decl" stmt, though, that can in principle
express any thought capable of human expression <wink>.

> 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.

> ...
> 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!>.

> 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!

silly-cpus-ly y'rs  - tim