64 bit application, is it needed?

m.mitch
m.mitch
Joined: 11 Feb 05
Posts: 187
Credit: 11,025,628
RAC: 0

RE: Not if the hardware

Message 25184 in response to message 25182

Quote:

Not if the hardware doesn't comply. The 64bit OS of Microsoft already adresses
lots of snipping

Goodness gracious me Ageless I know you know better than that! I wasn't talking about hardware! Ahg. I was taking about Bill Gates saying that 640K is more than enough memory to run Windows.
Then just ten years latter and Microsoft's products need a Gig each!
Hell, MS Windows XP SP2 requires more install space than most mainframes and uses more memory to run.
Well, almost ;-)
But, give BG & MS another ten years, and two Terabytes will come in a pack of two matched sticks of RAM. Then people like ourselves will have four sticks installed to stop bloody Windows 2015 from freezing up!
Gee, I think I just talked myself into running more Linux boxes.
(Have you ever tried to spell check Linux, in MS Word? ;-)

AMD-USR_JL
AMD-USR_JL
Joined: 24 Jan 06
Posts: 13
Credit: 27,886
RAC: 0

RE: This is not true for

Message 25185 in response to message 25183

Quote:
This is not true for the x86_64 architecture. No emulation is needed, a 32 bit application runs as fast as one compiled for 64 bit.

No, seriously there is a program called WOW64, which means windows 32 on windows 64. Windows uses this program to run a 32-bit application in a 64-bit OS. It installs programs in different dircetories depending on wether or not they are 64 bit.

"It does this by intercepting calls to APIs like GetSystemDirectory and returning the appropriate directory depending on whether the application is running under the WOW or not."

If you do not believe me you can read my source's (microsoft) page. Scroll down about a 1/4 of the page and you will see WOW64.

On another page I found this:
"Processor hardware (instruction emulation is performed on the chip). On the x64 processor, instructions are executed natively by the micro-architecture. Therefore, execution speed under WOW64 on x64 is similar (not exactly the same) to its speed under 32-bit Windows. On the Intel Itanium processor, more software is involved in the emulation, and performance suffers as a result."
So now I hope you understand what I am trying to say about einstein slowing down.

The Pirate
The Pirate
Joined: 11 Nov 04
Posts: 57
Credit: 23,332,769
RAC: 0

RE: RE: This is not true

Message 25186 in response to message 25185

Quote:
Quote:
This is not true for the x86_64 architecture. No emulation is needed, a 32 bit application runs as fast as one compiled for 64 bit.

No, seriously there is a program called WOW64, which means windows 32 on windows 64. Windows uses this program to run a 32-bit application in a 64-bit OS. It installs programs in different dircetories depending on wether or not they are 64 bit.

"It does this by intercepting calls to APIs like GetSystemDirectory and returning the appropriate directory depending on whether the application is running under the WOW or not."

If you do not believe me you can read my source's (microsoft) page. Scroll down about a 1/4 of the page and you will see WOW64.

On another page I found this:
"Processor hardware (instruction emulation is performed on the chip). On the x64 processor, instructions are executed natively by the micro-architecture. Therefore, execution speed under WOW64 on x64 is similar (not exactly the same) to its speed under 32-bit Windows. On the Intel Itanium processor, more software is involved in the emulation, and performance suffers as a result."
So now I hope you understand what I am trying to say about einstein slowing down.

[Edit] Origional post edited.
Einstein sure doesn't seem slower under XP64. It's not much.


DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 133

IF amd64's are only seeing

IF amd64's are only seeing systemcall emulation the effect should be negligable since it's only affecting gui and disk activities. The former might be an issue with the screensaver, but I assume (never used it) that it's got a low cpu burden to begin with. A write/minute for diskIO's essentially zero.

Biogenesis
Biogenesis
Joined: 11 Nov 04
Posts: 24
Credit: 140,834
RAC: 0

There is one factor that

There is one factor that seems to have slipped everyone's comments: The x86_64 architecture has double the CPU registers of 32b x86 CPU's. Now I've very little idea of how much memory i/o E@H does so can't comment on the theoretical performance differences an application compiled for 64b would see, but I think people should at least mention it.

NeoGen
NeoGen
Joined: 9 Feb 05
Posts: 1
Credit: 7,239,207
RAC: 0

One thing that comes to mind

Message 25189 in response to message 25188

One thing that comes to mind in support of a 64 bit app would be that it could be optimized by compiling with SSE2. If I'm not wrong the oldest athlon64 already supported SSE2. I guess the normal 32bit apps cannot take advantage of the optimizations because older processors may not support it. (Like my own Athlon XP unfortunately...)

Wouldn't the SSE2 instructions give a good performance boost to the app too? Maybe even more than just flipping the 32/64 bit switch?

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 133

Maybe. Team members have

Maybe. Team members have tried hand optimizing x86 assembly but gotten negligable gains over what the compiler output. About a week ago someone posted that (presumably after reverse engineering the algorithm) he was able to double the performance without affecting the results. He's shared his work with the E@H devs, but nothing's been said offficially about it yet.

Jord
Joined: 26 Jan 05
Posts: 2,952
Credit: 5,779,100
RAC: 0

RE: (Have you ever tried to

Message 25191 in response to message 25184

Quote:
(Have you ever tried to spell check Linux, in MS Word? ;-)


Hence why I use OpenOffice 2.0 :)

Wurgl (speak^Wcrunching for Special: Off-Topic)
Wurgl (speak^Wc...
Joined: 11 Feb 05
Posts: 321
Credit: 140,550,008
RAC: 0

RE: RE: This is not true

Message 25192 in response to message 25185

Quote:
Quote:
This is not true for the x86_64 architecture. No emulation is needed, a 32 bit application runs as fast as one compiled for 64 bit.

No, seriously there is a program called WOW64, which means windows 32 on windows 64. Windows uses this program to run a 32-bit application in a 64-bit OS. It installs programs in different dircetories depending on wether or not they are 64 bit.

"It does this by intercepting calls to APIs like GetSystemDirectory and returning the appropriate directory depending on whether the application is running under the WOW or not."

If you do not believe me you can read my source's (microsoft) page. Scroll down about a 1/4 of the page and you will see WOW64.

On another page I found this:
"Processor hardware (instruction emulation is performed on the chip). On the x64 processor, instructions are executed natively by the micro-architecture. Therefore, execution speed under WOW64 on x64 is similar (not exactly the same) to its speed under 32-bit Windows. On the Intel Itanium processor, more software is involved in the emulation, and performance suffers as a result."
So now I hope you understand what I am trying to say about einstein slowing down.

You mix up a few things. First of all you mix up the instruction set with some very operating system specific interface. An interface between whatever system parts and the application.

There might be a small slowdown when a 32 bit application changes its focus from 32-bit User space to 64 bit OS space. Okay. But how often is a system call done in some application? Maybe this is a slowdown by less than 1%.

And then you mention that Titanium chip. Forget it, we are talking about x86 / x86_64.

For myself, look here http://einsteinathome.org/node/189692
a 64 bit 2.6 kernel with gentoo linux was close to 10% faster that a 32 bit 2.4 kernel with SLES2. No idea and even no interest (sorry) if this applies to microsft or not. For Linux I got an increase of speed.

Jesse Viviano
Jesse Viviano
Joined: 8 Jun 05
Posts: 33
Credit: 133,045,917
RAC: 0

Compiling to an AMD64

Compiling to an AMD64 platform will result in a speedup of floating point code for a not-so-obvious reason. AMD made the SSE2 unit able to double up as a regular floating point that uses a register file instead of that trashy legacy x87 FPU that uses a stack. The x87 stack was why other CPU architectures were able to beat out x86 chips consistently. This stack forced the two operands to be on its top for anything to use it. If the numbers were anywhere else in the stack, you had to issue exchange instructions to move the operands to the top. This wastes CPU time. Simple compilers and beginning assembly programmers could just ignore the legacy FPU and use the SSE2 unit like a standard FPU that can fetch the operands anywhere in the FPU register file. More complicated compilers could use both FPUs in tandem. Better compilers will vectorize the code to take advantage of the SSE2 instructions. The best compilers will vectorize the code for SSE2 while using the x87 FPU at the same time. There is nothing 64 bit about this improvement. AMD just modernized the x86 FPU architecture when defining AMD64. The modernization of floating point math was thankfully copied when Intel copied AMD64 and renamed it EM64T.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.