10.2.7 and the G5

[MacRumors]

ZDNet reports (http://zdnet.com.com/2100-1103_2-5064990.html) on the shipping PowerMac G5s.

As was long rumored, the article reports that the PowerMac G5s ship with Mac OS X 10.2.7 (codename: Smeagol). 10.2.7 provides PowerMac G5 hardware support, as well as 64-bit support.

In particular, version 10.2.7 of Mac OS X has math and vector libraries that are optimized for the 64-bit chip, as well as the ability to address more than 4 gigabytes of physical memory, breaking through a limitation of 32-bit chips.

Readers are reminded that the speed advantages of the PowerMac G5 computers lie primarily in the increased performance of the processor and subsystems rather than the "64-bit"-ness of the computer.

[arn]

Before anyone says.... "things will be much faster with a true 64-bit version of the OS"

stop right there.

it won't.

There are g5-specific optimizations, but many people will not need true "64-bit" apps.

again, the PowerMac G5 is faster than current macs because it has a faster bus, faster ram, and a faster processor.

arn

[evilfunkgenius]

Arn, maybe you need to add a new tab to the top to try and explain all the technical information/rumors that go on here. As strange as it might be, I learn more about new technology hanging around this place than anywhere else. You could call the tab "Rumor Technology"....!

[Powerbook G5]

I don't know why everyone is so hung up on OS X not being "fully 64 bit" and all. As long as it lets the processor flex its muscle and addresses its full memory capabilities, it'll be great. I for one will not have 4 GB of memory, let alone 8...so I don't see a reason for my needing it besides having a faster processor/bus. It's a little sad knowing the bus on my G3 is just under half that of the G4...you'd think after all these years they could get a little faster than 167 MHz.

[zoozx]

X.2.7 ..........whooopeee.
Now tell me all of uz guys that bought a G5 early are not going to be penalized / shafted when Panther releases in a month and all G5 ship with it.
Tell me we get a "get out of jail free" upgrade coupon in the box for Panther.

[andyduncan]

Originally posted by evilfunkgenius
Arn, maybe you need to add a new tab to the top to try and explain all the technical information/rumors that go on here.

Not a bad idea. No need for new content, however, just link it to ars (http://www.arstechnica.com/).

Making the same argument over and over is decidedly un-Object-Oriented. Especially when it has been argued better by someone else (ie: ars has a great article debunking 64bitness). Make a pointer out of a link and *this.

[MrMacMan]

Hm... so it is finally coming, good for them...


Tho I have had it for a good deal of time, I'd say what 5 days?
:o



To get extra speed that comes with '64-bit ness' you need to optomize the code, something that many devolpers will be doing I am sure.

:D

[arn]

Originally posted by MrMacman
To get extra speed that comes with '64-bit ness' you need to optomize the code, something that many devolpers will be doing I am sure.


No, you do not - that was the whole point of my first two posts. Please reread them.

64-bit does not equal faster.

arn

[chetwilliams]

Originally posted by zoozx
X.2.7 ..........whooopeee.
Now tell me all of uz guys that bought a G5 early are not going to be penalized / shafted when Panther releases in a month and all G5 ship with it.
Tell me we get a "get out of jail free" upgrade coupon in the box for Panther.

Not me. I'm an ADC member so Panther is free. Not to mention that Panther Server is free so I can test out my web server as well.

[eric_n_dfw]

Originally posted by MrMacman
To get extra speed that comes with '64-bit ness' you need to optomize the code, something that many devolpers will be doing I am sure.

:D Did you read arn's post?

Please tell me what you do that would be sped up by native 64 bit applications? (Really, I am curious!)

The code that needs to be optimized the most is the GCC compiler -- for the G5's scheduling.

[Powerbook G5]

Well...I've heard nothing but good things about the 64-bit enhanced Stickies! :)

[chetwilliams]

Originally posted by eric_n_dfw
Did you read arn's post?

Please tell me what you do that would be sped up by native 64 bit applications? (Really, I am curious!)

The code that needs to be optimized the most is the GCC compiler -- for the G5's scheduling.

Hmmm. I can only think of a ton of things that would be faster. Though day-to-day apps like Word or Mail won't be sped up, pro apps such as Final Cut Pro (faster at HD video w/ 64), Photoshop (faster w/ 64), Mathematica (faster w/ 64), and of course folding would be sped up. Just because most apps won't be helped with 64 does not mean all apps won't be helped with 64.

[johnnowak]

Originally posted by MrMacman

To get extra speed that comes with '64-bit ness' you need to optomize the code, something that many devolpers will be doing I am sure.

:D

Ugh, that's embarrasing.

[snuffub]

Originally posted by arn
No, you do not - that was the whole point of my first two posts. Please reread them.

64-bit does not equal faster.

arn

In all fairness to this guy there is the point that it will be a while before the true potential of the chip will be reached because _both_ compiler optimization as well as app code optimization will have a huge impact. Just look at the new photoshop patch adobe is about to release. That said the optimizations have little to do with the fact that it's a 64bit chip, it has to do with the fact that the 970 has a different pipe line, different execution units and different latencies than the G4. It's no different from when any new architecture comes out, just look at early pentium 4 benchmarks they took a while to mature and their design was more similar to their predecesor than the 970 is to the G4.

[acj]

Originally posted by chetwilliams
Hmmm. I can only think of a ton of things that would be faster. Though day-to-day apps like Word or Mail won't be sped up, pro apps such as Final Cut Pro (faster at HD video w/ 64), Photoshop (faster w/ 64), Mathematica (faster w/ 64), and of course folding would be sped up. Just because most apps won't be helped with 64 does not mean all apps won't be helped with 64.

Are the optimizations for these programs specifically 64 bit? Or are they just G5?

[TMay]

Originally posted by chetwilliams
Hmmm. I can only think of a ton of things that would be faster. Though day-to-day apps like Word or Mail won't be sped up, pro apps such as Final Cut Pro (faster at HD video w/ 64), Photoshop (faster w/ 64), Mathematica (faster w/ 64), and of course folding would be sped up. Just because most apps won't be helped with 64 does not mean all apps won't be helped with 64.
I'm with you on this one.

Since there are many execution units, 64 bit integer, floating point, and vector in the 970, and multiples of these as it were, one could make the argument that concurrent processes carefully matched to the data types would be quite beneficial in multimedia apps.

As an example (in Photoshop), I could see 48 bit color plus 16 bit alpha operations well suited for the 64 bit integer execution units. Similarly, some filters may work quite effectively with the floating point units, leaving the balance to Altivec. I would argue that the memory bandwidth would make it efficient to process these concurrently for maximum performance, especially with multiple processors. That's a lot of simultaneous processing!

That said, I think it is premature to argue that a 64 bit processor won't be faster, when specifically, what needs to be stated is that there are operations that 64 bit processor may be faster at (than the 32 bit), and until we see some developers push the 970 performance envelope and optimize code, we can't really know how much benefit 64 bit provides.

[Freg3000]

Ok, I am just as likely to say something stupid and have everyone angrily correct me, so, instead of me guessing in the form of a question what the advantages of a 64 bit processor are, can someone just tell me?

If it is not speed, what is it (besides >4GB Ram)?

[esheep2001]

Originally posted by Freg3000
Ok, I am just as likely to say something stupid and have everyone angrily correct me, so, instead of me guessing in the form of a question what the advantages of a 64 bit processor are, can someone just tell me?

If it is not speed, what is it (besides >4GB Ram)?

The most widely accepted reason is the ability to handle twice as much data (64 bits instead of 32) in a single processor cycle.

Ordinarily this does equate to speed but in the case of the G5 (970) the architectural design allows for a transition from a 32 to 64 bit operating system by allowing existing 32 bit applications to run without modification. Hence these apps won't gain the speed advantage (other than through clock speed) until they are rebuit specially for the G5, and the OS will be hampered to some extent until all apps are built for 64 bits. This is the bug bear that people are talking about.

However you only need to look at the lacklustre market performace of the Itanium, which goes straight to 64 bits without the ability for transitioning, to see that the G5 (and AMD BTW) way is the best way as it keeps the largest number of people happy by allowing them to run all their favourite apps immediately. Itanium needs a special OS AND optimised apps (I believe) to run at all.

Basically what Apple have done is the equivalent of the 68k to PPC transition but without any of the pain.

Hope this helps.

e.

[snuffub]

Originally posted by esheep2001
The most widely accepted reason is the ability to handle twice as much data (64 bits instead of 32) in a single processor cycle.

Ordinarily this does equate to speed but in the case of the G5 (970) the architectural design allows for a transition from a 32 to 64 bit operating system by allowing existing 32 bit applications to run without modification. Hence these apps won't gain the speed advantage (other than through clock speed) until they are rebuit specially for the G5, and the OS will be hampered to some extent until all apps are built for 64 bits. This is the bug bear that people are talking about.

However you only need to look at the lacklustre market performace of the Itanium, which goes straight to 64 bits without the ability for transitioning, to see that the G5 (and AMD BTW) way is the best way as it keeps the largest number of people happy by allowing them to run all their favourite apps immediately. Itanium needs a special OS AND optimised apps (I believe) to run at all.

Basically what Apple have done is the equivalent of the 68k to PPC transition but without any of the pain.

Hope this helps.

e.

Errr... i feel like this is a futile battle to be fighting but I think youve got the wrong idea about how the 970 handles 32 bit legacy code. Rewriting apps is not a matter of making them 64bit apps so that they’ll run in native mode. It’s a matter of making the type of instructions, as well as the order of instructions conducive to fully utilizing all the parts of the processor so your task finishes in the fewest cycles. On the 970 a 32bit add takes the same number of cycles as a 64bit add if im not mistaken.

Now to answer that guy’s question as to the benefits of 64bit processors imagine this situation. You can only comprehend numbers up to 9 and you want to add the numbers 13 and 25 in this situation you would have to do the following steps.

Look at the last digit of the first number.. look at the last digit of the second number. add the two. write down whether the two numbers “overflowed” or added up to a number more than you can comprehend. Write down the part that didn’t overflow, ie if they added to 6 write down six if they added to 16 also write down six. Look at the next digit of the first number. Look at the next digit of the second number. Add the two. Write down if they overflowed….
You see where this is going

Now imagine you can comprehend numbers up to 1000. to add 13 and 25 you would look at the two numbers add then and write down the result.

So that’s the very long, very convoluted way to say that 64bit processors are much faster at operations which you need to work with big numbers. Mathmatica could be one of those apps, certain physics calculations, encryption, and a whole bunch of other apps that no one’s thought of making yet because up until very recently 64bit processors weren’t available to enough end users.

[Edot]

Here is the way I undertand it. Correct me if I am wrong.

64bit processors will not increase the speed of code written for 32bit processors, nor will code written for 8bit processors increase on a 32bit processor. (excluding speed increases) However, 64bit processors allow for more complex applications to be written. These apps aren't functional on a 32bit processor because of the speed at which it would run (Like OS X on a 128k). A 64bit app can process more instuctions at a time compared to 32bit apps. Applications and OSes will fill the processor sooner or later. More eye-candy for all!

I believe the issue is Speed vs Volume, which seem to be getting confused.

[Wonder Boy]

Originally posted by Powerbook G5
Well...I've heard nothing but good things about the 64-bit enhanced Stickies! :)

HAHA. I read somewhere that Clock is much faster now, too. Though I still haven't figured out the benifits of that yet.

[visor]

Originally posted by arn
There are g5-specific optimizations, but many people will not need true "64-bit" apps.



Oh well, who needs extremely large floating point operations anyway...

thank god all rendering and Gaming Apps won't need floating point operations... All those high end apps that do real time processing -surely they won't need floating points...
Thank god we don't need large memory. My god, designing a poster ought to be good enough at a resolution 640*480, right?

It makes far more sense to optimize on 8 bits - for backwards compatibility, you know.

[visor]

Originally posted by Edot
Here is the way I undertand it. Correct me if I am wrong.

I believe the issue is Speed vs Volume, which seem to be getting confused.

You've got a point there. On ADTV there is a free clip that focusses on optimizing on a G5.
The original code was about 13 times slower on the same maschine as the optimized one, using more threads, and using the Velocity angine.
In fact - data bandwith was still only used half - so with more optimizing, you could possible get a few more multipliers out of the maschine.

So, it's true, if you run old unoptimized code - it will only scale with the processor frequency. If however, you write optimized code - you can get exponential speed increases.

[sacrilicious]

Originally posted by Wonder Boy
HAHA. I read somewhere that Clock is much faster now, too. Though I still haven't figured out the benifits of that yet.

Hehehe.

[leo]

I can think of a few situations where 64-bit integer operations built in hardware will result in a performance boost. But, as others have pointed out, this is rarely the case.

But I can also think of situations where the long pipelines of the G5 will result in rather poor performance. Some algorithms have a complicated branching scheme and the processor doesn't do much other than handling pipeline stalls. And on the G5, these really hurt.

Also, the G5s relative memory latency is longer than that of the G4 (i.e. more cycles to access memory). Algorithms that make massive use of global data can be relatively poor in performance, especially with big data blocks and when the access scheme is really "random"/non-consecutive, thus leading to cache misses. The higher clock might compensate this to some extent, but you get the point.

I just want to point out: don't expect the G5 to excel in *every* situation.

[hvfsl]

People in this thread seem to think that 64bit is the same speed as 32bit. When software is optimised for 64bit it will be faster than 32bit software running of the G5. There may not be a big difference, but there will be some. This is because 64bit code can be processed more efficently than 32bit on the G5. This is due to the fact that 64bit apps will be throwing more data at the G5 over a period of time compared to 32bit apps. The G5 has a limit to the amount of data it can process over a period of time, but 64bit code makes it easier for the G5 to reach that limit.

[DakotaGuy]

Originally posted by Powerbook G5
It's a little sad knowing the bus on my G3 is just under half that of the G4...you'd think after all these years they could get a little faster than 167 MHz.

They did get a little faster 800Mhz to 1Ghz on the G5. I know you are talking about the G4 bus, but you make it sound like a faster machine is not offered.

[Don]

The G5 has a limit to the amount of data it can process over a period of time, but 64bit code makes it easier for the G5 to reach that limit.

wouldn't that make it run slower if it can reach its limit easier? shouldn't it run better if it is harder to reach its limit? sorry if im being stupid...i jst woke up and am awaiting pb updates!! :p

[freddiecable]

I want Panther to be delivered with my Dual 2Ghz G5! What if - you don't get a free update!?

PowerMac G5 was everything we wanted - and more! Stop BSing about performance. Obviously it will be a blazingly fast computer - AND it does not have to be 10 times faster than a 3 Ghz Pentium - it's sufficient enough to be as fast or a little bit faster...

peace brothers and sisters:p

[leo]

Originally posted by hvfsl
People in this thread seem to think that 64bit is the same speed as 32bit.


Well, 64-bit can also be slower, because the caches can only hold half the number of adresses.


When software is optimised for 64bit it will be faster than 32bit software running of the G5. There may not be a big difference, but there will be some. This is because 64bit code can be processed more efficently than 32bit on the G5.

Can you elaborate this?

And what exactly is "64-bit code"? The instruction set of the G5 itself does not differ from that of the G4, except for some cache-hinting and the ability to interpret a 64-bit integer as a 42-bit address.

In how far does the code of the inner loop of a photoshop filter differ when optimised for G5, except for the adapted instruction scheduling and cache-hinting (which are independent of 64-bitness)?

[MacRETARD]

Originally posted by visor
Oh well, who needs extremely large floating point operations anyway...

thank god all rendering and Gaming Apps won't need floating point operations... All those high end apps that do real time processing -surely they won't need floating points...
Thank god we don't need large memory. My god, designing a poster ought to be good enough at a resolution 640*480, right?

It makes far more sense to optimize on 8 bits - for backwards compatibility, you know.

1) Floating point operations are already bigger than 64 bits on the G4, surprise surprise! They are 80 Bits.

2) If you have a 64 bit pointer, its takes 64 bits of memory, if you have a 32 bit pointer it takes 32 bits. Also if you have a program that uses an integer with the default size it will be 32 bits in a 32 bit program and 64 bits in a 64 bit program. Sorry to seem like im being redundant but I have a point. The point is if you program doesnt need to use integer operations (not floating point), or access more memory than 4 gigs then a lot of the program will take up twice as much memory. If it takes twice as much memory it fills up cache quicker and it takes cycles to move across the memory bus.

All other things being equal (same compiler, code, etc) a 32 bit program on the G5 should be slightly faster than the 64 bit version unless it needs more than 4 gigs of memory or large integer math.

FYI - on some low end 64 bit sun boxes you can run them in 32 bit mode for speed and to use less memory.

[zedwards]

Originally posted by Powerbook G5
Well...I've heard nothing but good things about the 64-bit enhanced Stickies! :)
I heard that the Bomb.app is particularily unstable when updated to utilize 64 bits. It just crashes even faster!
:p

[clonenode]

Originally posted by zoozx
X.2.7 ..........whooopeee.
Now tell me all of uz guys that bought a G5 early are not going to be penalized / shafted when Panther releases in a month and all G5 ship with it.
Tell me we get a "get out of jail free" upgrade coupon in the box for Panther. Why are you getting penalized when you buy an Apple product with the most up-to-date OS at that time. Panther is another product... you know it is coming out soon, but the current OS works fine. You're only getting shafted in your mind. Why does Apple owe you an upgrade?

[coumerelli]

Here's my uneducated guess on the subject...

Changing from a 32 bit to a 64 bit proc is like going from a 32 lane hwy to a 64 lane hwy BOTH of which are, say, 70 mph. Although the 64 lane hwy is not inherently faster, there will be less bottle necking and therefore less 'traffic' jams - I just don't know what more RAM translates into in this illustration. ;)

Am I anywhere near to being close?

[CooCooCaChoo]

Originally posted by coumerelli
Here's my uneducated guess on the subject...

Changing from a 32 bit to a 64 bit proc is like going from a 32 lane hwy to a 64 lane hwy BOTH of which are, say, 70 mph. Although the 64 lane hwy is not inherently faster, there will be less bottle necking and therefore less 'traffic' jams - I just don't know what more RAM translates into in this illustration. ;)

Am I anywhere near to being close?

No, the issue is more like this:

Say I download a copy of FreeBSD, I then proceed to compile all the software from the ports collection, BUT instead of using just the default optimisations, I decide to add mcpu=i686 march=pentiumpro to my /etc/defaults/make.conf file. The net result in some cases is an improvement depending upon what code is being compiled. For an CODEC for example, it will now take full advantage of MMX/SSE features that are available..

Regarding the processor itself there are a number of improvements, for example, it now does MORE work per cycle than the G4 or the P4. The best way to describe is is Athlon XP vs P4. The P4 does 0.5 instructions per clock cycle which allows a higher frequency at the expense of lower efficiency. The net result? Intel have had to design a new mobile CPU which does more work per clock cycle so that power consumption and heat disappation decreases.

Also, there are other features, for example, the way the banch prediction portion of the chip does its work. If the code is recompiled again, with out changes, the code is then optimised, via the compiler, for the new features of the CPU.

As for the so-called "64bit optimisations", it will be like MMX, if the chip doesn't have it, that portion of the code won't be used.

[NoNothing]

----------
quote:

I can think of a few situations where 64-bit integer operations built in hardware will result in a performance boost. But, as others have pointed out, this is rarely the case.
----------

I can think of many more conditions where the 64 bit nature can benefit ANY application. ONE example (There a dozens more): Most applications consist of moving memory around from point A to point B. Many applications use a simply memcpy() to do this. And yes, if the routine is optimizes to move 8 bytes at a time and not a single byte, 2 bytes, of 4 bytes at a time, it will move faster. Almost twice as fast. Optimizing this one routine could speed EVERY application.

I think people are very short sighted (or have never programmed a computer) when they make blanket statements that the 64 bitness will not speed up apps even when they are optimized for it.

[neilw]

Heh, I was just going to post about memcpy(), ya beat me to it. It would seem like an obvious place to put some 64-bit code.

I wonder, though, if large moves would be more dominated by cache behaviour than the inner loop of the move itself. If the data are all in cache, then indeed a 64-bit memcpy() should be exactly twice as fast as the 32-bit version. How much effect this would have on typical programs I don't know.

Do either Smeagol or Panther allow true 64-bit code to be used by applications? I'm still not clear on that one...

[gothamac]

What's happened to the new cheese grater displays that were to be announced today?

[wizard]

There is a problem with the absoluteness of this statement. The fact that you have 64 bit registers does not mean that existing code will run faster that is certainly true.

On the other hand it is a mistake to believe that some operating system level modules can not be improved by the use of a processors 64 bit features. File systems are one thing that comes to mind along with anything else that uses large bit arrays. Search algorithms may also be improved by wider registers. The are other potential improvements also, but yes software has to be rewritten to take advantage of any possible 64 bit gain.

One should not be confused with the reality though that some code will never benefit and that some may even slow down if they are ported to a 64 bit environment. Your statemnt would have much more credibility if you simply modify it to indicate that 64 bits in many cases does on imply faster operation.

Dave


Originally posted by arn
No, you do not - that was the whole point of my first two posts. Please reread them.

64-bit does not equal faster.

arn

[wizard]

Its great to see that someone has this right. The same applies for you operating system.

Portions of MAC OS/X will benefit from the 970's 64 bit capabilities. I can't say precisely which parts of the OS will, but some operations will be enhanced by the use of the wider registers. I'm sure that Apple has already determined which parts of the system will benefit the most form 64 bit operations and has a progrma in place to move those modules to 64 bit.

Thanks
Dave


Originally posted by chetwilliams
Hmmm. I can only think of a ton of things that would be faster. Though day-to-day apps like Word or Mail won't be sped up, pro apps such as Final Cut Pro (faster at HD video w/ 64), Photoshop (faster w/ 64), Mathematica (faster w/ 64), and of course folding would be sped up. Just because most apps won't be helped with 64 does not mean all apps won't be helped with 64.

[wizard]

Originally posted by MacRETARD
1) Floating point operations are already bigger than 64 bits on the G4, surprise surprise! They are 80 Bits.

Hmm are you really sure about that on the Power PC

2) If you have a 64 bit pointer, its takes 64 bits of memory, if you have a 32 bit pointer it takes 32 bits. Also if you have a program that uses an integer with the default size it will be 32 bits in a 32 bit program and 64 bits in a 64 bit program. Sorry to seem like im being redundant but I have a point. The point is if you program doesnt need to use integer operations (not floating point), or access more memory than 4 gigs then a lot of the program will take up twice as much memory. If it takes twice as much memory it fills up cache quicker and it takes cycles to move across the memory bus.

Adding the capability to use 64 bit features of the porcessor does not automatically make it twice as large. This is a huge misstatement. Sure you have to the potential to fill the caches with larger data types, but the programmer has to be responsible enough ot select the right data types for the problem being solved. If done correctly the overall results will be capability increases in said program.


All other things being equal (same compiler, code, etc) a 32 bit program on the G5 should be slightly faster than the 64 bit version unless it needs more than 4 gigs of memory or large integer math.

FYI - on some low end 64 bit sun boxes you can run them in 32 bit mode for speed and to use less memory.

What is nice about the G5 system is that this is not required at all. Those programs that loose with trespect ot 64 bit implementation can stay 32 bits for a very long time. This is really a unsung capability of the 970 and its implementation with OS/X.

Dave

[Catfish_Man]

Originally posted by andyduncan
Not a bad idea. No need for new content, however, just link it to ars (http://www.arstechnica.com/).

Making the same argument over and over is decidedly un-Object-Oriented. Especially when it has been argued better by someone else (ie: ars has a great article debunking 64bitness). Make a pointer out of a link and *this.

idea++;

Heck, if you wanted to make it friendlier, you could just link directly to some of their articles as well (after getting permission, of course). I learned a good deal of what I know about CPUs from reading every ars article I could get my hands on.

[yanges]

Originally posted by zoozx
X.2.7 ..........whooopeee.
Now tell me all of uz guys that bought a G5 early are not going to be penalized / shafted when Panther releases in a month and all G5 ship with it.
Tell me we get a "get out of jail free" upgrade coupon in the box for Panther.

geez, we all knew that it would be coming with X.2.7, so what's the problem?

i myself decided to wait till Panther is the default OS and to check out benchmarks etc to decide.....:cool:

that said, i may have to order Right Now!!

:D :D

[leo]

Originally posted by NoNothing


I can think of many more conditions where the 64 bit nature can benefit ANY application. ONE example (There a dozens more): Most applications consist of moving memory around from point A to point B. Many applications use a simply memcpy() to do this. And yes, if the routine is optimizes to move 8 bytes at a time and not a single byte, 2 bytes, of 4 bytes at a time, it will move faster. Almost twice as fast. Optimizing this one routine could speed EVERY application.

Sorry, memcpy() (and memmove() as well) are already Altivec-enhanced in Mac OS X, so even the G4 is moving memory in 128-bit chunks. (But even in non-Altivec versions, like on a G3, the limiting factor has always been the memory bandwidth, not the chunk size.) The G5 is very good at moving memory, but NOT because of its native word length of 64 bits, but because of its advanced memory interface.


I think people are very short sighted (or have never programmed a computer) when they make blanket statements that the 64 bitness will not speed up apps even when they are optimized for it.

Well, I am very sure that I know what I'm talking about.

[AppleMatt]

Originally posted by zoozx

Tell me we get a "get out of jail free" upgrade coupon in the box for Panther.

If they're shipping now...we should know soon.

I would hope so simply to avoid the absolute riot that will explode if they don't. It'll be like 68k/PPC + MDD noise + iPod Software all rolled into one :(

AppleMatt

[clarkcox3]

Do either Smeagol or Panther allow true 64-bit code to be used by applications? I'm still not clear on that one...

There is no such thing as "64-bit" code or "32-bit" code (in the case of the G5). For the most part, code for the G5 and code for the G4 are identical. They have largely the same instruction set. Using a term like "true 64-bit" code is misleading, and just shows ignorance.

The speed advantages of the G5 primarily come from things besides it's "64-bit-ness". Except for applications that need to do lots of large integer calculations, you are not likely to see much (if any) speedup by recompiling to use the additional instructions. You will likely see a speedup as applications are optimized for other attributes of the G5, just as you saw speedups on the G4 when applications were optimized for the G4.

[eric_n_dfw]

A: Games, by and large, do NOT use floating point math - it's slow and there's no need for it. Fixed point (aka integer) math will always be faster and is what is used in most applications. 64 integers are overkill for games as you can represent 16+ million colors per pixel + alpha chanels in 32 bits.

B: I'd doubt that image and video manipulation software use floating point much either - BUT - they might be able to take advantage of 64 bit integers in the high end, pro print markets (Large format print and high end digital photography and processing). HD video, AFAIK, uses 24 bit color, just like SD so each pixel can be represented in 32 bit chunks. (correct me if I'm wrong)

C: As stated, G4 AltiVec already can process 128 bit chunks for vectorized applications.

D: The physical memory bus on the G4 is already 64 bits wide. (BTW, I believe I read that the G5 has 2 32 bit busses, one coming into and one going out of the cpu)

Lastly, here's a quote from an ArsTechnica article (http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html) that says better what I (and I think arn) are trying to get accross:
Some applications, mostly in the realm of scientific computing (MATLAB, Mathematica, MAPLE, etc.) and simulations, require 64-bit integers because they work with numbers outside the dynamic range of 32-bit integers. When the result of a calculation exceeds the range of possible integer values, you get a situation called either overflow (i.e. the result was greater than the highest positive integer) or underflow (i.e. the result was less than the largest negative integer). When this happens, the number you get in the register isn't the right answer. There's a bit in the x86's processor status word (see this page for a bit more on the PSW) that allows you to check to see if an integer has just exceeded the processor's dynamic range, so you know that the result is bogus. Such situations are very, very rare in integer applications. As an engineering student I never ran into this problem, although I did run into the somewhat related problem of floating-point round-off error a few times.

Programmers who run into integer overflow or underflow problems on a 32-bit platform do have the option of using a 64-bit integer construct provided by a higher level language like C. In such cases, the compiler uses two registers per integer, one for each half of the integer, to do 64-bit calculations in 32-bit hardware. This has obvious performance drawbacks, making it less desirable than a true 64-bit integer implementation.

Finally, there is another application domain for which 64-bit integers can offer real benefits: cryptography. Most popular encryption schemes rely on the multiplication and factoring of very large integers, and the larger the integers the more secure the encryption. As we'll discuss in the final section, AMD is hoping that the growing demand for tighter security and more encryption in the mainstream business and consumer computing markets will make a cheap, 64-bit, x86-compatible processor attractive.

So, mainly scientists and cryptogrophers need 64 bit math. By the sound of these forums, we have a lot of those types here :-)

In other news, 64 Bit addressing is a no brainer - if you need it, this will be a God-send.

The FSB speeds and optimizations for the G5's scheduling & pipelines will bring speed to the masses. 64 Bit's is just the icing on the cake!

[brhmac]

Here's my uneducated guess on the subject...

Changing from a 32 bit to a 64 bit proc is like going from a 32 lane hwy to a 64 lane hwy BOTH of which are, say, 70 mph. Although the 64 lane hwy is not inherently faster, there will be less bottle necking and therefore less 'traffic' jams - I just don't know what more RAM translates into in this illustration.

Am I anywhere near to being close?

Can someone respond to this metaphor with the same language? The person who responded earlier dropped the hwy metaphor in his response and gave a very technical reply that didn't make much sense to me.

Given the discussion, it seems like a number of folks are confused about the merits and capabilities of 64-bit processing. I know I am. :confused:

[clarkcox3]

: Games, by and large, do NOT use floating point math - it's slow and there's no need for it. Fixed point (aka integer) math will always be faster and is what is used in most applications. 64 integers are overkill for games as you can represent 16+ million colors per pixel + alpha chanels in 32 bits.


I'm sorry, but that is just plain wrong. Fixed point math is actually slower on the PPC than floating point math.

check out http://www.macscene.org/ppcdc/triangles.php as an example (first hit I found on Google)

[Parikh1234]

quick question for everyone. If OS X 10.2.7 is finished why cant you download it for the powermacs and powerbooks?

[close]

Originally posted by brhmac
Can someone respond to this metaphor with the same language? I'm as ignorant as you, but i'll give it a try:
32-bit: 32 lane highway.
64-bit: 32 lane highway but the lanes have double width so giant trucks with two full-length 48-53 foot trailers hooked together can drive easily.

[eric_n_dfw]

Originally posted by clarkcox3
I'm sorry, but that is just plain wrong. Fixed point math is actually slower on the PPC than floating point math.

check out http://www.macscene.org/ppcdc/triangles.php as an example (first hit I found on Google) Forgive me - I'm not a game coder - but wouldn't the topics discussed on that page all be handled by the 3d graphics card rather than by the CPU in a modern game? Besides, jaggie's are pretty common place on software rendered 3d games, that's because the prettieness which the author speaks of comes at a price. Sure, the PPC may proved an instruction that adds an int an fp at the same time, but can it be run superscalar? (Can multiple alu's do that instruction at the same time?)

Maybe I'm talking out my ars here - like I said, I'm no game programmer - but the people I've known that are have always contended that FP math is too slow compared to Int math.

Besides, the main argument I am putting out is that 64 bitness is of little help for games and MOST people do with PC's

[abb]

Originally posted by brhmac
Can someone respond to this metaphor with the same language? The person who responded earlier dropped the hwy metaphor in his response and gave a very technical reply that didn't make much sense to me.

Given the discussion, it seems like a number of folks are confused about the merits and capabilities of 64-bit processing. I know I am. :confused:

The highways aren't what the 64 bit tag on the G5 refers to. It's more like, a parking lot where the spaces are twice as big. It's great for the scientists and cryptographers who used to have park their RVs across two spaces. Everyone else's cars fit fine in regular spaces though, and making them twice as big doesn't achieve much.

And no, you can't park two cars in one big space, not unless you weld them together first, which makes them undrivable for most purposes. And of course, why'd you want to when there's an altivec parking lot nearby that 's designed for parking lots of cars at once?

64-bit is great for expanded memory, but it doesn't enhance performance unless you drive an RV.

[AppleMatt]

Originally posted by Parikh1234
quick question for everyone. If OS X 10.2.7 is finished why cant you download it for the powermacs and powerbooks?

quick answer:
ADC members can download it, that means it's in testing.
the rumored new powerbooks will require a software update. People have a nasty habit of pulling these to pieces and sending the results to rumor sites, ie

"looking at the xxxxx.xx file in the 10.2.7 update, there is a file called 15" keyboard" etc etc.

AppleMatt

[bankshot]

Originally posted by close
I'm as ignorant as you, but i'll give it a try:
32-bit: 32 lane highway.
64-bit: 32 lane highway but the lanes have double width so giant trucks with two full-length 48-53 foot trailers hooked together can drive easily.

Excellent analogy. My limited understanding is that 64-bit and 32-bit integers (for example) will both travel through the CPU's pipelines at the same speed. What I believe you CAN'T do is pack two 32-bit integers into one 64-bit slot to speed up 32-bit stuff. That's why people are saying 64-bit isn't twice as fast, etc. Of course.

From this perspective, simply recompiling your application to take use 64-bit numbers instead of 32-bit gains no speed whatsoever. However if you were already using 64-bit integers, recompiling to take advantage of the CPU's native 64-bit slots (rather than using two 32-bit slots) should help. Am I right?

And of course, the highway that really matters is the one going from the CPU to the rest of the machine (main memory, etc). That one has a much lower speed limit which you're likely to hit whether you take small cars (32-bit integers) or big trucks (64-bit).

That's about the limit of my knowledge, and please correct me if you know I'm wrong. I do know that I've seen a lot of misinformation in this thread already, but I don't quite have the expertise to correct it! ;)

[magitekkn]

Here's my take on it, based on my work with an 8-bit PIC18F452 microcontroller (essentially a dumb computer with ram built onto the chip with lots of little I/O toys attached):

The PIC18F452 is an 8-bit computer. It is a very popular chip due to its simplicity in instructions and low cost. However, it can only deal with 8-bits of data "at a time." I say "at a time" because you can have operations that manipulate 16-bit pointers anyways. However to do this, the PIC must first operate on the lower 8 bits, and then operate on the upper 8 bits. This effectively allows the PIC to deal with variables that are 16 bits long without being a 16-bit computer (ie having a 16-bit data bus, a 16-bit instruction set etc...)

Were this same operation done by a 16-bit microcontroller, the operation could be done in one pass since the chip can look at the whole variable at the same time.

now, neglecting the part that multiple execution units could play in this, a 32-bit processor (with 32-bit registers) can only deal with 32 bits at a time, when a program needs to talk about a 64-bit variable it will have to deal with the lower 32-bits first, then the high 32-bits taking roughly 2x a long to deal with this operation. A 64-bit processor would be capable of manipulating any 64-bit value whether it be a pointer, integer, double precision float, etc... in a single swipe, thus saving cpu time.

[mjones4th]

Forgive me in advance if this is a stupid question.

If Panther is optimized for the G5, what happens to the huge G3 and G4 user base? Will it be backward compatible?

Signed,

Concerned Quicksilver User

[abb]

bankshot is correct (and very concise) on all points.

magitekkn: Even a PowerPC 601 (http://216.239.33.104/search?q=cache:tkSNKD7uKJoJ:www.enel.ucalgary.ca/People/Smith/2002webs/encm515_02/02individualassignments/PowerPC_b.ppt+powerpc+%22register+size%22&hl=en&ie=UTF-8) from 1994 can handle 64-bit ("double precision") floats natively. The new 64-bit ness is for integers and pointers (especially pointers).

The other thing to remember is that integers are numbers, not arbitrary chunks of data. A G5 can eg add two 64-bit integers together natively. If you put tried to put a pair of 32-bit numbers in each G5 64-bit register*, the processor treats them as a single 64-bit number, so operations like adding no longer make sense. That's why saying it can process twice as much data at once is in most cases a mistake.

* register = parking space in my analogy earlier

mjones4th: Optimizing for a processor usually means ordering the instructions in the way that's most convenient for the way that processor is designed. That means "G5 optimized" code will be less conveniently ordered for a G4, but it'll still run, just slightly slower. There's no need to worry.

[TMay]

Just thought that I might add that 64 bit integers might be important for financial calculations.

[AppleMatt]

Originally posted by abb
bThat means "G5 optimized" code will be less conveniently ordered for a G4, but it'll still run, just slightly slower. There's no need to worry.

The reports I read claimed that G5 optimised code also ran faster on the G4's, there was quite a bit of discussion about it too...

AppleMatt

[wizard]

Originally posted by eric_n_dfw
A: Games, by and large, do NOT use floating point math - it's slow and there's no need for it. Fixed point (aka integer) math will always be faster and is what is used in most applications. 64 integers are overkill for games as you can represent 16+ million colors per pixel + alpha chanels in 32 bits.

This is not strickly the case, even for the G4 many developers found that it was justified to use the FPU. Now just as many found that it was justified to use the Alt-VEC facility to process floats. Like all things in life there are trade offs, just because floating point works well in one program does not mean that another program will see an equal payoff.


B: I'd doubt that image and video manipulation software use floating point much either - BUT - they might be able to take advantage of 64 bit integers in the high end, pro print markets (Large format print and high end digital photography and processing). HD video, AFAIK, uses 24 bit color, just like SD so each pixel can be represented in 32 bit chunks. (correct me if I'm wrong)

C: As stated, G4 AltiVec already can process 128 bit chunks for vectorized applications.

The vector unit processes data elements up to 32 bits in size. The data is arrainged in groups 128 bits in size, so in the case of 32 bit data it is processing 4, 32 bit chunks at a time.


D: The physical memory bus on the G4 is already 64 bits wide. (BTW, I believe I read that the G5 has 2 32 bit busses, one coming into and one going out of the cpu)

Lastly, here's a quote from an ArsTechnica article (http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html) that says better what I (and I think arn) are trying to get accross:


So, mainly scientists and cryptogrophers need 64 bit math. By the sound of these forums, we have a lot of those types here :-)

So you're saying that only scientist and cryptographers use cryptography and 64 bit math? Clearly that is not the case, this is just antoher example of where the average user will benefit from 64 bit engines. 64 bits will help in places like networking protocols and security applications.

It seems as if people are under estimating how much 64 bits will help with certain parts of the system software. These are often out of site programs, that none the less impact a systems performance. Sure not all of OS/X will be helped by 64 bit operations but a few optimized libraries here and there might have a surprising impact.

As far as user space software goes that is really a question of the users application. Some will be able to take advantge quickly of the new capabilities and others never will.

From the standpoint of floating point operations the one thing that programers now have is a whole bunch of scratch registers to store their data. It will be interesting to see just how far the 970 can go as far as optimizations for FP work, I see alot of potential.


In other news, 64 Bit addressing is a no brainer - if you need it, this will be a God-send.

Boy you hit that one right on the head.


The FSB speeds and optimizations for the G5's scheduling & pipelines will bring speed to the masses. 64 Bit's is just the icing on the cake!

[RBR2]

Originally posted by Powerbook G5
I don't know why everyone is so hung up on OS X not being "fully 64 bit" and all.

It's pretty simple. Apple is advertising it as a 64 bit computer which, at best, is a half truth and at worst is a bold faced lie. The G5 will be running 32 bit apps. That makes it a 32 bit computer. It can address memory in a 64 bit manner, but that does not make it a 64 bit computer. Apple can only blame themselves for the reaction. The G5 may best be described as a computer which may become a 64 bit computer when it gets a 64 bit OS and apps.

[Parikh1234]

Originally posted by AppleMatt
quick answer:
ADC members can download it, that means it's in testing.
the rumored new powerbooks will require a software update. People have a nasty habit of pulling these to pieces and sending the results to rumor sites, ie

"looking at the xxxxx.xx file in the 10.2.7 update, there is a file called 15" keyboard" etc etc.

AppleMatt

so then the people who had their g5 shipped this week will get a OS installed thats still in beta? or is it final for g5 but in beta for g4 and lower?

[WM.]

Originally posted by snuffub
Now to answer that guy’s question as to the benefits of 64bit processors imagine this situation. You can only comprehend numbers up to 9 and you want to add the numbers 13 and 25 in this situation you would have to do the following steps.

Look at the last digit of the first number.. look at the last digit of the second number. add the two. write down whether the two numbers “overflowed” or added up to a number more than you can comprehend. Write down the part that didn’t overflow, ie if they added to 6 write down six if they added to 16 also write down six. Look at the next digit of the first number. Look at the next digit of the second number. Add the two. Write down if they overflowed….
You see where this is going

Now imagine you can comprehend numbers up to 1000. to add 13 and 25 you would look at the two numbers add then and write down the result.
Yes, yes, yes, yes, yes, yes!

I'm not a programmer, but that seems pretty accurate to me!

WM

[Kamu-San]

Originally posted by RBR2
It's pretty simple. Apple is advertising it as a 64 bit computer which, at best, is a half truth and at worst is a bold faced lie. The G5 will be running 32 bit apps. That makes it a 32 bit computer. It can address memory in a 64 bit manner, but that does not make it a 64 bit computer. Apple can only blame themselves for the reaction. The G5 may best be described as a computer which may become a 64 bit computer when it gets a 64 bit OS and apps.

The computer is still 64-bits.
If I run 32-bit apps on 64-bit Solaris, does my Sun box suddenly become a 32-bit computer? Don't think so.

[moki]

Originally posted by NoNothing I can think of many more conditions where the 64 bit nature can benefit ANY application. ONE example (There a dozens more): Most applications consist of moving memory around from point A to point B. Many applications use a simply memcpy() to do this. And yes, if the routine is optimizes to move 8 bytes at a time and not a single byte, 2 bytes, of 4 bytes at a time, it will move faster. Almost twice as fast. Optimizing this one routine could speed EVERY application.

I think people are very short sighted (or have never programmed a computer) when they make blanket statements that the 64 bitness will not speed up apps even when they are optimized for it.

You are assuming that memcpy() is not already highly optimized, to do such things as use the 64 bit floating point registers to speed up block copies, or even to use the 128 bit altivec registers (if available) to do said copies.

Such an assumption is, shall we say, erroneous. That stuff is already in there.

It is true that making an application 64 bit does not inherently make it faster; indeed, it can make it slower, and it uses slightly more RAM as well. Highway analogies need not apply, that isn't how it works.

The only applications that will benefit by being 64 bit are those that perform integer calculations on large numbers (numbers larger than 2^32), or those applications that need to address more than 4gb of RAM (OS support willing, of course).

There certainly will be optimizations for the G5's architecture that apps can take advantage of by recompiling -- but please, trust me on this one -- don't start demanding "64 bit" versions of your favorite applications.

The odds are extremely good that what you think you want, you really don't.

[AppleMatt]

Originally posted by Parikh1234
so then the people who had their g5 shipped this week will get a OS installed thats still in beta? or is it final for g5 but in beta for g4 and lower?

I don't know, it's interesting. A new build of 10.2.7 (6R43) was seeded to ADC on Saturday. Perhaps the G5's will come with a 'beta' 10.2.7, and there will be the 'final' 10.2.7 in Software Update. Who knows?!

Originally posted by RBR2
The G5 will be running 32 bit apps. That makes it a 32 bit computer. It can address memory in a 64 bit manner, but that does not make it a 64 bit computer.

Are you quite sure about that :rolleyes:? I don't think Apple is to blame for the reaction, I think false-truthes are to blame for the reaction.
Also please explain how installing a 64-bit OS suddenly changes the hardware from almost-64bit to fully fledged 64-bit :confused:

AppleMatt

[Edot]

This article explains in detail why and how you should optimize code for the G5. Some fuctions and code that are written for the G4 will run poorly or not at all if not optimized for the new processor. Moreover, speed improvements may also be a product of optimizing your code. These processors are different and some code may need to be, or should be written to reflect this. Whether using 64bits or not!

http://developer.apple.com/technotes/tn/tn2087.html#Quick