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

["Min Xu (Hsu)" <xu@xxxxxxxxxxx>]

correct me if I am wrong, when opal is used, simics does
not get stalled by opal (and ruby is not installed as a
timing interface in simics). Each simics instruction
takes one simics cycle.

On Wed, 29 Mar 2006 Dan Gibson wrote :
> 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
> >   
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users