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? ;-)
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.
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.
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.
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.
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?
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.
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.
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.
RE: Not if the hardware
)
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? ;-)
Join the #1 Aussie Alliance on Einstein
RE: This is not true for
)
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.
RE: RE: This is not true
)
[Edit] Origional post edited.
Einstein sure doesn't seem slower under XP64. It's not much.
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.
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.
One thing that comes to mind
)
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?
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.
RE: (Have you ever tried to
)
Hence why I use OpenOffice 2.0 :)
RE: RE: This is not true
)
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.
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.