I have a question reguarding the true performance of 64bit CPUs vs. that of 32bit CPUs.
I understand that 64bit architectures allow for much more accurate calculations than 32bit architectures can.
What I am wondering is, what can be expected in true benchmark performance of a 64bit CPU (say a Clawhammer for example) vs. a 32bit CPU (like the T-bird) as it relates to the most demmanding programs such as CAD/CAM/CAE/CAID and 3D Animation progs like Maya, 3DSMAX, Softimage, etc.. Also I am wondering what to expect it to do for 2D graphics progs like Photoshop and Illustrator, and 3D gaming.
My question is only reguarding the difference between 64bit and 32bit, NOT what to expect from increased and improved instruction sets like SSE2. And NOT an increase in clock speed or an improved cache system.
Obviously these factors will have an impact on performance as well, but what I really want to know is what to expect out of a fundamental change from 32bit to 64bit architecture in a clock for clock comparison.
That is assuming you have the proper software support for both.
For example- a 1GHz 32bit CPU vs. a 1GHz 64bit CPU
More about :64bit cpu architecture 32bit cpu architecture
Well, your not going to go anywhere if the software your using isn't 64 bit. So, we won't know how it performs until companies release 64 bit versions of their software, which will take time. That goes for the OS too. But, you can probably relate 32 to 64 bit like 16 to 32 bit. At first, there probably won't be a HUGE increase, but as time goes on and ppl figure out how to optimize 64 bit code it will get faster. Sorta like the move from Win 3.1 to Win95 or NT3.51 to NT4.
But, from what I understand Windows 2000 (64 bit version) is multi-threaded. Which is a big change from Multitasking. Part of the reason G3's and G4's (apple CPU's) perform so well is MacOS is a multithreaded OS as is the G3/G4 processor family. So, you can yield great performance at a low clock speed. That's also part of the reason Itanium doesn't run at an outrageous clockspeed like 1.5Ghz, it's designed to work with multithreaded OS's. Get the idea? So, there may be a huge increase- only time will tell. =)
PS, multithreading in a nutshell is basically an OS and processor working in unison to perform many tasks or programs at the same time. Unlike multi-tasking which divides the processor's time.
December 1, 2000 3:49:41 AM
"multithreading in a nutshell is basically an OS and processor working in unison to perform many tasks or programs at the same time. "
The only fundamental difference between 32-bit CPU's and 64-bit CPU's is 64-bit addressing and 64-bit registers. I suppose you could implement flat 64-bit addressing with a CPU that had 32-bit registers, but I don't see why you'd want to.
There are 2 reasons a 64-bit architecture will outperform a 32-bit architecture. One is the capability to have >4GB memory visable to a process at a time. Some of the early 64-bit DEC Alpha machines reported huge performance boosts on applications that had >4GB working sets. Obviously, if an application can execute in 8GB vs. paging like crazy in 2GB, you will see a huge performance increase.
The other is that internal processor paths are usually (not necessarily) wider in 64-bit implementations. Many 64-bit processors (such as IBM's Power3 & RS64-IV) have bus widths that are several times wider than machine instructions (e.g. 256 bits wide)
The increased "accuracy" you're probably talking about is due to having 64-bit registers and 64-bit adders and such necessitated by 64-bit addressing. So if you are doing integer calculations that use numbers >4 billion or so, they can be executed much faster. IEEE floating point has always been "64-bit" in that the registers are 64-bits wide, even on 32-bit architectures.
Dunno what mpjesse was talking about re: multithreading. Software multithreading is a function of the OS and applications, not a microprocessor. I'm sure Linux running on 32-bit PPC/X86 supports POSIX threads.
OK, a multithreading OS processes programs running in memory at the same time, IN unison. a multitasking OS switches back and forth between programs and divides the processors time/power. ex. Windows processes stuff going on in napster for like 1 sec, then goes to AOL, then to WinAmp and then all the way back to napster again... it's a cycle.. only it's a LOT faster than a second. Anyways, it's kinda slow. Multithreading is a lot faster, running napster, AOL, and winamp all at the same time- NOT switching.
Intel and AMD processors can multithread, but their not designed around it because what do most Intel and AMD processors run? Windows- which is a multitasking OS. Now, processors like G4/G3, Alpha/Compaq, and anything not designed with x86 code is centered around a multithreading OS, like linux, MacOS, etc.
Back to Itanium... Itanium and Windows 2000 64 bit are supposedly based on multithreading technologies. So, i think we will see a pretty good increase in speed with 64 bit code. =)
January 7, 2001 11:37:53 PM
You can't run AOL, napster & winamp at the same time unless you have 3 or more processors. The difference between multithreading and multitasking is that the former allows processes to fork off threads, whereas the only parallelism achieved in the latter is at the process level. MacOS barely even has multitasking, at least until OS X. It does not support threads and only has rudimentary SMP support according to the 11/00 issue of MacWorld.
Multithreading is an OS function, not a microprocessor function. All a processor has to do to support multithreading is to have some way of trapping to an OS service routine after a given time slice.
Even the old Intel Paragon supercomputers with i860's could "multithread"....
Didn't I say AMD and Intel processors are capable of multithreading? I sure did. I have no idea what your going on about, but MacOS has been a multithreaded environment since OS 8. And now your saying that OS X barely supports multitasking? Well your frigin right because it's a multithreading OS.
My whole point is that I did say x86 code can multithread and does. Take for example Linux or Solaris, both multithreaded (depending on the kernel version). All you really did was reiterate what I posted.
January 8, 2001 6:19:11 AM
I think you guys are getting it confused with pipelining--hardware (mulithreading is software).
Please someone clear it up, now im confused...
January 8, 2001 9:22:49 AM
With 64 bit OS's and 64bit Processor cores.. are we going to see the introduction of a new slot? ISA's are 16 bit (DOS and win 3.x).. when Win95 came out they inroduced the PCI slot (32bit).. now will we see either a new type of PCI slot or a completely different one? I'm interested to see if they try to integrate 64 and 32 into the same PCI slot or just make a whole new one.
This thread is a little confused to say the least.
64-bit processors are nothing special. They can address more memory than 32 bit processors but this doesn't matter if you don't need vast amounts of memory. They can also perform 64 bit arithmetic quicker than 32 bit processors because they don't have to emulate it using 32 bit instructions.
As for speed improvements you can actually expect the performance to be slower on a 64 bit system as the instructions take up more space and so fewer can be cached in a given space. The degradation in performance is of the order of 5%. Only in those cases where you NEED more than 4GB of RAM can you expect to have big increases in performance.
As for the deviation in the thread about multi-tasking vs multi-threading the basic definitions may be helpful.
A process adresses its own memory, no process may normally refer to memory used by another process. Multiple processes running at exactly the same time MUST be running on multiple processors. This IS multitasking/mutliprocessing.
Multithreading occurs when you have specific support in the operating system. This allows two CPUs to be working at exactly the same time using the memory space of one process. The CPUs are executing different THREADs of the same program. Using multiple threads can be pretty tricky as the programmer has to be aware that something else can change variables.