Re: [Gems-users] Relation between SIMICS cycle & GEMS cycle

[Dan Gibson <degibson@xxxxxxxx>]

Simics cycles also count the time that a given processor is stalled 
waiting on a memory request. An L2 miss usually constitutes a few 
hundred simics cycles, though the exact number changes greatly depending 
on configuration, and whether or not Opal is used in conjunction with Ruby.
Min Xu (Hsu) wrote:
> Simics cycle number includes both dynamic
> instructions and exceptions/interrupts.
>
> When running with opal, each dynamic instruction
> increment simics cycle number by 1, but the
> same instruction may have much longer latency
> in terms of the "GEMS cycle". The reason that
> simics cycle is larger than the number of dynamic
> instructions in your experiment is that simics
> cycle number also counts the exceptions and
> interrupts. I am curious what workload you are
> using, because the number of exceptions and
> interrupts seems high.
>
> We are aware that because simics cycle
> number don't really reflect the instruction
> latency, interrupts are perhaps delivered
> more frequent than it needs to be.
>
> On Wed, 29 Mar 2006 Weihang Jiang wrote :
>   
> > I used both.
> >
> > On 3/29/06, Min Xu (Hsu) <xu@xxxxxxxxxxx> wrote:
> >     
> > > Did you use Opal or just Ruby only? It matters.
> > >
> > > On Wed, 29 Mar 2006 Weihang Jiang wrote :
> > >       
> > > > Hi,
> > > >   Can anybody help me understand the relation between SIMICS
> > > > cycle and GEMS cycle.
> > > >
> > > >   SIMICS cycle means the number of cycles SIMICS thinks the
> > > > simulation has lasted, which can be calculated through
> > > > calling SIM_cycle_count() at the beginning and the end of
> > > > one simulation.
> > > >   GEMS cycle is referring to the number of cycles opal/ruby
> > > > has advanced.
> > > >
> > > >   Understanding the relation between SIMICS cycle and GEMS
> > > > cycle is important for utilizing system level profiling
> > > > tools. For example, vmstat reports both number of events
> > > > (e.g. bi, bo) and relative execution time (e.g. us,sy,id).
> > > > Other profiling tools report absolute execution time.
> > > >
> > > >   I did a small experiment to testify the relation. I ran
> > > > SIMICS+GEMS with two different cache configurations for
> > > > 10,000,000 GEMS cycles.
> > > >   In experiment 1, using fast cache, 407,808 instructions
> > > > have been executed and the SIMICS cycle number is 1,711,569.
> > > > In experiment 2, using slow cache, 401,245 have been
> > > > executed. However, the SIMICS cycle number is 1,664,671
> > > > (different from exp1).
> > > >
> > > >    Based on this experiment, my understanding is that,
> > > > SIMICS cycle is not an accurate measurement and those system
> > > > level profiling tools can not be used without care.
> > > >
> > > >    So, I have 2 questions:
> > > >
> > > > 1. Is my understanding correct?
> > > > 2. How much effort does it require to let SIMICS cycle have
> > > > more sense(i.e. let SIMICS cycle == GEMS cycle)?
> > > >
> > > >
> > > > --
> > > > Weihang Jiang,  UIUC
> > > >
> > > > _______________________________________________
> > > > Gems-users mailing list
> > > > Gems-users@xxxxxxxxxxx
> > > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > >         
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx
> > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > >
> > >       
> > --
> > Weihang Jiang
> >
> >     
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>