There is more to making fast code than timing small code sections with rdtsc.

For any non-trivial program: The largest contributor to performance will almost certainly be memory access patterns, and cache usage. Your code might be different, but without testing how will you know?

It is kind of useless to have many super-fast tiny blocks of code, and then connect them together in a full program and discover that your cache gets filled and the whole thing thrashes, killing performance.

Test your whole code, the final app, as a whole, with everything working and running on normal data.

Uses for rdtsc should be limited to identifying hotspots to direct the optimisation efforts where the time spent is most productive. But also remember that rdtsc itself induces penalties possibly changing results that otherwise could be quite different.

revolution, you have a habit of giving this same generic canned-like response every time the topic of code timing comes up. Memory, cache, data access, optimize the high level algorithm, ..., small code may be better than huge code that trashes the code cache, ..., micro benchmarks are useless, test your whole program, ..., etc . I have heard all of this multiple times before and am well aware of where the hotspots are and how to find them. Sometimes the bottlenecks really do fall under the rubric of in-register throughput computation.
Now, I was simply musing (and revolution is not the intended audience) that at some point intel's nominal add/mul latency ratio went from 3/5 to 4/4, i.e. that addition became relatively "slower". Since Anger Fog goes through the trouble of assigning values here and intel even posts numbers on its intrinsics guide, they must be worth something.
And, before revolution jumps back in tells me that I will know nothing untill I time my whole app, I would just like to mention that the only real success I've had applying these latency numbers is in the case of these trivial micro loops. ha.

I'm glad the message is starting to get through.

I hate to see people waste time on the wrong and give up on assembly out of frustration when their code is no faster than a good C compiler.

I was born a C compiler then I had a growth spurt around Pascal. Because most code is compiled and the aggregate result was an increase in performance. This is why these new instructions will work - because they are compiler puzzle pieces, and can be made faster than existing instructions. So, rather than find ways to combine existing instructions (which compilers struggle to navigate correctly), Intel invests silicon in better tools for the compiler.

If no bottlenecks exist in fetch/decode/retire then instruction binning into execution ports drives throughput. (Assuming no dependencies.)