What does it mean for a processor to be 64 bit?
OK, so the G5 is supposed to be 64-bit (or at least have a 64-bit version). What does this mean? More memory is accessible? Will it be faster?
Is it true that OSX would have to be re-written or re-compiled to run? And if it's 32-bit backward compatible, will there be any benefit at all to running 32-bit software?
Is it true that OSX would have to be re-written or re-compiled to run? And if it's 32-bit backward compatible, will there be any benefit at all to running 32-bit software?
Comments
Altivec is very fast for certain instruction since it handles vector based instructions 128 bits at a time, correct?
Alti-Vec is a 128-bit vector processing unit. How vector processing units work I don't know the details. But suffice it to say that it can accept 128-bits of data and have this 128-bits be four single-precision floating point numbers, I believe.
The G5 is supposed to be 32bit backwards compatible so I don't THINK software has to be recompiled for it just like it didn't have to be recompiled for G3 -> G4. But like the previouse case, it would result in better performance if it is recompiled. Is there any info on this?
<strong> 64-bit processors can deal with numbers up to 2^64 is size, whatever that number is.</strong><hr></blockquote>
18.45 billion billion?
A 64 bit is not automatically twice as fast as a 32 bit. Consider that something like photoshop does integer ops most of the time and the integers are all 32 bits or less and most often 16 or 8.
<strong> How vector processing units work I don't know the details.</strong><hr></blockquote>
<a href="http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECFACT.pdf" target="_blank">http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECFACT.pdf</a>
Sorry, didn't find it directly.
You can't add 2 128bits integers using Altivec in a single step, but you can add 4 * ( 2 32bits integers) in a single one.
That's because Altivec is roughly 4 times faster than a traditionnal ALU when dealing with integers.
Er, anyway, back to my point. UltraSparc processors (At least the most recent ones) can work in 64 or 32bit mode. You load up 32bit solaris, they work as 32bit, you load up 64 bit solaris, it works as as a 64 bit processor. Thats how i understood it anyway. Times ten also came in 64 bit version. When one of their support engineers was at our place (One thing nice about being a big company, other companies bend over backwards for you), I asked him "should we go to 64bit everything? What kind of performance will we gain?" He said, basically, probably none, and we may even take a slight hit. We'd be able to have a bigger maximum database size (something astronomical), but it'd be slightly slower for normal database sizes due to 'moving more around in memory'. Soo ....
Being 64bit may only be good for a marketing perspective. "Look, OSX! Now with 64bits, and we remember where your icons go!"
I think the best thing for Apple to do now, even if the G5 does come out, is to use 32-bit OS X. Stepson, you don't mention, but with a 64-bit processor operating in 32-bit mode are you still moving 64-bit integers around in memory? It would seem to me the answer is now. Certainly you can only move 32-bit integers (or floats or whatever) into the processor and then front or back load (depending on your endian orientation) it with zeros. Moving out of the processor you could generate 64-bit numbers but the OS would ideally reduce these back to 32-bit if the processor or memory system didn't.
So basically stay with 32-bit OS X to keep memory bandwidth down. However, if Apple wants to get serious in the server market then a 64-bit OS is at the very list a powerful [marketing] feature.
Notice that the amount of memory the CPU can address is not on that list. It's not uncommon for CPU address registers to be wider than the general registers: For instance, the 8-bit 65C02 had a 16 bit memory bus to allow it to address a whopping 64K. The 7450 reportedly has a 36-bit memory bus.
The effects of going from 32-bit to 64-bit are, generally:
64-bit precision computations go a lot faster. (Note, however, that a 64-bit G5 will still trail the lowly 604e in raw precision: The 604e came with a special 80 bit FPU, and a lot of scientists really miss that little feature.) This will speed up Lightwave 3D, and a few other high-end, high-precision applications (Maya?!), and it might prompt high-end 32-bit apps like Photoshop to switch to 64-bit precision when possible. More is always better as far as precision goes. Furthermore, I have heard rumblings that 64-bit color is in the pipeline; if not now, soon.
If the main memory bus is 64 bit, you can address truly insane amounts of real and, with an appropriately tweaked filesystem, insane amounts of external storage space and virtual memory. ("insane" ~= 1.6 exabytes, by an offhand calculation, where 1 exabyte = 1 million gigabytes).
Application files (object files) bloat, because instead of loading instructions and data in 32-bit chunks, it loads them in 64-bit chunks. This means that if your instruction or data only takes up 32 bits then you're wasting a lot of space - the other 32 bits are padded and/or ignored.
With some adaptation, a handful of instructions which previously had to be loaded first as a 32-bit "instruction" word and then as a 32-bit "data" word might be able to run faster simply because the CPU can load them both at once. This is a hypothetical, not by any means a given. It might very well not provide enough of a performance boost to be worth the trouble of implementing it.
I believe not. When using 32bit solaris, the ultrasparc operates in 32bit mode, and doesn't know anything about 64bits ... I haven't even seen too many applications that require or even offer 64bit binaries. As I mentioned, times ten does ... and there may be a few other applications by now, i haven't been dealing with solaris in quite a while.
If you look here: <a href="http://www.timesten.com/products/64bitdatasheet.html" target="_blank">http://www.timesten.com/products/64bitdatasheet.html</a> , you'll see more about how times ten utilizes a 64bit processor. They also mention "IBM's PowerPC"
Is it only based on the fact that we think a 400 MHz bus is likely, faster RAM, as well as some other buzzword technology (rapid IO, Gigawire, etc.)?
Also, I had one question about the Velocity Engine. I wrote a simple program that used a large repetition FOR loop. It generated a random single precision number and did some stuff with it, compared it to other numbers, and then stored it in the place that I wanted.
Anyway, what I did was not important, but on my Ti PB G4, the same program using integers, single, and double precision floating numbers all executed at the exact speed. Is there some special code that must be used to utilize the VE?
BTW-it's ok if none of that made any sense. If so, just ignore me
-Ender
Is it only based on the fact that we think a 400 MHz bus is likely, faster RAM, as well as some other buzzword technology (rapid IO, Gigawire, etc.)?"
No, not at all. The G5 is a completely new processor design with more functional units, more transistors, and redesigned functional units. All these translate to higher performance. The faster bus and RAM will certainly help, but won't do much without a processor that can actually crunch more data.
"Is there some special code that must be used to utilize the VE?"
Yeah, you have to use libraries that will allow you to utilize the special AltiVec functions.
<strong>So if indeed this is all relatively accurate, and 64 bit is generally not much faster than 32 bit, why is everybody stating that a 1.6 GHz G5 crush a 2+ GHz P4?
Is it only based on the fact that we think a 400 MHz bus is likely, faster RAM, as well as some other buzzword technology (rapid IO, Gigawire, etc.)?
</strong><hr></blockquote>
64-bit processors are faster in certain circumstances only the average person won't deal with them. Engineers and scientists will surely find the benefits though.
There is a good link here if you want to read it and to save me explaining. It isn't perfect but it is decent especially on the subject of why we should to introduce it.
<a href="http://www.mackido.com/Hardware/64Bit.html" target="_blank">64Bit link</a>
What makes the G5 faster is the fact it is actually a faster chip. Keep in mind it is a redesigned chip. The G4s are deficient in certain areas (integer and floating point units) and the G5 is leaps and bounds ahead. That's what narrows the gap so much.
Keep in mind also a 1.6GHz G5 has a 10 stage pipeline compared to a 2GHz PIV which has a 20 stage one.
DDR RAM and various other motherboard improvements will help performance considerably too. This has in the past been an area Apple has been a bit behind in.
As it happens there is some other innovative stuff they have done to gain performance. Can't tell you much on it though. Just have to wait until it is announced to learn more on it.
<a href="http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECPIM.pdf" target="_blank">http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECPIM.pdf</a>
It's pretty fun to code for, if you can manuever your data into 128 bit chunks.
Talking about 64 bit processors, it sounds like it's mostly not worth it, unless you need to address big memory. If not, you lose because all your pointers get blown up to 64 bits, increasing the amount of memory bandwidth you need.
dave