What this means is that if I use _rdtsc() to measure how many clock cycles it takes to execute a function I am actually measuring how many ‘standardized’ clock cycles it takes to execute that function.
I can’t get it to thermally limit itself, even when pegging all four hyperthreaded cores. On the code that I care about I find that my Sandybridge CPU usually runs at it’s peak speed of about 3.0 GHz. That sentence just about makes my head explode. The actual peak CPU speed depends on the overall load of the CPU and GPU, which means that if you optimize your code really well then you might push the CPU so hard that it can’t overclock itself quite as much.
#A1278 2011 sandybridge full
I could feel ripped off that my 2.20 GHz CPU runs 1.1% slow, but it turns out that isn’t the full story.īy using CPU-Z or Intel’s overnamed “Intel(R) Turbo Boost Technology Monitor 2.0” I can see that when my CPU is idle it drops to very low speeds, and when it is under heavy load it actually spikes up to around 3.0 GHz (2.993 GHz according to CPU-Z, which is probably more trustworthy than Intel’s potentially biased CPU speed monitor). My Sandybridge CPU is rated at 2.20 GHz and the rdtsc instruction on it returns a rock-solid 2.195 GHz at all times. It was fascinating, in a pointless and geeky way, to see how the CPU clock speed changed as the load changed. It would record the current number of CPU clock ticks with _rdtsc() (the C/C++ intrinsic for the rdtsc instruction), then wait some period of time (measured with QueryPerformanceCounter()), and then see how many CPU ticks had elapsed during that period. Years ago I wrote a program that would dynamically measure the speed of my CPU.
0 kommentar(er)
