x86 vs. x64 CPU performance

Page 3 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Yah - You can fill your motherboard with DIMMS. But tell me: What's the use of stuffing your PC full of RAM that the OS can't address??


By and large, the people here are street level consumers. The versions of windows they are running are consumer level, and therefore very much do have the address limitation. We get several posts a week here from people with that exact issue: "...installed 4GB....only sees 3..." "...why won't Windows see my RAM..." blah blah blah... Often enough that some of us have saved the replys as a file so we don't have to type out the answer... again... and again... and again...


Now... The reason MSFT don't make PAE available on the desktop is because it requires drivers to at least be large address aware - There are thousands and thousands of devices out there with drivers which are not. And the instant one of their drivers attempts a DMA call to an address that was remapped elsewhere under PAE, the computer will crash. This is a VERY common shortcut, and therefore enabling PAE to be used for expanding the address space would cause the computers with these devices installed to constantly crash on systems that *used* to be perfectly stable.

Why would Microsoft do that?? So a few gamers/enthusiasts can play with more RAM?? At a period in time where MSFT also have perfectly good consumer based 64 bit OS's??

If you're an IT professional, then you know what's required and are trained to handle it. Therefore it's a viable option on the server side. But I'm Sorry - No Product/Project manager in his right mind would ever inflict that on the buying public.
 


Sadly, that conclusion is wrong, though. Not inherently, but unless the program doesn't need great precision there is no benefit in moving from 32 to 64 bit. In addition a 64 bit processor has less registers available while running 64 bit code. Intels Op Fusion might work less efficient too since it merges 2 32 bit operations.
The generalization, that 64 bit is faster than 32 bit, is wrong. It can be if properly used, but so can 32 bit.
 
Radnor,

A 32-bit application running on a 64-bit OS will not be faster and may be slower, though in most cases the difference will be very small and not noticable.

A 64-bit Application on a 64-bit OS may be faster or slower than a 32-bit app on a 32-bit OS. It depends on the work the application does as to whether it can take advantage of the 64-bit capabilities. In general, if it's slower, it will be minimally so. However, in some cases a 64-bit application can be significantly faster.

Today, Most Home User applications are 32-bit and will not see a benefeit of 64-bits. That being said, If I would likely get a 64-bit OS all else being equal so long as the software I was running was supported under that OS.
 




Op Fusion only works with 32bit binaries the feature is dormant in 64bit operation.

Word, Playa.
 


Then, you agree with me. Just one thing.

There are native x64 apps. Too bad it aint for windows mate. Linux is using x64 NATIVE code and compilers from a long time now.

Ill show you how it WILL be faster. Some time ago i was managing some web servers. From WEBhosting to GSPs. Just the typical webadmin glued to a putty SSH console. They added a Athlon 64+ 3000 box. Hey, for testing it was nice, because it was cutting edge. This was a good few years ago. I used shells, and i had already bash scripting ready to put up servers with a few commands (It is not pleaseant at all, if you need to do something in your Linux box WITHOUT the | key, my Nokia 8210i didnt have it, and couldnt be mapped), so i got some UT and CoD servers that were ready for x64 Microcode/Intruccions.

I made a "few" tests with that machine. With x86 Kernel and a x64 Kernel. The X64 available at the time ( cba to remember the version i was using a gentoo distro) was a bit buggy and freaking hard to work with a decent uptime. Hey it was baby steps for me aswell. But in a few days ive tested it i got to a nice conclusion.

With a x64 Kernel i ran MORE servers, with MORE players, and MORE workload.It means i had more Live Slots in the same PC, but with x64 kernel/apps. With a NATIVES x64 aplications, that had been COMPILED to x64 microcode. The problem was uptime. the kernel was still buggy. I couldnt get it to last more 12-14 days. The players liked it though. They noticed less "stutter" in some actions.

Sorry mate. If you tell me the Consumer market isnt ready for such a big shift, ill tell you your right. x64 is FASTER than x32. but we are AS ready for X64 and we are for 4 or more Cores per CPU. Most apps wont use more than 1 or 2.
 
This is what an cakewalk had to say about it:

"In conclusion, x64 processing is a very exciting new development for audio workstations. For about the same cost as typical processor upgrade you will get 20-30% more horsepower, plus the ability to play more loops and samples from RAM" from http://www.cakewalk.com/x64/whitepaper.asp

This is some of what PC world mag had to say:
"Let's put it this way: If you think today's computers are fast, wait until they make the leap from 32 bits to 64 bits. This isn't about more megahertz--it's about actually doubling the amount of data a CPU can process per clock cycle."

From http://www.pcworld.com/article/id,111508-page,1/article.html

And here's a view from IBM:
"Logical operations (AND, OR, XOR) also benefit from wider registers, since they can operate on a much larger data size. As a result, applications that involve the manipulation of huge data sets, such as document management and decision support, run much faster on a 64-bit system. Finally, 64-bit processors can drive 32-bit applications even faster, by handling more data per clock cycle than a 32-bit processor. Therefore, even apps that don't need to address memory beyond 4GB can benefit from 64-bit processing."

fROM: http://www.ibm.com/developerworks/library/pa-microdesign/

For me personally 64 bit computing combined with a great machine has made all the difference in CAD work I do. Features I would turn off in 32 bit I now have open, my productivity has probably increased a minum of 20% to about 80% more in some circumstances. Never would I go back to 32 bit for CAD.
 


Or only half as much since op fusion no longer works on core 2 processors...
 


Yeh go on recycle other peoples comments...

Bob
 


I wouldn't have to if other people were actually able to read.

In addition i'm not at a stage where i consider myself to be "other people". I know, i know, sometimes it's rather easy to hit the reply button and post something stupid - not everyone can be flawless like me.
 
I have run some some converting, decoding, etc. crap under linux 64 and 32. From what I have experienced, 64-bit is faster in general. Though of course it depends on what the program is, and if it was written in 64-bit coding.
 
You are focused too much on the software aspect, and not the hardware implementation. Sure, you have twice as much data per clock, but you also need twice the amount of transistors to accomplish this! For example (oversimplified to two vs four registers),

to evaluate (1+2) * (4-3)

two registers (x86) (times 2) run in parallel, seporated by '|' : r1= register 1, r2=register 2
r1 = 1 | r1 = 4
r2 = 2 | r2 = 3
r2 =r2+r1 | r2=r2-r1
(idle) | [mem location] = r2
r1=[mem location] | (idle)
r1 = r1 * r2 | (idle)

now, with 4 registers, one pipeline
r1 = 1
r2 = 2
r3 = 4
r4 = 3
r1 = r1 + r2
r4 = r4 - r3
r4 = r1 * r4


this just as easily could have been done with three registers, though:
r1 = 1
r2 = 2
r1 = r1 + r2
r2 = 4
r3 = 3
r3 = r3 - r2
r3 = r3 * r1


In the first two forms, the same bandwidth is used, only the first one is done in 6 steps, while the latter two are done in 7 steps. However, the last is done using only three registers, so it really only uses (3/4)*7 = 5.25 steps (relatively). However, the first has 3 idle clocks (1.5 if you call each thread a half a clock), making it only effectively use (6-1.5)=4.5 clocks (the scheduler will make sure that these are used by other running programs), so in this example, it is more efficient to use the old architecture! Of course, this is very simplified, and requires much use of multithreading. The real question is in PRACTICE, is it more efficient? Remember, in order to double size of the architecture, you need to double the architecture itself! Saying that x64 is twice as large as x86, while true, is like saying that there is a new pizza that is twice the size of the original. While that is true, they do not tell you that it costs twice as much! So if you have the same amount of money and are ordering a lot of pizza, you get the same amount of pizza either way. The question is, is there more crust (waste) if you order 10 new pizzas or 20 old pizzas? That is very hard to say.....



 
With Win 32 OS, you are limited to use of less than 4 GB of physical memory. Some of the 4 GB dedicated to hardware buffers. With Win 64 OS, you can use more than 4 GB of physical memory. With being able to hold more info in memory, you don't have to read/write to/from the hard drive as frequently. If you are running a lot of programs or memory intensive programs, the Win 64 bit OS with more than 4 GB helps more. So even with 32 bit applications, a Win 64 bit OS can help. 64 bit OS uses 64 bit drivers. Over the years, more programs have been written with 64 bit versions. You get more benefit from 64 bit with applications that are memory intensive (databases, servers, CAD, although even Internet Explorer is a memory hog).