"Robert W. Cunningham" wrote:

> By the time Plex86 makes it to 1.0, I suspect the P6 architecture will be dead
> and gone.

Ye have little faith.


> Make that decision, to effectively restrict the target platform to a single
> processor architecture, then we can talk about more precise cache optimization!

People are going to run plex86 on a spectrum of platforms.  This is software
for as many people as possible.  There's no need to restrict the internals
to a particular architecture (except we use Pentium+ features).  One of the
best techniques I've learned is to code small testbed segments, try them
out on various processors, and get a general understanding of how it
reacts.  Then integrate it into the whole code framework.  Run it varying
parameters (compile time or runtime), until you get a set of optimal
numbers.  Then feedback this info into compiletime/runtime/hardcoded
parameters, so that the software can be run efficiently on various
systems.

Changing the set of programs you run inside the VM will greatly effect
the performance.  Thus, it's best to let people be able to tweak things
where possible.  First attempts, generally are less flexible, but are
great testbeds for gathering valuable instrumentation data.  But gearing
for one architecture doesn't solve the problem, because there can be
a huge amount of interdependency between the host architecture and
the user specific workload.  The person using (and compiling) the
program should decide such parameters, not you.

If the code is real smart, it could even be put into a special
instrumentation mode, where at the end of the run, it spits out
statistics which can be used to fine-tine the parameters for the
workload that was run.  So subsequent runs will be more optimal.

There is no one optimal strategy, even for one specific stepping
model of any given CPU.  A web server running inside the VM may
require completely different parameters than a compression algorithm.
This is further complicated and constrained by other attributes
of the VM environment, such as the workload imposed on the host
OS, interrupt rates used by the guest OS where each context switch
necessitates certain decoupling/recoupling of translated code
fragments, clocking skewing which magnifies the interrupt rate,
cache competition between the host and VM/guest, etc.

<non-sequitur>
I think it was Mark Twain who said something like "Never let
school get in the way of a good education."
</non-sequitur>

-Kevin


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton                        [EMAIL PROTECTED]
MandrakeSoft, Inc.                  Plex86 developer
http://www.linux-mandrake.com/      http://www.plex86.org/

Hopkins' Law: no clever idea in computer architecture ever goes unpunished.

Reply via email to