Usually we break our workloads into, for lack of a better word,
transactions. These are NOT TM transactions -- they are 'cohesive,
workload-specific units of work'. Examples are: Client interactions in
apache, Database transactions in our OLTP workload, iterations of the
main loop of a scientific code.
We augment the simulator with magic calls to delineate transaction
boundaries whereever possible. This is referred to as a 'workload
transaction' in the magic_call.h source code. Ruby can intercept these
magic calls and automatically stop execution after N workload
transactions have completed (have a look at how gen-scripts works). This
guarantees the same amount of 'work' has been done, even when different
execution paths have been followed.
This strategy is robust even for non-deterministic workloads, but as
usual requires long runs to attain a statistically significant average.
You should use RUBY_CYCLES as the time measurement, naturally. Your
performance metric should be RUBY_CYCLES per transaction or the
reciprocal of that measure.
As an aside, instruction count is fine as a proxy for work if your
workload is single-threaded and your Simics checkpoint has only one
processor.
Regards,
Dan
Zhang Yu wrote:
Thanks. I just want to run some application on different
configurations. Since it will take very long time for the whole
application to complete, I can only afford to run it partially. So,
what I do is making the simulation run for a certain number of cycles.
Then, the number of instructions executed would be a metric of
performance. That's why I care so much about this. If the instruction
counts is not reliable, what would you suggest me to do?
Thanks,
Yu
On Jan 29, 2008 2:00 PM, Dan Gibson <degibson@xxxxxxxx
<mailto:degibson@xxxxxxxx>> wrote:
I think the user/OS instruction counts are subject to a lot of
factors.
The 'init' process on Linux for instance is user-level. I'm not
sure if
there is an analogue on Solaris or not, but relying on instruction
counts is not a good idea anyway for multiprocessor systems, since
multiprocessors will often experience entirely different execution
paths
from run to run.
Zhang Yu wrote:
> I only care the number of instructions from the user. pstats
gives two
> kind of instruction count, one is from the user and the other is
from
> the supervisor, I guess the OS idle loop may increase the
instruction
> counts of the supervisor but will not impact that of the user.
>
> Thanks,
> Yu
>
> On Jan 29, 2008 1:47 PM, Dan Gibson <degibson@xxxxxxxx
<mailto:degibson@xxxxxxxx>
> <mailto:degibson@xxxxxxxx <mailto:degibson@xxxxxxxx>>> wrote:
>
> Processors will always execute SOME code somewhere -- pstats is
> agnostic
> to which code is executed. That is, even the execution of
the OS idle
> loop will cause the pstats instruction counts to increment-- you
> cannot
> assume processors that you do not assign tasks do not execute
> instructions.
>
> Zhang Yu wrote:
> > Thanks for the reply. However, what I mean of pstats is
already a
> > delta of the instructions (I did the calculation myself).
And in my
> > case, the number of instructions executed by each processor
> should not
> > be equal or similar.
> >
> > Yu
> >
> > On Jan 29, 2008 12:15 PM, Dan Gibson <degibson@xxxxxxxx
<mailto:degibson@xxxxxxxx>
> <mailto:degibson@xxxxxxxx <mailto:degibson@xxxxxxxx>>
> > <mailto:degibson@xxxxxxxx <mailto:degibson@xxxxxxxx>
<mailto:degibson@xxxxxxxx <mailto:degibson@xxxxxxxx>>>> wrote:
> >
> > The number of instructions reported by ruby is a delta
> between the
> > initial instruction count and the final instruction
count. The
> > number of
> > instructions reported by pstats is a total instruction
count,
> > staring at
> > boot-time if I am not mistaken. Hence the discrepancy.
> >
> > Zhang Yu wrote:
> > > Hi,
> > >
> > > I'm using Gems2.0 with Simics3.0.30. While I run the
> simulation with
> > > multiple cores, the statistics dumped by ruby seems
to be
> > > unreasonable. For example, when I use "taskset"
command to
> assign a
> > > single task to a certain processor, instruction_executed
> for all the
> > > processors are almost the same in the ruby statistics.
> However, if I
> > > use "pstats" command in simics, I can see obviously that
> the certain
> > > processor executed much more instructions than other
> processors. So,
> > > is there anything I can do to make the ruby stats
seems more
> > reasonable?
> > >
> > > Thanks,
> > > Yu
> > >
> >
>
------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx
<mailto:Gems-users@xxxxxxxxxxx> <mailto:Gems-users@xxxxxxxxxxx
<mailto:Gems-users@xxxxxxxxxxx>>
> <mailto:Gems-users@xxxxxxxxxxx
<mailto:Gems-users@xxxxxxxxxxx> <mailto:Gems-users@xxxxxxxxxxx
<mailto:Gems-users@xxxxxxxxxxx>>>
> > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > Use Google to search the GEMS Users mailing list by
adding
> > "site:https://lists.cs.wisc.edu/archive/gems-users/";
to your
> search.
> > >
> > >
> >
> > --
> > http://www.cs.wisc.edu/~gibson
<http://www.cs.wisc.edu/%7Egibson>
> <http://www.cs.wisc.edu/%7Egibson>
<http://www.cs.wisc.edu/%7Egibson>
> > [esc]:wq!
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
<mailto:Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>>
> <mailto:Gems-users@xxxxxxxxxxx
<mailto:Gems-users@xxxxxxxxxxx> <mailto:Gems-users@xxxxxxxxxxx
<mailto:Gems-users@xxxxxxxxxxx>>>
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding
> > "site:https://lists.cs.wisc.edu/archive/gems-users/";
to your
> search.
> >
> >
> >
>
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
<mailto:Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>>
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your
search.
> >
> >
>
> --
> http://www.cs.wisc.edu/~gibson
<http://www.cs.wisc.edu/%7Egibson> <http://www.cs.wisc.edu/%7Egibson>
> [esc]:wq!
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
<mailto:Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>>
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your
search.
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>
--
http://www.cs.wisc.edu/~gibson <http://www.cs.wisc.edu/%7Egibson>
[esc]:wq!
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
------------------------------------------------------------------------
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}