Disappointed

Talk about anything related to Legend of Grimrock 2 here.
User avatar
Dr.Disaster
Posts: 2855
Joined: Wed Aug 15, 2012 11:48 am

Re: Disappointed

Post by Dr.Disaster » Wed Apr 22, 2015 6:07 pm

badhabit wrote:
Dr.Disaster wrote:
Isaac wrote:Isn't 64 bit slower?
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.

here some benchmarks http://www.osnews.com/story/5768/Are_64 ... es_/page3/
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.

badhabit
Posts: 467
Joined: Sat May 05, 2012 2:24 pm

Re: Disappointed

Post by badhabit » Wed Apr 22, 2015 6:43 pm

Dr.Disaster wrote:
badhabit wrote:
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.

here some benchmarks http://www.osnews.com/story/5768/Are_64 ... es_/page3/
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.

User avatar
Dr.Disaster
Posts: 2855
Joined: Wed Aug 15, 2012 11:48 am

Re: Disappointed

Post by Dr.Disaster » Wed Apr 22, 2015 6:47 pm

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.

badhabit
Posts: 467
Joined: Sat May 05, 2012 2:24 pm

Re: Disappointed

Post by badhabit » Wed Apr 22, 2015 6:55 pm

Dr.Disaster wrote:
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.

User avatar
Dr.Disaster
Posts: 2855
Joined: Wed Aug 15, 2012 11:48 am

Re: Disappointed

Post by Dr.Disaster » Wed Apr 22, 2015 7:21 pm

badhabit wrote:
Dr.Disaster wrote:
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.

badhabit
Posts: 467
Joined: Sat May 05, 2012 2:24 pm

Re: Disappointed

Post by badhabit » Wed Apr 22, 2015 8:09 pm

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.

User avatar
Dr.Disaster
Posts: 2855
Joined: Wed Aug 15, 2012 11:48 am

Re: Disappointed

Post by Dr.Disaster » Wed Apr 22, 2015 11:28 pm

Thx for confirming that I talked about the CPU and you about something else.

badhabit
Posts: 467
Joined: Sat May 05, 2012 2:24 pm

Re: Disappointed

Post by badhabit » Thu Apr 23, 2015 11:10 am

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.

User avatar
Dr.Disaster
Posts: 2855
Joined: Wed Aug 15, 2012 11:48 am

Re: Disappointed

Post by Dr.Disaster » Thu Apr 23, 2015 12:32 pm

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.

minmay
Posts: 2700
Joined: Mon Sep 23, 2013 2:24 am

Re: Disappointed

Post by minmay » Fri Apr 24, 2015 1:41 am

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
Grimrock 1 dungeon
Grimrock 2 resources
I no longer answer scripting questions in private messages. Please ask in a forum topic or this Discord server.

Post Reply