On Tue, 8 Aug 2000, Ken Fox wrote:
> Dan Sugalski wrote:
> > The problem perl will always run into is that our executable code counts as
> > data to CPUs, and lives in the D cache, along with all the data we work on.
> > Ripping through a few 100K strings'll kill any sort of benefits to keeping
> > the optree small ...
>
> Which is an argument for making it large? ;)
Nah, it's an argument for multiple targeted D caches on a chip. Alas we
don't have any of those handy. :)
> I don't think we can do much about cache issues except work on locality.
> Can we figure out what data is going to be used most by what op stream and
> put them on the same page? For example, if a regex is applied to an I/O
> buffer, it would help to allocate the buffer and the regex on the same
> memory page.
I need to go check (just what I need--more books on the stack) but IIRC
generally things aren't cached on a per-page basis, rather they're cached
on a per cache-line basis, and cache lines are smaller than pages.
(Considerably in some cases. Alphas have a native page size of either 8k,
16k, or 32k...) At least the L1 caches do. I don't know about the L2, but
I'd bet they did too. (Alan?)
Dan
