10.2.7 and the G5

[close]

Re: Re: Speed vs. volume

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]

Re: Re: Speed vs. volume

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.

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]

Re: Re: Re: Speed vs. volume

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]

My crack at the analogy

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]

Question?

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=cach..._b.ppt+powerpc+"register+size"&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]

financial calculations

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]

Re: 64 Bitness

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

Re: 64 bit optimizations can really help

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

AppleMatt

 

[Edot]

G5 Optimizations

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