As long as the CPU uses at least 64 bit in every area (registers, op-code, busses) and therefore does not has to resort to 32 bit operations to emulate 64 bit operation it can't be slower.
Infact, if you take the same CPU with the same ISA and architecture (register number) & die size for 32 & 64bit, the 64bit version will be normally (slightly) slower, due to increased instruction cache pressure due to double sized pointers.
This "test" shows only one thing: code ment for 32 bit systems compiled into 32 and 64 bit binaries behaves different. In addition using something as heavyly disk-I/O-influenced as SQL paired with rather I/O-weak ATA drives .. *shiver*
It also does not support your statement about 32 and 64 versions of the same CPU: there are no 32 bit UltraSPARC CPU's in existence.
Dr.Disaster wrote:
As long as the CPU uses at least 64 bit in every area (registers, op-code, busses) and therefore does not has to resort to 32 bit operations to emulate 64 bit operation it can't be slower.
Infact, if you take the same CPU with the same ISA and architecture (register number) & die size for 32 & 64bit, the 64bit version will be normally (slightly) slower, due to increased instruction cache pressure due to double sized pointers.
This "test" shows only one thing: code ment for 32 bit systems compiled into 32 and 64 bit binaries behaves different. In addition using something as heavyly disk-I/O-influenced as SQL paired with rather I/O-weak ATA drives .. *shiver*
It also does not support your statement about 32 and 64 versions of the same CPU: there are no 32 bit UltraSPARC CPU's in existence.
Well, this was not the point, my point was if you have an CPU of same ISA, architecture & size, 64bit code will be necesserily slower due to increased cache pressure.
Only if you utilize wider datatypes (int64 etc) or the wider virtual address space in a clever way (like this 64bit Virtual-Memory Counting Sort) you can get serious speed-up. Plain recompilation will lead only to marginal differences & often even reduced performance.
Last edited by badhabit on Wed Apr 22, 2015 6:58 pm, edited 1 time in total.
badhabit wrote:Plain recompilation will lead only to marginal differences & often even reduced performance.
.. which is exactly what happened in that "benchmark" you linked to.
Yes, which is the opposite of your statement: "it can't be slower ". Infact, it will be slower (indicated also be the linked benchmark) due to increased cache pressure. For specific software (software with many branches and cache dependency) MUCH slower.
badhabit wrote:Plain recompilation will lead only to marginal differences & often even reduced performance.
.. which is exactly what happened in that "benchmark" you linked to.
Yes, which is the opposite of your statement: "it can't be slower ". Infact, it will be slower (indicated also be the linked benchmark) due to increased cache pressure. For specific software (software with many branches and cache dependency) MUCH slower.
Please, don't rip my statements out of context. I refered to Issac's description of 64 bit adressing in a 32 bit system, not plain recompiled software.
Dr.Disaster wrote:
Please, don't rip my statements out of context. I refered to Issac's description of 64 bit adressing in a 32 bit system, not plain recompiled software.
Sorry, seems I got you wrong here.
edit: hmm, after re-reading "As long as the CPU uses at least 64 bit in every area (registers, op-code, busses) and therefore does not has to resort to 32 bit operations to emulate 64 bit operation it can't be slower." no, I didn't got you wrong. You stated that 64bit can be slower only in case of legacy emulation etc and not in full 64bit mode (you meant not only 64 bit RAM adressing). Which is not correct in this generality, the cache pressure reduces the performance even in full native 64bit mode vs a 32bit mode.
Dr.Disaster wrote:Thx for confirming that I talked about the CPU and you about something else.
Yeah, thanks for being as stubborn as ever... could you not just accept that your formulation was misleading and/or to generalizing? "As long as the CPU uses at least 64 bit in every area (registers, op-code, busses) and therefore does not has to resort to 32 bit operations to emulate 64 bit operation it can't be slower."
You liked to took a very patronizing tone against Isaac ("you don't understand 64bit, it can't be slower")... therefore your statement deserved a sharper look. And in this form it is not true in general. Please, take as feedback if you do very general statements ("it can't be slower"), be extra sure that is really true in all the cases your statement occupies. Or better don't do such wide generalization statements.
Why do you keep trying to mix completely different topics like "die size" or "cache pressure" into a general 32/64 bit talk that Issac, minmay and me have? If you want to prove my statement wrong that 64 bit operations in a CPU designed for 64 bit are slower than 32 bit operations come up with something like cpu cycles needed per op-code and not some flawed benchmark done by simply re-compiling 32 bit code into 64 bit binaries.
Dr.Disaster wrote:Why do you keep trying to mix completely different topics like "die size" or "cache pressure" into a general 32/64 bit talk that Issac, minmay and me have? If you want to prove my statement wrong that 64 bit operations in a CPU designed for 64 bit are slower than 32 bit operations come up with something like cpu cycles needed per op-code and not some flawed benchmark done by simply re-compiling 32 bit code into 64 bit binaries.
A small die size and effective cache are essential to the practicality and effective speed of modern CPUs and it makes no sense to disregard them
is there a single hill you aren't willing to die on
