------- Additional Comments From law at redhat dot com 2005-04-06 00:25 ------- Just more notes on the huge perl speedup with the threading changes...
For reasons yet unknown, we're seeing a lot less L2 cache traffic when perl is compiled with the threading changes. The decreased L2 traffic also corresponds to the areas of code which I had previously identified as showing the most significant runtime improvements. What I don't have an answer for yet is _why_ we're seeing the huge decrease in L2 traffic. We're seeing a huge jump in MEMORY_CANCEL events, which if I understand the docs correctly will cause an increase in cache activity as we are either low on store buffers or we have conflicts due to 64k aliasing. [Both sub-events are way-down with the threading changes. ] Attempts to perturb the size of the stack for the recursive routine in question to avoid the 64k aliasing problem haven't met with any success yet. We are seeing variables spilled into different stack locations, so that _could_ be the ultimate cause of the cache behavior. These things would definitely classify as secondary order effects We're also seeing a measurable decrease in ITLB misses, howerver, I'm not convinced that the decrease is significant enough to cause the kind of performance improvement we're seeing. Anyway, I'm still plugging away... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
