Live data from Hacker News

Replacing 32-bit loop variable with 64-bit introduces performance deviations

stackoverflow.com

21–26 of 26 posts

Re: Replacing 32-bit loop variable with 64-bit introduces performance deviations

#21
post #20
post #19

Earlier quoted context omitted.

'icpc' (the Intel C++ compiler) has equal performance for both of the test cases, and it did choose to use different registers for each call. But it's not clear if that's by design or by chance. In some ways, that's the boring part. The interesting part (to me) is that both tests are much faster than either version with g++. Here's icpc 14.0.3 vs g++ 4.8.1 on a Sandy Bridge E5-1620 @ 3.60GHz and a Haswell i7-4770 CPU…

OK, it looks like 'icpc' has decided that it would be fastest to invert the two loops: popcnt() once, then repeat the addition 10000 times. I'm neither a language lawyer nor a friend of C++, so I'll refrain to trying to decide whether this is a legal optimization. But a liberal sprinkling of 'volatile' makes it do what was obviously intended. After this, the speeds are more comparable, although 'icpc' retains a small…

It's definitely legal, the buffer is created with operator new and is not made visible to any other code, so the compiler knows that it can't change within the loop.

Re: Replacing 32-bit loop variable with 64-bit introduces performance deviations

#23
post #20
post #19

Earlier quoted context omitted.

'icpc' (the Intel C++ compiler) has equal performance for both of the test cases, and it did choose to use different registers for each call. But it's not clear if that's by design or by chance. In some ways, that's the boring part. The interesting part (to me) is that both tests are much faster than either version with g++. Here's icpc 14.0.3 vs g++ 4.8.1 on a Sandy Bridge E5-1620 @ 3.60GHz and a Haswell i7-4770 CPU…

OK, it looks like 'icpc' has decided that it would be fastest to invert the two loops: popcnt() once, then repeat the addition 10000 times. I'm neither a language lawyer nor a friend of C++, so I'll refrain to trying to decide whether this is a legal optimization. But a liberal sprinkling of 'volatile' makes it do what was obviously intended. After this, the speeds are more comparable, although 'icpc' retains a small…

That's the problem with microbenchmarks, ensuring they're measuring what you think they're measuring.

Re: Replacing 32-bit loop variable with 64-bit introduces performance deviations

#24
post #18

It should be noted that using 64-bit operands, even in 64-bit mode, incurs an extra penalty of 1 byte per instruction, for the REX prefix. The same applies to using the extended registers (the uncreatively-named "r8" through "r15".) This is very much not noticeable for microbenchmarks, where all the code of a loop fits in the cache, but for bigger ones, the effects of icache misses can become quite significant. A sma…

> incurs an extra penalty of 1 byte per instruction, for the REX prefix. Any hope to see a Thumb mode for x86-64?

[deleted]

Re: Replacing 32-bit loop variable with 64-bit introduces performance deviations

#25
post #4

To elaborate on the justification for the answer: So Intel probably shoved popcnt into the same category to keep the processor design simple In the processor design I work on, we do register dependency checks by partitioning all instructions into a set of "timing classes" and checking the dispatch delay needed between dependent register producers and consumers across all possible timing class pairs. The delays vary d…

All X86 ops are translated into very simple (RISCy) micro-ops before being scheduled, so the problem probably lies in that part of the processor.

Even if the problem isn't there, it's really easy to fix in that layer: just insert an instruction before popcnt that kills the value in the destination register, and there won't be anything to wait for. Intel does regular microcode updates to fix this sort of thing, so I would anticipate seeing this one get fixed in the not-too-distant future.

Re: Replacing 32-bit loop variable with 64-bit introduces performance deviations

#26

Earlier quoted context omitted.

I suspect that aside was written tongue-in-cheek.

I'm sure, but in case anyone at a CPU design company gets any bright ideas and decides to start naming everything... ;-)

cough MIPS cough
Post reply on HN