The funny thing: in fact, it will work, and for exactly the same reasons. The manual describes it thus: "The conflicting condition is a stride determined by the

The funny thing: in fact, it will work, and for exactly the same reasons. The manual describes it thus: "The conflicting condition is a stride determined by the size of the cache in bytes, divided by the number of ways." L1 caches for most modern CPUs work in this manner, and you see the same result. (Wikipedia has a description - http://en.wikipedia.org/wiki/CPU_cache http://en.wikipedia.org/wiki/CPU_cache - the type of cache commonly employed today being the N-way set associative type.) You can run the same calculations to get an equivalent value for each CPU. For example, you asked about HPPA: for a PA8700, this value would - I suppose... I just found the cache specification using Google :) - be 384KBytes, as its data cache is 1.5MBytes 4-way set associative. As a more general note: If you try to seriously solve performance problems, you'll quickly find, as I always have, that there's little basis in reality for the idea that they can be fixed late in the day with a few spot hacks. Indeed, that idea is usually the reason the problems have arisen in the first place. But that idea has to be the basis of any doctrine of adopting a just-in-time policy for performance problems! So if you're not a big fan of programming with performance in mind, then I do think you should be celebrating this kind of quick tweak, rather than decrying it. It's evidence for your position.