[parsec-users] regarding simulation stopping criterion

Jim Dempsey jim at quickthreadprogramming.com
Tue Jan 31 15:21:43 EST 2012

Your simulated system likely boots an O/S (virtual) and you somehow start a
program within the simulated system to begin a region of interest. An
example might be to boot a virtual Linux O/S with a boot command script that
runs a PARSEC benchmark program. Your interest in generating an IPC might be
to exclude the simulation information from virtual boot (or running image
restore) up to the point of execution of the program of interest (e.g. a
PARSEC benchmark program). If for example you modify the program of interest
(e.g. a PARSEC benchmark program) to issue something like
int main(int argc, char* argv[])
#if defined(UsingMySimulatedCPU)
    *((intptr_t*)~0) = 1; // 1=start IPC counters
    ... oiriginal code ...
#if defined(UsingMySimulatedCPU)
    *((intptr_t*)~0) = 0; // 0=stop IPC counters
} // int main(
And you modify your simulator for writes to 0xFFFFFFFF(FFFFFFFF) as a
message for start/stop IPC.
Then the above will be suitable for whole program run. You might want to
enable/disable IPC counting for the duration of the PARSEC ROI since you may
want to skip the datafile read-in and/or other initialization. (i.e relocate
the  #if defined(UsingMySimulatedCPU) ... to the PARSEC code that
starts/stops its ROI.
You can also use different codes for start/stop per simulate hardware
thread. This likely would require edits to one or two additional places in
the original code.
If these runs take too long, the host machine that is running the simulation
can add a feature to the simulator that should be able to take a keypress
or, like many profilers use a runtime of nnn seconds (following the
"*((intptr_t*)~0) = 1; // 1=start IPC counters"). You could use simulated
instruction counts or wall clock time interval or virtual wall clock time
interval. You have control as to do what you want.
Jim Dempsey


From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of sparsh
Sent: Tuesday, January 31, 2012 1:55 PM
To: PARSEC Users
Subject: Re: [parsec-users] regarding simulation stopping criterion

2012/1/31 Jim Dempsey <jim at quickthreadprogramming.com>

Are you 
a) simulating a multi-core processor that is running multiple programs
and/or parallel programs

Yes. I am running cycle-accurate simulation of single-threaded
multi-programmed workload. Currently I am not using parallel or
multithreaded program.

b) running a simulation program (e.g. those in PARSEC) and measuring the
performance of the simulation program
Typically PARSEC users use b), but there are a few testing out there
processor designs using a)
Since you reference your interest is in IPC I will assume you mean
Instructions Per Cycle, and therefor you too are also interested in a)
Can you clarify this?
Often when doing a) you would do something analogous to the PARSEC Region Of
Interest (ROI). In your case you would add a call in your source code to
indicate start of region of interest and a call to indicate end of region of
interest. Your simulation engine may have something designed for this
purpose, if not, and if you have the sources to your simulation code, this
can be easily added, as an example, of writing a value (message) to an
otherwise invalid address, which is interpreted by your simulator as a
control message as opposed to bug in simulated program.
Jim Dempsey

Thanks a lot for your suggestion. My main interest is in using a stopping
criterion, such that my simulations do not become very long. Method 1 (my
last mail) is a widely accepted method, but for long simulations and
different kinds of benchmarks, it may lead to very very long simulations
(e.g. one benchmark finishes 10B instruction, while other has only done its
specified 500M instruction). To avoid such issue, I am looking for
alternative stopping criterion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20120131/b244ed58/attachment.htm>

More information about the parsec-users mailing list