4 ms·

You are overgeneralizing. Being front-end bound is true for some code but not for others. We see our gotchas typically in terms of not being able to issue inst

You are overgeneralizing. Being front-end bound is true for some code but not for others. We see our gotchas typically in terms of not being able to issue instructions due to data dependencies and filling up the RS with things that can't make progress (informally, a big tree of "ORs" where one source for everything has missed L1 and held everyone else up). Other people will be hopelessly bound on cache or memory bandwidth, or floating point multiply, or whatever. Or disk access :-) If one is curious about whether this applies to one's own code, you don't have to speculate - just bust out the Optimization Guide (http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html http://www.intel.com/content/www/us/en/architecture-and-tech...) and go figure out where your bottlenecks are by looking at counters. VTune can do some of this stuff for you.

rayiner 13y ago
I'm speaking from an architectural design standpoint. Exceeding the ability of the OOO engine to cover cache misses isn't a "gotcha" it's a design limit of the hardware. Being able to only predict three branches in a 16-byte fetch group, even though more than 3 branches can fit in a 16-byte stretch of code, is a gotcha. Being able to execute only 3 SSE operations per cycle is a design limit. Not being able to hit 3 SSE operations per cycle depending on which registers you use and how many prefix bytes they require to encode is a gotcha.