4 ms·
The decoder might not be running strictly all the time, but I would wager that for some applications at least it doesn't make much of a difference. For HPC or D
by mhh__ 6y ago
The decoder might not be running strictly all the time, but I would wager that for some applications at least it doesn't make much of a difference. For HPC or DSP or whatever where you spend a lot of time in relatively dense loops the uop cache is probably big enough to ease the strain on the decoder, but for sparser code (Compilers come to mind, lots of function calls and memory bound work) I wouldn't be surprised if it didn't make as much difference.
I have vTune installed so I guess I could investigate this if I dig out the right PMCs
- pbsd 6y agoI agree; compiler-type code will miss the cache most of the time. A simple test with clang++ compiling some nontrivial piece of C++: 0 lsd_uops 1,092,318,746 idq_dsb_uops ( +- 0.49% ) 4,045,959,682 idq_mite_uops ( +- 0.06% ) The LSD is disabled in this chip (Skylake) due to errata, but we can see only 1/5th of the uops come from the uops cache. However, the more relevant experiment in terms of power is how many cycles is the cache active instead of the decoders: 0 lsd_cycles_active 378,993,057 idq_dsb_cycles ( +- 0.18% ) 1,616,999,501 idq_mite_cycles ( +- 0.07% ) The ratio is similar: the regular decoders are not active only around 1/5th of the time. In comparison, gzipping a 20M file looks a lot better: 0 lsd_cycles_active 2,900,847,992 idq_dsb_cycles ( +- 0.07% ) 407,705,985 idq_mite_cycles ( +- 0.33% )