[parsec-users] Simulation time of "facesim" and "vips"

Jim Dempsey jim at quickthreadprogramming.com
Tue Jun 1 10:16:09 EDT 2010

Oops, make that "Back in the early 1970's..." (1972 actually)


From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Jim
Sent: Tuesday, June 01, 2010 8:09 AM
To: 'PARSEC Users'
Subject: Re: [parsec-users] Simulation time of "facesim" and "vips"

>>As far as I understand your response you are asking me to Optimize I/O of
"facesim" and "vips" using actual and virtual time.
Back in the late 1960's when I worked at Digital Equipment Corporation I
used a simulator on their PDP10 that would simulate a PDP8-I computer system
including all the I/O devices. The computer being simulated was single core
and therefore the virtual time was elastic. By this I mean I/O wait time
could be simulated, or estimated, or instantaneous (immediately complete in
virtual system).
The simulator you use simulates multi-core systems. Not being a user of this
system, I can only hypothesize. 
The simulator you use:
    may not
    or have option to control
simulation of disk level I/O. If your simulator (settings) present a fully
accurate disk sub-system, then the I/O wait time by one thread is not
elastic. Meaning the virtual I/O wait time by one simulated core is
available run time for remaining simulated cores (and available for the I/O
initiating core since the initiating software thread is likely context
switched out). If your simulator is executing at, for example, 1/100th the
rate a real system operates at, then I/O operations on physical system that
takes 8ms will consume wall clock time of 800ms. The actual consumption will
depend on the difference between your wall clock time and virtual time (i.e.
performance of simulator).
Check your documentation to see if the I/O wait time is tunable. (or choose
to simulate a SSD or RAM-disk)
The point I was making is if you can set a tuning parameter to eliminate I/O
wait time, then you may also wish to accumulate the physical I/O wait time
when you run stand alone, and accumulate the virtual no wait I/O wait time
(likely non-zero). With the two lists at hand you can now re-adjust the
results data for a better estimate on the relative performance. This won't
be completely accurate, but it may be a better estimate of the virtual
Also, with the list of timestamp differentials in your real simulation, and
knowing the simulation rate of facsim in your simulation, you can now let
your simulation run for ? 8 hours (you pick convenient time), extract the
number of iterations of the major loop, then extrapolate the completion
time. This will be a rough estimate which is better than no estimate.
Jim Dempsey


From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Muhammad
abid Mughal
Sent: Tuesday, June 01, 2010 12:35 AM
To: PARSEC Users
Subject: Re: [parsec-users] Simulation time of "facesim" and "vips"

Hi Jim Dempsey,    
                         Thanks for quick response.
I have already successfully run "facesim" and "vips" using "parsecmgmt -a
run -p vips -c gcc-hooks -i simsmall -n 8 -x pre-simics" command on
    my real sun machine  and simulated machine inside simics (ie functonal
simulation).In addition, i disabled all SMF services of solaris 10 inside my

simulated machine so that these services don't interfere with my PARSEC

As far as i understand your response you are asking me to Optimize I/O of
"facesim" and "vips" using actual and virtual time.

My simulated machine is 8-chip distributed shared memory machine and i am
working on prefetching/memory streaming using Hardware Prefecher.
I am confused because i was planning to run simulations using "simmedium"
data set but i would not be possible because of simulation speed.

I am wondering if i increase number of threads for facesim and vips to
finish simulation quickly. Any more suggestion.

Muhammad abid


From: Jim Dempsey <jim at quickthreadprogramming.com>
To: PARSEC Users <parsec-users at lists.cs.princeton.edu>
Sent: Tuesday, June 1, 2010 11:39:56
Subject: Re: [parsec-users] Simulation time of "facesim" and "vips"

Have you verified first that your configuration runs well in native mode on
an x86 processor? This is to make sure your input data and command line
arguments are correct. And will give you a base line measurement for a given
processor model.
The next thing to do is look at the major loop in facesim to see if you can
instrument that in native mode. e.g. on the native mode run, use RDTSC (or
other high precision timer) and record the time intervals for each iteration
of the major loop. After you have this collection of times (convert to
seconds) then recode to use a virtual timer in your simulation mode, however
also modify the simulator such that you get progress information such as the
virtual time elapsed .AND. the actual time elapsed at each major loop
interval. Now then instead of running simulation to end of benchmark
program, you can run the simulation for as many iterations as you deem
practical and which provides the timing information you want.
Also, while you are adding your RDTSC insturmentation, measure the time for
each file I/O. Then you can use this data to normalize the I/O within the
Jim Dempsey


From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Muhammad
abid Mughal
Sent: Monday, May 31, 2010 8:32 PM
To: Parsec group
Subject: [parsec-users] Simulation time of "facesim" and "vips"

Hi guys/Chris,
                        Hope you all doing good. I am running timing
simulation of above-said benchmarks using "simsmall" data set.
But its been running for almost 7 days. Is there anyway to reduce this huge
simulation time for these benchmarks without compromising on the performance
measurement accuracy? ie performance measurement must be representative of
the work done by these benchmarks.

i find it hard to switch to another Simulator fast simulator (ie Flexus) . I
am using GEMS simulator.

Muhammad abid

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

More information about the parsec-users mailing list