Request from Intel's Museum

From: Frank McConnell <fmc_at_reanimators.org>
Date: Wed Oct 9 17:56:00 2002

"Dwight K. Elvey" <dwightk.elvey_at_amd.com> wrote:
> Still, I don't understand why many are not going to more
> efficient memory optimization than apparent execution speed.
> The compiler writers have a ways to go. The day is gone
> when pinhole optimization buys much. Keeping the process
> in on chip cache is really the important thing.

As someone who writes code that goes through compilers, the reason why
I don't think too hard about the on-chip cache is because I have no
idea about the size or architecture of that on-chip cache. Well,
I have some idea, and that's that I can't count on it.

OK, so the products I work on are sold as portable C source that
is expected to build and run on a bunch of different processors,
some of which don't have any cache but may be clocked slow
enough for SRAM to keep up. I may not be the programmer you have
in mind.

So, let's take instead the case of someone writing code to run on
Win32. Reading the side of a box for something newish like that,
we could narrow it a bit further, to Win98, WinME, and Win2000
(hmm, maybe that's why this thing was in the closeouts pile, no WinXP).
That could be running on anything made in the last four years, and
what have x86 processor manufacturers done with on-chip caches in
that time? Overall I suspect it's an upward trend but I'm thinking
there were some local downturns for things like the early Celerons
to keep them from competing too effectively with Pentium IIs, but
as mentioned above I haven't really been paying attention.

I am thinking that the programmer will probably not know even if he
does want to think about writing code to fit in on-chip cache, and
he's the compiler vendor's customer. How is the compiler vendor
supposed to have any idea what the eventual target's on-chip cache
will be like?

-Frank McConnell
Received on Wed Oct 09 2002 - 17:56:00 BST