Re: [Gems-users] Why should Opal issue speculative store to ruby?

[Dan Gibson <degibson@xxxxxxxx>]

Since Ruby doesn't actually store values, you can think of the "issue" of the store as a permission prefetch. Ruby only tracks cache line metastate anyway (it doesn't need to track actual values in the cache). The store remains resident in the LSQ until commit-time. It is true that "issuing" the store changes the Ruby statistics-- but store prefetching isn't really pollution, merely a possible optimization from an out-of-order core, and it is consistent to use store prefetching, provided that the actual store value doesn't appear to other processors before commit-time.

郭锐 wrote:

Hi,

         After reading the source code of Opal, I come to the point that it doesn’t pay any attention to store instructions in mis-predicted branch. It may have issued load/stores to Ruby when the pipeline has been flashed.

Yes, I understand that Opal was designed to be a very aggressive optimistic OOO processor. I find it ok to even issue stores out of order, and so is to issue loads speculatively. But it’s unacceptable to me if the stores are speculatively issued to Ruby, which will pollute the statistics of Ruby and be impractical to real-world systems.

Can anybody prove me wrong or explain why it was designed like this?

 

G.R.

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