Pranith
Pranith
> > Hmm, OK, I highly doubt this is the case in modern BTBs though because of all of the security considerations post Spectre/Meltdown. That said, I think we need...
> > I still think this change is very problematic. It's going to be hard for users to understand how to set this parameter correctly and it won't be a...
Hi, just wanted to know if there is any other review feedback for this change?
> I tend to agree with @andysan here. Overall, by using 64 we would still be backwards compatible; however, for the very common case of tag extraction we now have...
Thank you @andysan for your review and comments. > My take on this particular change is that it is going to become problematic and will need to be dropped once...
> My problem with this change is that it introduces a public API (a param) that we know will need to be removed within the next 1-2 releases because we...
> The problem is that this change is extremely short-sighted. We know that we will need to use structs to represent tags in the future to support important use cases...
@giactra I tried using the templatized version of the cache library as an exercise. Can you please review this change? Thank you!
@giactra Thanks for the review! I tried inheriting from the base classes (instead of CacheEntry and IndexingPolicy) but it seems like we need to copy most of what these classes...
> Thanks @pranith for this change! As this is a purely refactoring change, could you run some workload with O3 and see if there are any stats difference between pre...