What does it mean for a processor to be 64 bit?

brussell

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?

bodhi

From what I understand it can now process information at 64 bits at a time (if the software is written in that form) So in a sense the G5 could process twice as much information at one time than the G4 or G3. The beauty of the G5 is that it is completely backwards compatiable, meaning it can process 32 bit programs as well as 64 bit no problem. That is the roadblock that Intel is running into with their new 64 bit processor, it's not completely backwards compatiable.

macaddict

Now, what is the difference between processor bits and IPC (instructions per clock)? Just how many bits is are instructions usually?



Altivec is very fast for certain instruction since it handles vector based instructions 128 bits at a time, correct?

the swan

Basically a processor's "bit size" is its integer processing size. 32-bit processors can deal with numbers up to 32-bits (if its an unsigned integer this means 0->4.29 billion). 64-bit processors can deal with numbers up to 2^64 is size, whatever that number is. Its somewhat of a misconception to say that a 64-bit processor processes twice the information. Technically speaking it can, but as I understand it an 64-bit processor can do two 32-bit operations in one clock. Only that if you were previously dealing with numbers larger than 32-bits now you don't have to use any tricks to do it.

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.

outsider

It's a tricky distinction. Personally I consider it 64bit when it uses 64bit memory addressing and all processing units can handle 64bit data (not just the SIMD and FPU but also the Integer unit).

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?

smalm

[quote]Originally posted by The Swan:

<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?

discstickers

Yeah, the G5, if 64 bit, will run all 32 bit apps at full speed (unlike the lovely itanium). However, to gain any advantage with regards to bit counts, apps will have to be remcompiled. But i heard that this is a simple recompile, no large changes like Altivec optimization or Classic to carbon.

ghost_user_name

It's all that easy. My SGI at work as new32 old32 and 64 bit libraries on it. I have to tweak the compiler for one of those three and guess what? Not all the needed libraries are there. So it's not as easy at "click the 64 bit toggle in the compiler". It can be if everything is ready to go.



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.

smalm

[quote]Originally posted by The Swan:

<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.

bodhi

Meanwhile when something takes advantage of AltiVec it is processed in 128 bit integers.

franck

AFAIK, Altivec can't deal with 128b integer but 4* 32bits instead,



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.

airsluf

stepson

I used to work for a rather large company (think "Industrial Average"). We used mostly Sun equipment there, mostly due to the fact that most of the System Admins (like me) had a background in Sun and Solaris. We needed a *really* fast database, so we used a Sun UltraEnterprise 450, and the "In Memory" times ten database (That sun had 4 processors, 400Mhz each, each with 2megs of cache, 4gigs of memory, and many, many SCSI disks). Times Ten is a fast (it was the fastest) RDBMS. It works by keeping the entire database 'In Memory', hence the need for lots of memory .



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!"

the swan

Stepson and Airsluf, great posts.



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.

amorph

What 64-bit means: Essentially, that the instruction words (the block of memory containing an instruction for the CPU to execute) is 64 bits wide; the CPU's general-purpose registers are 64 bits wide; the basic operations (arithmetic, comparative) work with data 64 bits wide; and the CPU fetches instructions and data in 64 bit chunks ("words"). There may be special parts of the processor that deal with wider (or narrower) instructions or data, but they're considered special cases (the G4 is not 128 bit just because the SIMD unit can handle data in 128 bit chunks).



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.

stepson

"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?"



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"

ender

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.)?



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

the swan

"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.)?"





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.

telomar

[quote]Originally posted by Ender:

<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.

outsider

I wonder if Photoshop is taking so long to come to OS X because it's being written to take advantage of a certain 64bit processor? Hmm?

davechen

To use the Altivec unit, you have to program it directly. The compiler won't just take regular C or C++ code and generate Altivec. Instead they add vector types, e.g. "vector float" or "vector int" and routines like vec_add or vec_madd (multiply then add). Here's a link to Motorola's programming manual:



<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