>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The problem perl will always run into is that our executable code
DS> counts as data to CPUs, and lives in the D cache, along with all
DS> the data we work on. Ripping through a few 100K strings'll kill
DS> any sort of benefits to keeping the optree small, though how often
DS> that happens is also up in the air. (I really want a CPU with
DS> three caches, I, D, & perl optree...)
if we generate TIL, then some/most of the optree stuff (the calls and
returns) will be in the I cache. no need to scan the op tree in the D
cache then. this could be a real win for TIL (we need a new name for
threaded in line code since thread is too overloaded now).
DS> That's not entirely true. When I think "This'll run faster!" about
DS> some clever bit of hackery, I'm almost inevitably wrong. Terribly
DS> handy, that. :)
and i trust your misjudgment! :)
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
