[parsec-users] regarding simulation stopping criterion

sparsh mittal sparsh0mittal at gmail.com
Tue Jan 31 14:54:47 EST 2012

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

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

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/346230fa/attachment.html>

More information about the parsec-users mailing list