This is for everyone who doesn't know what the difference between 32 and 64 bit is. I found this on Google, it's very informative!
devresource.hp.com/STK/partner/64what.pdf
devresource.hp.com/STK/partner/64what.pdf
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Definitive 64-bit thread
- Thread starter shadowfax0
- Start date
- Sort by reaction score
Ya know, something has been bothering me about the whole 64-bit processors let you do 64-bit integers and larger address spaces. While the larger address space thing is kind of a big deal since we now have 1 Gig DIMMS and it won't be that long before we have 4Gig Memory modules. But the 64-bit integer thing is big whoop, who really needs to add 2 64-bit numbers. 
This attitude is simplistic and it completely ignores what data is. 64 bit registers will allow you to double the amount of data you can process in one opperation. Take text processing for example. Instead of working on 4 characters or bytes in one operation you now can work on 8 characters. Take 32bit graphics. You load half of the data in the high 32-bits and the other half in the lower 32-bits. Take any bit of data of any size and you can chomp through it twice as fast. You have doubled your throughput without increasing your mhz or ghz speed.
This attitude is simplistic and it completely ignores what data is. 64 bit registers will allow you to double the amount of data you can process in one opperation. Take text processing for example. Instead of working on 4 characters or bytes in one operation you now can work on 8 characters. Take 32bit graphics. You load half of the data in the high 32-bits and the other half in the lower 32-bits. Take any bit of data of any size and you can chomp through it twice as fast. You have doubled your throughput without increasing your mhz or ghz speed.
Thoughts from a switcher - a repost in a better place
I guess I am what you would call a switcher. I was an OS/2 to Windows NT to LINUX/UNIX to MacOSX ( better UNIX ) switcher. I now only use OSX and Windows 98 ( and then, only for 1 application )
Having said that, I have to say that this has been a fun discussion to watch. I want to put the memory concerns of this new processor to rest by simply saying that I would be shocked if Apple didn't user DDR 2 ( see http://www.commsdesign.com/design_c...EG20021016S0038 ). This would satisfy the memory bandwidth needs of this new chip.
Second, as for the no performance gain, coupled with the faster P4 mantra, I have to say that there are some mis-informed people here. I suggest that we start a new thread and have everyone list the top 5 apps they use on the mac. This is what would clearly define any performance gain a user would or wouldn't see.
The reason I suggest this is that many high performance app developers on the window side ( and I am sure Mac too ) have been working with 64 bits for a while in their 32-bit applications. Even MS in several of their APIs will divide their values returned from objects in two 32bit chunks that must be reassembled into the original 64 bit values. I myself have seen this in file system operations in the Win32 writing I have done.
Since such operations described above require two ticks of the proc to process, I would take a slower 64 bit AMD or PPC processor in a heart beat over a much faster p4 for hard core applications. So a 5 GHz p4 at best on these types of apps still only keeps up with a 64 bit at half it's speed. An OS optimised for 64-bits make this more so.
Now, will every app see a difference? No.
If my average apps I use often are only Quicken, Mail, IExplorer, iChat, Word, etc. then a 2.4 GHz P4 will be snappier than a 1.8 PPC or AMD. If your average apps are DVD Studio, Final Cut Pro, Maya, Cinema4D, etc. then a 64 system will be an improvement. I won't even go into databases, except to say that in the future, more and more apps will start using them. Need proof ? iPhoto and iTunes both are primitive apps that use a crude database to track your data. Overtime, more and more apps with get more advanced in this idea, and you may see OSs come out with master Databases built into them that iApps, as well as other apps can use natively.
So, with all of this said, What are the apps you use on a daily basis?
Let the flames begin,
Max.
I guess I am what you would call a switcher. I was an OS/2 to Windows NT to LINUX/UNIX to MacOSX ( better UNIX ) switcher. I now only use OSX and Windows 98 ( and then, only for 1 application )
Having said that, I have to say that this has been a fun discussion to watch. I want to put the memory concerns of this new processor to rest by simply saying that I would be shocked if Apple didn't user DDR 2 ( see http://www.commsdesign.com/design_c...EG20021016S0038 ). This would satisfy the memory bandwidth needs of this new chip.
Second, as for the no performance gain, coupled with the faster P4 mantra, I have to say that there are some mis-informed people here. I suggest that we start a new thread and have everyone list the top 5 apps they use on the mac. This is what would clearly define any performance gain a user would or wouldn't see.
The reason I suggest this is that many high performance app developers on the window side ( and I am sure Mac too ) have been working with 64 bits for a while in their 32-bit applications. Even MS in several of their APIs will divide their values returned from objects in two 32bit chunks that must be reassembled into the original 64 bit values. I myself have seen this in file system operations in the Win32 writing I have done.
Since such operations described above require two ticks of the proc to process, I would take a slower 64 bit AMD or PPC processor in a heart beat over a much faster p4 for hard core applications. So a 5 GHz p4 at best on these types of apps still only keeps up with a 64 bit at half it's speed. An OS optimised for 64-bits make this more so.
Now, will every app see a difference? No.
If my average apps I use often are only Quicken, Mail, IExplorer, iChat, Word, etc. then a 2.4 GHz P4 will be snappier than a 1.8 PPC or AMD. If your average apps are DVD Studio, Final Cut Pro, Maya, Cinema4D, etc. then a 64 system will be an improvement. I won't even go into databases, except to say that in the future, more and more apps will start using them. Need proof ? iPhoto and iTunes both are primitive apps that use a crude database to track your data. Overtime, more and more apps with get more advanced in this idea, and you may see OSs come out with master Databases built into them that iApps, as well as other apps can use natively.
So, with all of this said, What are the apps you use on a daily basis?
Let the flames begin,
Max.
Anon:
Yeah so? Your "64-bit rules" example would be done even better by AltiVec. I maintain that there is nothing all that exciting to see with regards to 64 bitness (although I like having it around).
maxvamp:
Since filesystem ops naturally deal a lot with the very very slow hard disk, I fail to see why native 64-bit numbers would make any difference at all. Well, you could count the clock cycles saved, so it is technically more than zero gain. But it's not someting I'm gona worry about.
Anyway my main apps on OSX are Mozilla, Terminal, Finder, Folding@Home, and Project Builder should I ever get time to code again. Also play WC3 and Civ3. I don't see a lot of gain from 64-bitness, but a nice PPC-970 would certainly be nice.
Yeah so? Your "64-bit rules" example would be done even better by AltiVec. I maintain that there is nothing all that exciting to see with regards to 64 bitness (although I like having it around).
maxvamp:
Since filesystem ops naturally deal a lot with the very very slow hard disk, I fail to see why native 64-bit numbers would make any difference at all. Well, you could count the clock cycles saved, so it is technically more than zero gain. But it's not someting I'm gona worry about.
Anyway my main apps on OSX are Mozilla, Terminal, Finder, Folding@Home, and Project Builder should I ever get time to code again. Also play WC3 and Civ3. I don't see a lot of gain from 64-bitness, but a nice PPC-970 would certainly be nice.
64 bitness ??
ddtlm
I can see your questions about 64bitness for you, and your main apps. You may never see a difference. Truth be told Windows 3.1 on a pentium would probably serve most of your mac programs' needs.
Still, there are others that will see a big boost from this processor. The main apps
I use are DVD Studio Pro ( Combined with InnoBits ), MAME, and MoneyDance. I also use the usual selection of net and 'i' apps, of which, I suspect only iTunes and iMovie would see a boost out of the new proc.
I think we will see some apps that will get a big boost from this processor, and some that will see none. Simply look at the old Win95 conversion for examples. 32bit Paint Shop Pro anyone?
max
ddtlm
I can see your questions about 64bitness for you, and your main apps. You may never see a difference. Truth be told Windows 3.1 on a pentium would probably serve most of your mac programs' needs.
Still, there are others that will see a big boost from this processor. The main apps
I use are DVD Studio Pro ( Combined with InnoBits ), MAME, and MoneyDance. I also use the usual selection of net and 'i' apps, of which, I suspect only iTunes and iMovie would see a boost out of the new proc.
I think we will see some apps that will get a big boost from this processor, and some that will see none. Simply look at the old Win95 conversion for examples. 32bit Paint Shop Pro anyone?
max
maxvamp:
Unless the apps you listed have specific use for lots of 64-bit integers or for more than 4gigs of RAM, then I think that AltiVec does a better job than anything that 64-bitness brings to the table. Other than 64-bit integers, whats the point in doing things 64 bits at a time when you can do them 128 bits at a time, without any "funny" business of swapping values into high and low ends of registers?
I'm as happy as anyone about the idea of getting a PPC-970 based Mac, but I far as I can see, the 64-bitness is not something that makes much difference either way.
Unless the apps you listed have specific use for lots of 64-bit integers or for more than 4gigs of RAM, then I think that AltiVec does a better job than anything that 64-bitness brings to the table. Other than 64-bit integers, whats the point in doing things 64 bits at a time when you can do them 128 bits at a time, without any "funny" business of swapping values into high and low ends of registers?
I'm as happy as anyone about the idea of getting a PPC-970 based Mac, but I far as I can see, the 64-bitness is not something that makes much difference either way.
You two are correct, 64-bit won't make much of a difference for the average person, but for people doing Final Cut, Maya, Mathematica (Mathematica might be something we should keep our eyes on, I'm getting excited already!) and things of that sort will. At this point in time, there won't be much if any difference, but the difference will be seen when in a few years when a large amount of programs are written to take advantage of the vast amounts of memory that 64-bit has to offer. Also, I think we may see Apple make a big leap into the pro video market (like Hollywood professional) being that the 64-bit will allow for a port of specialized programs, this will have the same effect on the video industry as OS X did on the scientific community; people will no longer need 3 computers to do one job. Instead of having your Mac for video editing alone, and then having to port that over to your SGI for some heavy duty work, it will now be able to have it all there. I gotta say Apple has alot of the bases covered, and although what I have said may not happen in huge places making multi-million dollar films, I have a feeling it will for smaller/mid-sized production houses it will have a profound impact. (Video edit -> use shake/Maya/Photoshop/any other effects program -> finish in Final Cut -> then one has the option to use Cinema Tools if in high fps ->Edit audio right there using anythign you'd like -> then DVD Studio Pro -> and for people on a tight(er) budget, that's you whole movie, right there!)
That's called...
...SIMD, or vector processing. It's how Altivec works. I've been wondering a bit about why someone hasn't made a 64 bit chip where the scalar ALUs can act as 64 bit wide vector ones. I eventually decided that it was probably because it would add too much complexity to the chip for too little gain (not everything is suited to parallel processing. The things that are are probably already handled by Altivec + 3 ALUs + 2 FPUs + extensive OOOE).
Originally posted by Anon
Ya know, something has been bothering me about the whole 64-bit processors let you do 64-bit integers and larger address spaces. While the larger address space thing is kind of a big deal since we now have 1 Gig DIMMS and it won't be that long before we have 4Gig Memory modules. But the 64-bit integer thing is big whoop, who really needs to add 2 64-bit numbers.
This attitude is simplistic and it completely ignores what data is. 64 bit registers will allow you to double the amount of data you can process in one opperation. Take text processing for example. Instead of working on 4 characters or bytes in one operation you now can work on 8 characters. Take 32bit graphics. You load half of the data in the high 32-bits and the other half in the lower 32-bits. Take any bit of data of any size and you can chomp through it twice as fast. You have doubled your throughput without increasing your mhz or ghz speed.
...SIMD, or vector processing. It's how Altivec works. I've been wondering a bit about why someone hasn't made a 64 bit chip where the scalar ALUs can act as 64 bit wide vector ones. I eventually decided that it was probably because it would add too much complexity to the chip for too little gain (not everything is suited to parallel processing. The things that are are probably already handled by Altivec + 3 ALUs + 2 FPUs + extensive OOOE).
Perhaps if they just changed things so that the AltiVec unit was the main processor and the original PowerPC parts were ancillary to handle I/O and such, the processor would be useful. Certainly, 128 bits should go somewhat faster than 64 or 32 bits.
Being a developer on 64-bit PowerPC systems, I can tell you that there is definitely greater performance available from those one or two cycle savings. For computers with hundreds or thousands of users, the advantages are clear. The average desktop user will see much less of an advantage unless they're doing 3D, movie editing, or playing 3D games where the calculations tend to be more intense.
Developing such an application would once again be much less error-prone, just as it was since the 8->16 bit and the 16->32 bit conversions. When you're constantly running up against the limits, a native data size increase is nirvana.
Being a developer on 64-bit PowerPC systems, I can tell you that there is definitely greater performance available from those one or two cycle savings. For computers with hundreds or thousands of users, the advantages are clear. The average desktop user will see much less of an advantage unless they're doing 3D, movie editing, or playing 3D games where the calculations tend to be more intense.
Developing such an application would once again be much less error-prone, just as it was since the 8->16 bit and the 16->32 bit conversions. When you're constantly running up against the limits, a native data size increase is nirvana.
bousozoku:
At least in the case of "3D games" and "3D" there will no immediate use for a 64-bit processor, since the G4, G3, and everything else already supports 64-bit floating point numbers. The PPC-970 does have much better units to handle the "doubles" though, so thats certainly good.
At least in the case of "3D games" and "3D" there will no immediate use for a 64-bit processor, since the G4, G3, and everything else already supports 64-bit floating point numbers. The PPC-970 does have much better units to handle the "doubles" though, so thats certainly good.
Color depth
One of the few things that film still has over video is color-depth. With the OS natively supporting only 32 bit color depth I don't see much of a speed increase even in video-intensive aplications from going 64-bit. But if digital video, in an effort to overtake films color-depth goes 64 bit, then having an os with native 64 bit color depth would position apple very nicely indeed.
One of the few things that film still has over video is color-depth. With the OS natively supporting only 32 bit color depth I don't see much of a speed increase even in video-intensive aplications from going 64-bit. But if digital video, in an effort to overtake films color-depth goes 64 bit, then having an os with native 64 bit color depth would position apple very nicely indeed.
wrylachlan:
64-bit color depth would presumably mean 16-bit fields for RGB and one for Alpha, and this would not be ideally suited to math as a single 64-bit integer. It would, however, work very well in AltiVec which would treat it as 4x16-bit fields just like it really is. AltiVec could even do two 64-bit color operations per operation since it can handle 8x16-bit fields at once.
64-bit color depth would presumably mean 16-bit fields for RGB and one for Alpha, and this would not be ideally suited to math as a single 64-bit integer. It would, however, work very well in AltiVec which would treat it as 4x16-bit fields just like it really is. AltiVec could even do two 64-bit color operations per operation since it can handle 8x16-bit fields at once.
fwiw, The typical color space for film and high-quality
broadcast video is 10-bit per channel (RGBA = 40bit).
Now whether that 10 bits/channel of info is contained
(or how it's calculated) in 16-bit space (or 40 in 64)
I'm not entirely sure.
64-bit != 2 x 32-bit
This is not even close to correct. It does not work for simple adds or subtracts let alone anything as complicated as a multiple, divide or shift. The same is true of 32-bit CPUs--you don't treat the 32-bits as four separate 8-bit or two separate 16-bit numbers for calculations.
A quick paper calculation of multiplying two sets of two 32-bit numbers will demonstrate this will not work. If you want to spend even more time, try all of the basic ALU operations: add, subtract, multiply, divide, shift left and shift right. You will find that none of them work correctly except in very special cases.
This is not even close to correct. It does not work for simple adds or subtracts let alone anything as complicated as a multiple, divide or shift. The same is true of 32-bit CPUs--you don't treat the 32-bits as four separate 8-bit or two separate 16-bit numbers for calculations.
A quick paper calculation of multiplying two sets of two 32-bit numbers will demonstrate this will not work. If you want to spend even more time, try all of the basic ALU operations: add, subtract, multiply, divide, shift left and shift right. You will find that none of them work correctly except in very special cases.
Re: 64-bit != 2 x 32-bit
You are making the mistake that data held in a register is either all integers or floating point. I agree with you that arithmetic operations on those types by doing what I suggest here would be a nighmare. You would have to do to much checking for overflows in each section. Doing things that microcode already does for you.
The most common type of data I'm talking about that can be used this way is ASCII text. This is hardly a very special case and extremely common. Most people or programs don't add, subtract, multiply or divide text characters. You are doing mainly searches, replaces, deleteing and moving such data.
The shift right or left could be optimized by what I am suggesting. Lets say take 8-bytes of data that you want to shift 3 bits right in each byte.
Most people would write the code like this:
for i= 1 to 8
shiftright (n(i),3)
next i
This looks nice and compact, especially when you look at what you have have to do if you were to do it as a single 64-bit move. as below:
shiftright (reallylongword,3)
templongword=reallylongword AND 1110000011100000111000001110000011100000111000001110000011100000
shiftleft (templongword,5)
reallylongword = reallylongword AND 0001111100011111000111110001111100011111000111110001111100011111
reallylongword=reallylongword AND templongword
But when you loop when it executes actually becomes this:
i=1
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
OK, lets say you optimize it and take out the loop and the array. Your code becomes this:
shiftright(n1,3)
shiftright(n2,3)
shiftright(n3,3)
shiftright(n4,3)
shiftright(n5,3)
shiftright(n6,3)
shiftright(n7,3)
shiftright(n8,3)
You look at my code and say, "My code is 8 lines and yours is 5, some savings but no big deal. Also the 64-bit way is harder to figure out." Lets look at what happens when you compile these. Written in a pseudo assembly.
64-bit way:
move registerA ,reallylongword
Shiftright registerA, 3
move registerB, 1110000011100000111000001110000011100000111000001110000011100000
AND registerB, registerA,
Shiftleft registerB, 5
move registerC, 0001111100011111000111110001111100011111000111110001111100011111
AND registerA, RegisterC
AND registerA, registerB
move reallylongword, registerA
8-bit way:
move registerA, n1
shiftleft registerA, 3
move n1, registerA
move registerA, n2
shiftleft registerA, 3
move n2, registerA
move registerA, n3
shiftleft registerA, 3
move n3, registerA
move registerA, n4
shiftleft registerA, 3
move n4, registerA
move registerA, n5
shiftleft registerA, 3
move n5, registerA
move registerA, n6
shiftleft registerA, 3
move n6, registerA
move registerA, n7
shiftleft registerA, 3
move n7, registerA
move registerA, n8
shiftleft registerA, 3
move n8, registerA
8 lines vs 24. If you consider that some of the data may not be in the cache the 8-bit way way could take significantly longer.
Anyway, I have already conceded the point that Altivec can do what I suggest here considerably easier and in larger chunks.
You are making the mistake that data held in a register is either all integers or floating point. I agree with you that arithmetic operations on those types by doing what I suggest here would be a nighmare. You would have to do to much checking for overflows in each section. Doing things that microcode already does for you.
The most common type of data I'm talking about that can be used this way is ASCII text. This is hardly a very special case and extremely common. Most people or programs don't add, subtract, multiply or divide text characters. You are doing mainly searches, replaces, deleteing and moving such data.
The shift right or left could be optimized by what I am suggesting. Lets say take 8-bytes of data that you want to shift 3 bits right in each byte.
Most people would write the code like this:
for i= 1 to 8
shiftright (n(i),3)
next i
This looks nice and compact, especially when you look at what you have have to do if you were to do it as a single 64-bit move. as below:
shiftright (reallylongword,3)
templongword=reallylongword AND 1110000011100000111000001110000011100000111000001110000011100000
shiftleft (templongword,5)
reallylongword = reallylongword AND 0001111100011111000111110001111100011111000111110001111100011111
reallylongword=reallylongword AND templongword
But when you loop when it executes actually becomes this:
i=1
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
shiftright(n(i),3)
i++
if i>8 end
OK, lets say you optimize it and take out the loop and the array. Your code becomes this:
shiftright(n1,3)
shiftright(n2,3)
shiftright(n3,3)
shiftright(n4,3)
shiftright(n5,3)
shiftright(n6,3)
shiftright(n7,3)
shiftright(n8,3)
You look at my code and say, "My code is 8 lines and yours is 5, some savings but no big deal. Also the 64-bit way is harder to figure out." Lets look at what happens when you compile these. Written in a pseudo assembly.
64-bit way:
move registerA ,reallylongword
Shiftright registerA, 3
move registerB, 1110000011100000111000001110000011100000111000001110000011100000
AND registerB, registerA,
Shiftleft registerB, 5
move registerC, 0001111100011111000111110001111100011111000111110001111100011111
AND registerA, RegisterC
AND registerA, registerB
move reallylongword, registerA
8-bit way:
move registerA, n1
shiftleft registerA, 3
move n1, registerA
move registerA, n2
shiftleft registerA, 3
move n2, registerA
move registerA, n3
shiftleft registerA, 3
move n3, registerA
move registerA, n4
shiftleft registerA, 3
move n4, registerA
move registerA, n5
shiftleft registerA, 3
move n5, registerA
move registerA, n6
shiftleft registerA, 3
move n6, registerA
move registerA, n7
shiftleft registerA, 3
move n7, registerA
move registerA, n8
shiftleft registerA, 3
move n8, registerA
8 lines vs 24. If you consider that some of the data may not be in the cache the 8-bit way way could take significantly longer.
Anyway, I have already conceded the point that Altivec can do what I suggest here considerably easier and in larger chunks.
I put forward the assertion that the most significant benefit of a 64 bit processor is that the size of an address (ie a memory pointer), rather than an integer is 64 bits. And this is because of sparse memory spaces, not fully populated (!!!!) memory systems.
Apart from very unusual situations, Altivec is probably going to give more general performance gain than 64 bit integers.
Now, who was I disagreeing with
Apart from very unusual situations, Altivec is probably going to give more general performance gain than 64 bit integers.
Now, who was I disagreeing with
Re: Thoughts from a switcher - a repost in a better place
right, but as we all know, people are using more and more their computer to digital media (MP3, Video editing...). So I think it will be great to jump to 64 bit cpu. Anyway mail, web browser, text editor... are already fast enough even on a P3! People should check the need they have before claiming for speed like you say.
One domain that will be really enchanced I believe it's game. They use a lot of CPU and GPU.
I use video editing on a dual 450 and it work great for my need, but to play recent game it's a different storie with a GForce 2MX! I would appreciate to see 64 bit copmuter but it will be long before programmer opimize their appz, even the OS. Just like ALTI-VEC, but if PC move to 64 bit too, it can accelerate the move.
right, but as we all know, people are using more and more their computer to digital media (MP3, Video editing...). So I think it will be great to jump to 64 bit cpu. Anyway mail, web browser, text editor... are already fast enough even on a P3! People should check the need they have before claiming for speed like you say.
One domain that will be really enchanced I believe it's game. They use a lot of CPU and GPU.
I use video editing on a dual 450 and it work great for my need, but to play recent game it's a different storie with a GForce 2MX! I would appreciate to see 64 bit copmuter but it will be long before programmer opimize their appz, even the OS. Just like ALTI-VEC, but if PC move to 64 bit too, it can accelerate the move.
Ti_Pousin:
Perhaps you didn't read the posts above, but so far in this thread it has been very well established that 64-bitness is not a big deal. There are very very few things 64-bitness does for us that AltiVec cannot do better. Please stop going on about 64-bitness already, it is not a big deal.
Perhaps you didn't read the posts above, but so far in this thread it has been very well established that 64-bitness is not a big deal. There are very very few things 64-bitness does for us that AltiVec cannot do better. Please stop going on about 64-bitness already, it is not a big deal.
...on the contrary, it may be a big deal. Perhaps not in the sense you're saying, but as history in the time of the personal computer, it's huge. This blurs the line between a personal and industrial computer. This means that there will be ports of SGI software to OS X, and that Apple will be making inroads into places never even thought of. In THAT way, it's a big deal. Think about it, what does SGI have that's worth $22,000 for a single workstation...? Out of what they offer, it's the fact that you can get a quad 64-bit setup with access to something like 12-20 GB of memory. I think this will an integral step for Apple, and could possibly ensure their future into different parts of the computer market.