[parsec-users] regarding simulation stopping criterion

sparsh mittal sparsh0mittal at gmail.com
Tue Jan 31 15:32:32 EST 2012


Thanks a lot for your detailed response and help. I will look into this
more, with the help of your answer.
Thanks and Regards
Sparsh Mittal




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

> **
> 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
> #endif
>     ... oiriginal code ...
>  #if defined(UsingMySimulatedCPU)
>     *((intptr_t*)~0) = 0; // 0=stop IPC counters
> #endif
> } // 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.
>
> QED
>
> Jim Dempsey
>
>  ------------------------------
> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *sparsh mittal
> *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>
>
>> **
>> 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.
> Thanks.
>
>
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20120131/769dc29c/attachment.html>


More information about the parsec-users mailing list