or Connect
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › What does it mean for a processor to be 64 bit?
New Posts  All Forums:Forum Nav:

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

post #1 of 28
Thread Starter 
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?
post #2 of 28
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.
I'm making plastics right now!
Reply
I'm making plastics right now!
Reply
post #3 of 28
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?
*Registered March 1, 1999*
Member #14
Reply
*Registered March 1, 1999*
Member #14
Reply
post #4 of 28
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.
post #5 of 28
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?
post #6 of 28
[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?
post #7 of 28
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.
"It's not like Windows users don't have any power; I think they are happy with Windows, and that's an incredibly depressing thought." -Steve Jobs
Reply
"It's not like Windows users don't have any power; I think they are happy with Windows, and that's an incredibly depressing thought." -Steve Jobs
Reply
post #8 of 28
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.
post #9 of 28
[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.
post #10 of 28
Meanwhile when something takes advantage of AltiVec it is processed in 128 bit integers.
I'm making plastics right now!
Reply
I'm making plastics right now!
Reply
post #11 of 28
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.
post #12 of 28
post #13 of 28
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!"
post #14 of 28
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.
post #15 of 28
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.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #16 of 28
"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"
post #17 of 28
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
If you find yourself sided with the majority, it is time to change your thinking.

-Mark Twain
Reply
If you find yourself sided with the majority, it is time to change your thinking.

-Mark Twain
Reply
post #18 of 28
"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.
post #19 of 28
[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.
"When I was a kid, my favourite relative was Uncle Caveman. After school, wed all go play in his cave, and every once and awhile, hed eat one of us. It wasnt until later that I discovered Uncle...
Reply
"When I was a kid, my favourite relative was Uncle Caveman. After school, wed all go play in his cave, and every once and awhile, hed eat one of us. It wasnt until later that I discovered Uncle...
Reply
post #20 of 28
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?
post #21 of 28
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
post #22 of 28
[quote]Originally posted by Outsider:
<strong>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?</strong><hr></blockquote>

Not likely. A simple recompile is all that is needed to make a 32bit app 64bit.
"It's not like Windows users don't have any power; I think they are happy with Windows, and that's an incredibly depressing thought." -Steve Jobs
Reply
"It's not like Windows users don't have any power; I think they are happy with Windows, and that's an incredibly depressing thought." -Steve Jobs
Reply
post #23 of 28
[quote]Originally posted by Franck:
<strong>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.</strong><hr></blockquote>

That's correct, basically, but AltiVec is not limited to 4 * 32bit Int. Other alternatives are 8 * 4bit Int, 16 * 8Bit Int, or 4 * 32bit Float.


[quote]<strong>That's because Altivec is roughly 4 times faster than a traditionnal ALU when dealing with integers.</strong><hr></blockquote>

It's more like AltiVec is multiple ALUs in one (though all are controlled by the same CU, and thus all have to perform the same operation at any given time).

Bye,
RazzFazz
post #24 of 28
[quote]Originally posted by AirSluf:
<strong>
Altivec is set up to handle 4 32bit floats loaded back to back and apply a single common instruction against all 4 of them simultaneously (in parallel.) It is not faster from in to out, but accomplishes 4x the work in the same number of cycles because it has 4 mini fpu's stacked side by side. </strong><hr></blockquote>

Actually, AltiVec can handle data in 4*32, 8*16 aand 16*8 int format too, so there are probably not just 4 ALUs in there, but between 4 and 16, depending on the instruction. (Of course, silicon does not just magically (dis)appear, so it's probably one large reconfigurable / subdividable one.)

Bye,
RazzFazz
post #25 of 28
[quote]Originally posted by Amorph:
<strong>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</strong><hr></blockquote>

That's probably not a very good criterium. x86 CPUs, for example, have a completely non-uniform instruction length, and thus would be something between 8-bit and 256-bit, depending on instruction, prefixes, modifiers and operands.


[quote]<strong>and the CPU fetches instructions and data in 64 bit chunks ("words").</strong><hr></blockquote>

Not a valid criterium either. x86 processors have been fetching data from main memory in 64 bit chunks since the original pentium, and I think the same is true for current PPCs. Datapaths to the L1 cache are sometimes even as wide as 256 bit (P3).


[quote]<strong>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.</strong><hr></blockquote>

Since most current CPUs use their GP registers for address calculations, this is not really an issue.
True, some CPUs have address buses that are wider than their GP registers, but they still usually have 32bit address operands for their instructions. To reach the additional memory space provided by the other 4 address lines, they resort to using additional segment registers. Note that these always *add* to width of the GP registers, so the number of address bus lines is always bigger thatn the GP register width, so moving to 64 bit GPRs *will* automatically increase addressabel memory space.

[quote]<strong>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.)</strong><hr></blockquote>

It actually did? x86 processors do too, but hardly anybody else. Also, I wonder how memory alignment was handled with 80 bit (not a power of 2) floats...


[quote]<strong>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.</strong><hr></blockquote>

Hmm, I'd agree in most cases, but I wonder what the benefit would be in graphics - a 64-bit color space would probably be of little use given the human eye's restrictions.


[quote]<strong>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).</strong><hr></blockquote>

Actually, the main memory bus has been 64 bits wide for a long time. You're probably referring to the address bus.


[quote]<strong>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.</strong><hr></blockquote>

This is definitely true.
Obviously, the same was true when the transition from 16 bit to 32 bit was made, but there was a significant difference: Back then, the limits imposed by being 16-bit were visible (and hindering) in everyday use, so a trading in some bandwidth in exchange for larger address space was very acceptable for most users. Nowadays, on the other hand, 32 bit address space is not such an immediately limiting factor. It's only a problem in a few situations (mainly huge databases, scientific stuff probably uses floats [already 64 bit wide today] anyway), and most users are not likely to ever run across it. As such, most users would not see any benefit at all (everybody who has ever run a program larger than 4GB please raise your hand , but would still have to sacrifice memory bandwidth. So, in general, I think moving the complete line to 64 bits is not a good option for Apple at this time.


[quote]<strong>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.</strong><hr></blockquote>

As stated above, memory transfers in all current 32 bit CPUs are already 64 bits wide (as is SDRAM, incidentially).

Bye,
RazzFazz
post #26 of 28
[quote]Originally posted by RazzFazz:
<strong> It actually did? x86 processors do too, but hardly anybody else. Also, I wonder how memory alignment was handled with 80 bit (not a power of 2) floats... </strong><hr></blockquote>

Only FPU registers and calculation is done in 80 bits. These 80 bit are converted to 64 before stored to memory. PPC604e FPU is 64 bit.
What a pity, the 603 core was used to develop the G3!
post #27 of 28
x86 processors are too wierd to serve as metrics for anything. I did assume a lot of the RISC design goals in my post, but that's fair for a RISC-based processor.

Also, it was not the 604e. It was the 68040 that had the 80-bit FPU.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #28 of 28
Thanks for the great information! I've only taken a couple programming courses, and I've learned a little on my own, but I am considering majoring in CS when I go off to college next year.

-Ender
If you find yourself sided with the majority, it is time to change your thinking.

-Mark Twain
Reply
If you find yourself sided with the majority, it is time to change your thinking.

-Mark Twain
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Future Apple Hardware
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › What does it mean for a processor to be 64 bit?