Re: [Gems-users] instruction count

["Zhang Yu" <thuzhangyu@xxxxxxxxx>]

Thanks a lot. I'll look into it.

Yu

On Jan 29, 2008 2:17 PM, Dan Gibson <degibson@xxxxxxxx> wrote:

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!

_______________________________________________
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.