Re: [Gems-users] How to identify cache hit rate in Ruby?

[Mike Marty <mikem@xxxxxxxxxxx>]

Are numOfHits and numOfMisses instantiated for each Sequencer, or are 
they global?
The transition counts are global counts

--Mike


Dave Z. wrote:
> If I put the following code in Sequencer::makeRequest,
> and set REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH to true,
> then I should get the same number of hits/misses in
> both the Sequencer stats and cache controllers, right?
>
>     if ((request.getType() == CacheRequestType_LD) ||
> 	(request.getType() == CacheRequestType_ST) ||
> 	(request.getType() == CacheRequestType_IFETCH)) {
>       if (hit) numOfHits++;
>       else numOfMisses++;
>     }
>
> But it doesn't give me the same numbers. Is there any
> other parameter that I need to reconsider?
>
> Thanks,
>
> Dave
>
>
>  
> --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
>   
> > With REMOVE_DCACHE_FAST_PATH (or whatever the name
> > is) is set to 
> > "false", the Ruby sequencer directly accesses the L1
> > cache objects to 
> > determine a hit.  If there is an L1 hit, then the L1
> > cache controller is 
> > not invoked and you will not see "Load, Ifetch, and
> > Store" events.  If 
> > you want to  see these events in the controllers,
> > then set the above 
> > flag to "true". 
> >
> > --Mike
> >
> >
> >
> > Lei Yang wrote:
> >     
> > > But wait, when I compare the sum of L1D and L1I
> > >       
> > misses,  and the sum
> >     
> > > of L1 Load, Ifetch, and Store, they are exactly
> > >       
> > the same, does this
> >     
> > > mean that all L1 access are misses?
> > >
> > > Lei
> > >
> > > On 11/1/07, Lei Yang <lei.d.yang@xxxxxxxxx> wrote:
> > >   
> > >       
> > > > Thanks Mike!
> > > >
> > > > In addition to the simics driver transaction
> > > >         
> > results stats, could we
> >     
> > > > also look at the chip stats? (Right below the
> > > >         
> > transaction results
> >     
> > > > stats, which I didn't notice before).
> > > >
> > > > Chip Stats
> > > > ----------
> > > >
> > > >  --- L1Cache ---
> > > >  - Event Counts -
> > > > Load  4775
> > > > Ifetch  10102
> > > > Store  25032
> > > >
> > > > This way, we'll know both L1 and L2 miss rates.
> > > >
> > > > Maybe we should consider include the results of
> > > >         
> > miss/hit rates in the
> >     
> > > > L1/L2 stats in the next release.
> > > >
> > > > Lei
> > > > On 11/1/07, Mike Marty <mikem@xxxxxxxxxxx> wrote:
> > > >     
> > > >         
> > > > > misses_per_transaction simply divides the total
> > > > >           
> > misses by the total
> >     
> > > > > number of transactions.  This is not
> > > > >           
> > transactions in Transactional
> >     
> > > > > Memory.  This is workload transactions (i.e., a
> > > > >           
> > transaction in the
> >     
> > > > > Apache web server workload).
> > > > >
> > > > > You have the L1D and L1I misses.  To get the
> > > > >           
> > total accesses (assuming
> >     
> > > > > REMOVE_FAST_PATH... is set to false), look for
> > > > >           
> > the following:
> >     
> > > > > Simics Driver Transaction Results Stats
> > > > > ------------------------------------------
> > > > > Fast path: 114008467
> > > > > Request missed: 3926280
> > > > >
> > > > > The "Request missed" should equal the L1D and
> > > > >           
> > L1I misses.  The "Fast
> >     
> > > > > path" indicates how many requests were made to
> > > > >           
> > the Ruby sequencer, but
> >     
> > > > > hit in the L1 caches.
> > > > >
> > > > > --Mike
> > > > >
> > > > >
> > > > >
> > > > > Lei Yang wrote:
> > > > >       
> > > > >           
> > > > > > Dear list,
> > > > > >
> > > > > > I'm wondering whether Ruby provides such
> > > > > >             
> > statistics like cache
> >     
> > > > > > hit/miss rate? For example, in the following
> > > > > >             
> > stats report from Ruby:
> >     
> > > > > > L1D_cache cache stats:
> > > > > >   L1D_cache_total_misses: 29807
> > > > > >   L1D_cache_total_demand_misses: 29807
> > > > > >   L1D_cache_total_prefetches: 0
> > > > > >   L1D_cache_total_sw_prefetches: 0
> > > > > >   L1D_cache_total_hw_prefetches: 0
> > > > > >   L1D_cache_misses_per_transaction: 29807
> > > > > >   L1D_cache_misses_per_instruction: 0.000143247
> > > > > >   L1D_cache_instructions_per_misses: 6980.94
> > > > > >
> > > > > >   L1D_cache_request_type_LD:   16.0197%
> > > > > >   L1D_cache_request_type_ST:   82.7557%
> > > > > >   L1D_cache_request_type_ATOMIC:   1.22454%
> > > > > >
> > > > > >   L1D_cache_access_mode_type_SupervisorMode:  
> > > > > >             
> > 6933    23.2596%
> >     
> > > > > >   L1D_cache_access_mode_type_UserMode:   22874 
> > > > > >             
> >   76.7404%
> >     
> > > > > >   L1D_cache_request_size: [binsize: log2 max:
> > > > > >             
> > 64 count: 29807 average:
> >     
> > > > > > 4.90469 | standard deviation: 4.44371 | 0 642
> > > > > >             
> > 88 23854 5077 0 0 146 ]
> >     
> > > > > > We know the total L1D cache misses, and the
> > > > > >             
> > misses_per_instruction.
> >     
> > > > > > But do we know the total number of cache
> > > > > >             
> > acesses, and thus the
> >     
> > > > > > hit/miss rate? Also, what does
> > > > > >             
> > misses_per_transaction mean?
> >     
> > > > > > Thank you in advance!
> > > > > > Lei
> > > > > > _______________________________________________
> > > > > > 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.
> >     
> > > > > >         
> > > > > >             
> > > > > _______________________________________________
> > > > > 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.
> >     
> > > > >       
> > > > >           
> > > _______________________________________________
> > > 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.
> >     
> > >   
> > >       
> > _______________________________________________
> > 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.
> >
> >
> >     
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> 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.
>