Re: [Gems-users] R: Comparing "ruby cycles" when running ruby alone and opal+ruby

[Dan Gibson <degibson@xxxxxxxx>]

Alessandro,

It is probably the case that the miss *rates* will be similar, though in 
saying so I am making a very broad generalization. There is a large body 
of work that has studied the effect of out-of-order processing on 
caches--suffice to say the effect is significant.
Opal may issue *more* requests to the memory hierarchy due to 
misspeculation, which could affect the miss rate, and may also issue 
instruction fetches differently (IE in greater or lesser number or even 
to different addresses) than the Simics processor model does. I am not 
an Opal expert myself, but I would not be surprised if the rates as well 
as performance were mismatched.
Regards,
Dan Gibson

Alessandro Bardine wrote:
> Dan,
> very thank you for your replies.
> At this point I have another question:
> The performances of the L2 cache in the two enviroments (in terms of
> miss-rates) should be the same?
> I think yes because, apart of different timing scales, in both enviroments I
> should have (almost) the same requests to the L2.
>  
>   
> > Alessandro Bardine wrote:
> >
> >     
> > > Hi,
> > > I am trying to compare the ruby cycles value that I get
> > > when I run a benchmark in opal+ruby environment ( with DNUCA cache
> > > architecture) with the same value that I get when I only run ruby (with
> > >       
> > the
> >     
> > > same DNUCA cache) driven directly by Simics.
> > > My idea is to make a comparison for the "ruby cycles" values I get at
> > >       
> > some
> >     
> > > fixed number of executed instruction in both environments.
> > > To do this I step opal+ruby with the "sim-step" command and I collect the
> > > ruby cicle value at regular interval, while for ruby alone I collect info
> > >       
> > >from the file generated with the "periodical-stat-file".
> >     
> > > What I expected was to get similar results but what I am getting from the
> > > first simulations is quite different!!
> > >
> > >
> > >       
> > I would expect the value of ruby_cycles to vary greatly between
> > Ruby-only and Opal+Ruby configurations. When Opal is NOT loaded, the
> > processor model is that of an in-order, blocking machine. Opal simulates
> > an out-of-order machine, and thus should behave very differently from
> > (and probably perform better than) the Ruby-only configuration.
> >
> >     
> > > Are the values of "ruby-cycles" for the two environments (intended at the
> > > same number of total executed instruction) directly comparable?
> > >
> > >
> > >       
> > The two values will show the performance of an in-order core for
> > Ruby-only, and the performance of an out-of-order core for Opal+Ruby.
> > They both are a measure of "execution time".
> >
> >     
> > > For the "ruby alone" I get the number of executed instruction in the
> > >       
> > file
> >     
> > > generated with the "periodical-stat-file", what is hard to understand for
> > >       
> > me
> >     
> > > is how ruby is able to know this value assumed that it is being driven by
> > > Simics.
> > >
> > >
> > >
> > >       
> > Ruby is aware of the number of instructions executed through the Simics
> > API. That is, it is possible to simply ask Simics how many instructions
> > have been executed on a given processor. See the Simics documentation
> > (specifically, the Simics reference manual) for more information.
> >
> > Regards,
> > Dan Gibson
> >
> >     
> > > _______________________________________________
> > > 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
> >     
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>