PDA

View Full Version : Quote from Arstechnica on 64bit processors


caveman_uk
Mar 12, 2003, 06:01 AM
Note that I attributed the CS performance increase to x86-64's larger number of registers, and not the increased register width. On applications that do not require the extended dynamic range afforded by larger integers (and this covers the vast majority of applications, including games), the only kind of performance increase that you can expect from a straight 64-bit port is whatever additional performance you get from having more memory available. As I said earlier, 64-bitness, by itself, doesn't really improve performance for anything but the rare 64-bit integer application. In the case of x86-64, it's the added registers and other changes that actually account for better performance on normal apps like games.

Should Apple move from 32-bit PPC to 64-bit PPC, Mac users should not expect the same kinds of performance gains that x86 software sees from the jump to x86-64. 64-bit PPC gives you larger integers and more memory, and that's about it. There are no extra registers, no cleaned up addressing scheme, etc.

Article here (about x86-64 mostly) (http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html)

748s
Mar 12, 2003, 06:53 AM
...........actually account for better performance on normal apps like games.........


round my way normal apps ain't no games:confused:

Bear
Mar 12, 2003, 07:00 AM
The reason there is no cleaned up addressing scheme is that the PowerPC got it right the first time.

As for any other differences betweenthe G4 and the 970, we would have to see the current specs of the 970 to make comparisons. Items that affect performance (besides being 64 bit): Number of instruction pipelines length of pipelines memory bus width bus speeds size (and speed) of the various caches. number of registers amount of physical memory the processor/system can address
I'm sure I left others off that list, and of course how much each of the above affects an application depends on each individual application.

caveman_uk
Mar 12, 2003, 07:22 AM
I agree, but a few people seem to think that somehow a 64bit 1.5GHz processor will be as fast as 32bit 3GHz processor. I've seen stuff to that effect in postings here. I posted this just to make the point that going to a 64bit processor isn't going to suddenly give Macs a massive performance increase. A scalable, well-designed processor and a chipset that can adequately support it just might ;)

kenohki
Mar 12, 2003, 08:42 AM
Originally posted by caveman_uk
I agree, but a few people seem to think that somehow a 64bit 1.5GHz processor will be as fast as 32bit 3GHz processor. I've seen stuff to that effect in postings here. I posted this just to make the point that going to a 64bit processor isn't going to suddenly give Macs a massive performance increase. A scalable, well-designed processor and a chipset that can adequately support it just might ;)

I think Apple's marketing department had a lot to do with that. Those nice diagrams of AltiVec on their site apply to SIMD but not to regular 64-bit integer or floating point operations.

*Multiplication is much easier than computer engineering. :D

RIP
Mar 12, 2003, 08:55 AM
the 970 will improve performance dramatically. Ars is probably correct that 64bit computing may not yield any performance improvements, but the 8-way superscaler will. My point; Ars is specifically talking about 64bit computing and what it brings to the table, and that is it. So for those of you that concluded from reading the pages at Ars that the 970 won't boost performance much compared to the G4, keep in mind that there are a lot of other changes not specific to 64bit computing that are included with the 970 that will be huge for the Mac community.

Nemesis
Mar 12, 2003, 10:09 AM
Originally posted by RIP
the 970 will improve performance dramatically. Ars is probably correct that 64bit computing may not yield any performance improvements, but the 8-way superscaler will. My point; Ars is specifically talking about 64bit computing and what it brings to the table, and that is it.

Agree. Generally, Ars Technica is not right regarding 970. First of all, 970 is designed to be most effective in 2, 4, 8, 16 way systems, which will DRAMATICALLY increase the performance of overall system.

970 is a non-standard 64-bit processor, so all the predictions are in vain. It cannot be compared to 64-bit AMDs because they follow different way of computing.

This is especially true when thinking about what will Apple do to enhance 64-bit computing. They will surely innovate something that will left us bewildered and amazed.

;)

ddtlm
Mar 12, 2003, 10:18 AM
Nemesis:

Generally, Ars Technica is not right regarding 970.
I guess it's no big deal to just outright reject the opinions of informed people when those opinions contracdict your pre-conceived expectations?

970 is a non-standard 64-bit processor, so all the predictions are in vain. It cannot be compared to 64-bit AMDs because they follow different way of computing.
This is hand-wavy nonsense. As a relation of one of the more established lines of 64-bit processors, the PPC-970 is very much more of a standard 64-bit processor than the Hammer is.

This is especially true when thinking about what will Apple do to enhance 64-bit computing. They will surely innovate something that will left us bewildered and amazed.
Meanwhile, on the planet Earth...

ddtlm
Mar 12, 2003, 10:21 AM
RIP:

the 970 will improve performance dramatically. Ars is probably correct that 64bit computing may not yield any performance improvements, but the 8-way superscaler will.
Exactly!

porovaara
Mar 12, 2003, 10:45 AM
Originally posted by Nemesis
[B]Agree. Generally, Ars Technica is not right regarding 970.

Uh huh, and how is exactly is Ars not right? I'm thinking you probably have no idea what the bulk of the articles on ars are even about.

Ars is completely and totally right with what is expressed in that article about the 970.

MacBandit
Mar 12, 2003, 10:55 AM
8-way superscaler doesn't do you any good unless they are using multiple processors. While it is a good chance that they will (IF THEY USE THE 970 AT ALL) it doesn't mean they will use more then 2 processors as they are doing now. Remember these chips still cost money and Apple needs to compete on price 1st.

szark
Mar 12, 2003, 10:58 AM
Originally posted by Bear
As for any other differences betweenthe G4 and the 970, we would have to see the current specs of the 970 to make comparisons.

Look to Hannibal's PPC 970 article (http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html) and IBM's PDF (http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/A1387A29AC1C2AE087256C5200611780/$file/PPC970_MPF2002.pdf) for the answers.

This article (x86-64) was very informative, and he is right in saying that we would not see any performance increase based on the move from 32 to 64 bits. We will see a performance improvement from better clock speed/scaling, faster FSB, and the improved core.

caveman_uk
Mar 12, 2003, 11:01 AM
I fear that some people are going to be horribly disappointed when the 970 comes out. It'll be better than the G4 - yes. Faster - yes. More scalable - yes. But to sayThis is especially true when thinking about what will Apple do to enhance 64-bit computing. They will surely innovate something that will left us bewildered and amazed. is being a little naive and optimistic. Apple are great designers but they can't turn water into wine...

Nemesis
Mar 12, 2003, 11:15 AM
Originally posted by porovaara
Uh huh, and how is exactly is Ars not right? I'm thinking you probably have no idea what the bulk of the articles on ars are even about.

Ars is completely and totally right with what is expressed in that article about the 970.

From the technnical point of view, they are right. I don't say they are wrong in that sense.

But the real world application of 970 is something different. That's what they didn't bother to talk about, because it is impossible to predict. Do we know how Apple will utilise 970? And do we know if Apple will use it at all?

For example, if Ford produces a V6 engine that is really nice but doesn't improve car speed drastically (from the point of view of general automotive industry), we are observing just the engine.

Of course that V6 will hardly beat V8 models, but it's the car and overall concept of a car that counts, not just engine.

Most of us buy car thinking how safe it is, what's the fuel consumption, is it affordable, does it looks nice, what's the standard equipment included, what's it's colour ... I think, the EXACT type of the engine and how it's built, which alloys it uses and does it produces 15 or 25 more kWs than a standard V6 (let's presume there is one) is totally unimportant for the majority of customers.

Tell me if I'm wrong. Producing a car that runs certain engine is what Apple is doing with 970 (let's presume they will use it). It's the car that matters! We'll be driving cars, sitting in a comfortable chair, with air-con, listenning to the nice music ... we won't be sitting with our asses on a overheated V6.

That's what I meant to say. Sorry for the confusion. ;)

Nemesis
Mar 12, 2003, 11:25 AM
Originally posted by caveman_uk
I fear that some people are going to be horribly disappointed when the 970 comes out. It'll be better than the G4 - yes. Faster - yes. More scalable - yes. But to say is being a little naive and optimistic. Apple are great designers but they can't turn water into wine...

Probably not :), but I think 970 wouldn't exist at all if it wasn't Apple that delivered specifications and design improvements to the existing IBM PPC family and asked IBM to invest R&D money into a new project (that will open new markets).

So, if that is true, let's say this: if they gave the specs and how 970 will be designed, they must have someting in their minds on how to utilize its performance:
1. to the max
2. in the future

MacBandit
Mar 12, 2003, 11:27 AM
There are too many assumptions going on here for any real logic to be derived.

If science worked like this we would have sailed off the edge of the earth a long time ago.

Nemesis
Mar 12, 2003, 11:36 AM
Originally posted by MacBandit
There are too many assumptions going on here for any real logic to be derived.

If science worked like this we would have sailed off the edge of the earth a long time ago.

You're right. All we have to play with is pure guessing.

But I'd say that's cool as well, because by exchanging ideas between ourselves, we're actually participating in a huge brainstorming process that can shed some light on the future of our beloved platform.

I say, let's play and let's be provocative, thinking out of the box. Someone will say that we are just imagining things, but let's observe it as well:

"Imagination will often carry us to worlds that never were. But without it we go nowhere."
-- Carl Sagan

MacBandit
Mar 12, 2003, 11:41 AM
Originally posted by Nemesis
You're right. All we have to play with is pure guessing.

But I'd say that's cool as well, because by exchanging ideas between ourselves, we're actually participating in a huge brainstorming process that can shed some light on the future of our beloved platform.

I say, let's play and let's be provocative, thinking out of the box. Someone will say that we are just imagining things, but let's observe it as well:

"Imagination will often carry us to worlds that never were. But without it we go nowhere."
-- Carl Sagan

That's fine but you need to keep it grounded in facts.

If we were to just make assumptions I would say right now that the PPC970 will you quad core and have 18 pipelines/core and each core would have it's own FSB.

Can you see the logic. What I said is not based in fact or reality at all just like most of the posts on the 970. Brainstorming is far more effective when you work from a solid base facts.

greenstork
Mar 12, 2003, 11:44 AM
Look I don't claim to know much about this subject but from what I have read it seems like even if Ars' article is true about 64-bit integer computations and actually processor speed, isn't the biggest speed improvement on the Macs going to come from the scaled up bus speed 533 MHz or more I don't know exactly but that is what I have read.

The bus is what is currently clogging the ability of the processor and more importantly, the ability of the DDR Ram to use both the uptick and downtick of the clock cycle as it was intended. The 166 MHz bus currently on Powermacs nullifies the DDR memory.

For all those supposed tech savvy people on this thread panning the anticipated speed increases of the 970 and saying it will disappoint, I would think the improved bus speed alone and full utillization of DDR will provide drastic speed improvements.

Just my two cents
Dave

MacBandit
Mar 12, 2003, 11:51 AM
Originally posted by greenstork
Look I don't claim to know much about this subject but from what I have read it seems like even if Ars' article is true about 64-bit integer computations and actually processor speed, isn't the biggest speed improvement on the Macs going to come from the scaled up bus speed 533 MHz or more I don't know exactly but that is what I have read.

The bus is what is currently clogging the ability of the processor and more importantly, the ability of the DDR Ram to use both the uptick and downtick of the clock cycle as it was intended. The 166 MHz bus currently on Powermacs nullifies the DDR memory.

For all those supposed tech savvy people on this thread panning the anticipated speed increases of the 970 and saying it will disappoint, I would think the improved bus speed alone and full utillization of DDR will provide drastic speed improvements.

Just my two cents
Dave

There will definitely be an increase in speed due to a faster FSB. Though it will not be as great as some would hope. On the X86 platforms the speed increase after several revisions was no more then about %15-%20. While that is a large increase it will not be that great on the Macs. There are a couple of reasons for this. The G4s are a much much more efficient in the way they hand data input/output. Also the G4 has a large L3 and L2 caches. Another things to consider is the architecture of the X86 platform requires the processor to process every last bit of data that goes through it. There is no DMA (direct memory access). DMA allows the Mac to move data from the hard drive to the ram to be accessed later without having to stream through the processor. DMA can access the DDR ram at full DDR speeds. Thusly the only speed increase will be a very minor one of normal cpu processes between the CPU and the system bus and not an increase in the rest of the computer processes.

Nemesis
Mar 12, 2003, 11:54 AM
Originally posted by MacBandit
That's fine but you need to keep it grounded in facts.

If we were to just make assumptions I would say right now that the PPC970 will you quad core and have 18 pipelines/core and each core would have it's own FSB.

Can you see the logic. What I said is not based in fact or reality at all just like most of the posts on the 970. Brainstorming is far more effective when you work from a solid base facts.

What about this:

* Apple will introduce Mac models that won't use hard-drives but 3D optical memory (already working at IBM - technology exists), which is WAYS FASTER than using regular HDs and magnetic memory.

* FSB will run on 900 MHz (next gen buses - this also exists).

Will that improve the performance of next gen computer running single core 970?

We are constantly forgetting simple fact: Apple is the company that introduced the real life usage of ones of the most innovative concepts in computer industry that no other company dared to use: GUI, Mouse, CD, USB, FW, ... to say the few.

I'm just provocative. But all this can be true.

Rincewind42
Mar 12, 2003, 12:08 PM
Originally posted by MacBandit
8-way superscaler doesn't do you any good unless they are using multiple processors. While it is a good chance that they will (IF THEY USE THE 970 AT ALL) it doesn't mean they will use more then 2 processors as they are doing now. Remember these chips still cost money and Apple needs to compete on price 1st.

8-way superscaler has nothing to do with how many processors are in the box, it is how many instructions that a single processor can have executing at any particular time.

Otherwise, the benchmarks on the 1.8 part put it at the level of a 3Ghz P4. Apple will probably drop 2 in a high end PowerMac and call it a day when these are released. How it will fare against a Hammer/Opteron I have no idea (I haven't seen benchmarks on those chips) but it will be fast, and it won't be because it is a 64-bit chip.

ddtlm
Mar 12, 2003, 03:13 PM
MacBandit:

8-way superscaler doesn't do you any good unless they are using multiple processors. While it is a good chance that they will (IF THEY USE THE 970 AT ALL) it doesn't mean they will use more then 2 processors as they are doing now. Remember these chips still cost money and Apple needs to compete on price 1st.
You don't know what superscalar means. I see that Rincewind42 told you just now, though.

There are too many assumptions going on here for any real logic to be derived.
I don't agree.

Nemesis:

You're right. All we have to play with is pure guessing.
Speak for yourself; some of us here know what we are talking about.

MacBandit:

If we were to just make assumptions I would say right now that the PPC970 will you quad core and have 18 pipelines/core and each core would have it's own FSB.
There is absolutely no mystery here. The PPC-970 is single core, the number and nature of its pipelines have been stated in that pdf from IBM's site as well as numerous articles and documents about the Power4, and we know that each processor has its own FSB.

There will definitely be an increase in speed due to a faster FSB. Though it will not be as great as some would hope. On the X86 platforms the speed increase after several revisions was no more then about %15-%20.
Compare a fast Athlon on a KT133A to the same chip on a nForce2 (you could do as high as a 2100+ or 2200+ on both I think). Big difference (on games and other relevant test). Since each new motherboard, each new bus speed, and each new processor makes only a small increase it is easy to be fooled and think that the FSB and memory are irrelevant, but in fact they are not. I know Aceshardware has done a few articles that illustrate parts of this.

The G4s are a much much more efficient in the way they hand data input/output.
Unsubstantiated claim.

Also the G4 has a large L3 and L2 caches.
Large L3 yes, but the L2 is actually undersized compared to the compedition which is all either at 512k or has at least newer chips there.

There is no DMA (direct memory access).
There is no DMA on what? PC's? PPC-970 systems?

jettredmont
Mar 12, 2003, 06:03 PM
Originally posted by MacBandit
8-way superscaler doesn't do you any good unless they are using multiple processors. While it is a good chance that they will (IF THEY USE THE 970 AT ALL) it doesn't mean they will use more then 2 processors as they are doing now. Remember these chips still cost money and Apple needs to compete on price 1st.

Also, note that 2 970s on a motherboard will cost significantly more to design and produce than 2 G4s on a motherboard as each 970 has its own FSB to the controller chip (and the controller chip hence has to manage multiple FSBs to CPUs instead of just one shared FSB ...)

Dual 970s will carry a significantly higher premium (either passed on to the consumer or eaten by Apple via lowered margins, yeah right) over single 970s than dual G4s carry over single G4s.

Nemesis
Mar 12, 2003, 06:08 PM
Originally posted by ddtlm
[b]MacBandit:


You don't know what superscalar means. I see that Rincewind42 told you just now, though.


I don't agree.

Nemesis:


Speak for yourself; some of us here know what we are talking about.



Oh, so, you work for Apple, right?

C'mon! Yes, you're talking techno stuff, but does it have anything with reality? Did Apple announce 970, dual 970, 64-bit Panther, or whatever....?

Nope.

So welcome to the rumor club, dude.

Steradian
Mar 12, 2003, 06:37 PM
Originally posted by caveman_uk
Apple are great designers but they can't turn water into wine...
and why not? ;)

Rincewind42
Mar 12, 2003, 07:16 PM
Originally posted by jettredmont
Also, note that 2 970s on a motherboard will cost significantly more to design and produce than 2 G4s on a motherboard as each 970 has its own FSB to the controller chip (and the controller chip hence has to manage multiple FSBs to CPUs instead of just one shared FSB ...)

Dual 970s will carry a significantly higher premium (either passed on to the consumer or eaten by Apple via lowered margins, yeah right) over single 970s than dual G4s carry over single G4s.

In all current dual cpu systems, the CPUs have to arbitrate access to the FSB anyway, so Dual 970s wouldn't be any different from Dual G4s. But if Apple wants to make 5% market share, they can't afford to produce these with a high premium.

buddha
Mar 12, 2003, 07:16 PM
Originally posted by caveman_uk
Apple are great designers but they can't turn water into wine...

True, but that little fact wouldn't stop Apple Advertising.

"Sick of carpet stains? Tired of lost productivity from hangovers? Well then you need Apple Wine (tm). With Apple Wine those problems will be a thing of the past." I figure you have Stevo doing a keynote you could get *at least* some people to believe they are actually getting drunk.

ddtlm
Mar 12, 2003, 07:25 PM
Nemesis:

C'mon! Yes, you're talking techno stuff, but does it have anything with reality? Did Apple announce 970, dual 970, 64-bit Panther, or whatever....?
Looking at my posts, it seems to me that I didn't even include Apple in my arguements. What I did discuss was the PPC-970, about which quite a bit is known.

Catfish_Man
Mar 12, 2003, 08:44 PM
Originally posted by Bear
The reason there is no cleaned up addressing scheme is that the PowerPC got it right the first time.

As for any other differences betweenthe G4 and the 970, we would have to see the current specs of the 970 to make comparisons. Items that affect performance (besides being 64 bit): Number of instruction pipelines length of pipelines memory bus width bus speeds size (and speed) of the various caches. number of registers amount of physical memory the processor/system can address
I'm sure I left others off that list, and of course how much each of the above affects an application depends on each individual application.

I'll add a few (and subtract a few):

out of order execution
number of registers (I assume you mean rename registers) hasn't been released to my knowledge, so I wouldn't put it on the list
Improved branch predictor
More instructions in flight
The bus width is actually the same (32*2 instead of 64*1)
Funky instruction groups (which make it so that instructions are tracked in groups of 5 instead of individually)
Higher fetch, dispatch, and completion throughput (8, 5, 5 instead of 4, 4, 4)
Old G4 (7400) style Altivec (the 745x's Altivec is slightly improved)

MacBandit
Mar 12, 2003, 09:12 PM
Originally posted by Catfish_Man
I'll add a few (and subtract a few):

out of order execution
number of registers (I assume you mean rename registers) hasn't been released to my knowledge, so I wouldn't put it on the list
Improved branch predictor
More instructions in flight
The bus width is actually the same (32*2 instead of 64*1)
Funky instruction groups (which make it so that instructions are tracked in groups of 5 instead of individually)
Higher fetch, dispatch, and completion throughput (8, 5, 5 instead of 4, 4, 4)
Old G4 (7400) style Altivec (the 745x's Altivec is slightly improved)


This is the type of stuff I have wanted to see. Not the crap just blowing off the Ars article.

My previous statement about multiple FSB and everything was done as an example of type of myths and assumptions uneducated people are making about the 970. They all think it's some sort of mythical holy grail and will banish all other chips to the darkness. I know the specs of the 970 and have read the white papers as many of you have. There just seems to be a lot of assumptions being made about Apples use of the chip and about the final chip that are unecessary. Also admit that I was wrong about Superscalar and appologize.

Even with all the benefits I doubt the overall speed increase over a G4 MHz for MHz will be much more then %25. A far cry from the %200 increase the whinners that are waiting to by a new Apple want (but never will buy one).

ddtlm
Mar 12, 2003, 10:13 PM
MacBandit:

My previous statement about multiple FSB and everything was done as an example of type of myths and assumptions uneducated people are making about the 970. They all think it's some sort of mythical holy grail and will banish all other chips to the darkness. I know the specs of the 970 and have read the white papers as many of you have.
Good.

Even with all the benefits I doubt the overall speed increase over a G4 MHz for MHz will be much more then %25. A far cry from the %200 increase the whinners that are waiting to by a new Apple want (but never will buy one).
Things that have been carefully tuned for the 7455 will probably not perform better per clock on a PPC-970 unless main memory bandwidth was an issue. Things that have not been carefully tuned, or that haven't been tuned at all, are going to be substantially faster per clock on a PPC-970 because of its hugely enhanced ability to execute instructions out of order, as well as its ability to execute more instructions per cycle. Other apps that were especially starved for memory bandwidth or that were hung up on the solitary double-precision FP unit of a 7455 will get a nice boost per clock as well.

insidedanshead
Mar 12, 2003, 10:23 PM
Originally posted by Nemesis
What about this:

...We are constantly forgetting simple fact: Apple is the company that introduced the real life usage of ones of the most innovative concepts in computer industry that no other company dared to use: GUI, Mouse, CD, USB, FW, ... to say the few....



In all honesty, I have tried to conceivabley see your side, however, with this statment you have lost all credibility my friend. Apple was DEFINITELY not the first to use USB especially when it's Intel's patent, and of COURSE they were the first to use Firewire they designed it and at the time it was the fastest peripheral connectivity solution, who wouldn't use it.. and CDs? are you kidding me? Apple hardware has been innovative, true, but Apple has by no means fronted these so called innovative concepts.... and one more thing...


... I think 970 wouldn't exist at all if it wasn't Apple that delivered specifications and design improvements to the existing IBM PPC family and asked IBM to invest R&D money into a new project (that will open new markets).

IBM isn't our big brother savior here. Granted apple probably passed along design improvements or urged IBM to make something better, HOWEVER, the 970 is derived from IBMs own Power4 architecture which is used in their own machines.. much like the 970 is designed to be. IBM doesn't have to deal with Apple at all... Apple is non other than a possible customer for the chip.

Just a few things I am sure about...

phampton81
Mar 13, 2003, 12:56 AM
With all this talk of the improvements by percentage I haven't seen anyone hear reference the benchmarks that IBM released, I dont know the numbers but it used SpecInt or something like that and the numbers for the 970 were like 3 times that of the G4, so that has to say something.

caveman_uk
Mar 13, 2003, 02:53 AM
Just guessing here but won't moving to 64-bit mean bigger programs - and mean we need more RAM, more HDD space and longer downloads....good job we'll have 64-bit address registers :rolleyes:

Rincewind42
Mar 13, 2003, 08:05 AM
Originally posted by caveman_uk
Just guessing here but won't moving to 64-bit mean bigger programs - and mean we need more RAM, more HDD space and longer downloads....good job we'll have 64-bit address registers :rolleyes:

No, it won't. All that you get with the 970 over the previous generation (as far as software size is concerned) is a larger pointer (slightly more memory and cache space - but to use 1K more memory would require 256 pointers, so it's not a big deal). Your programs won't get bigger (the instruction size is still 32-bits) they won't use more RAM or HD space, and your downloads won't get longer. And since at the introduction of the PPC970 most programs will still be 32-bit, you won't even see the larger pointers for a while.

locovaca
Mar 14, 2003, 09:46 AM
Originally posted by Rincewind42
No, it won't. All that you get with the 970 over the previous generation (as far as software size is concerned) is a larger pointer (slightly more memory and cache space - but to use 1K more memory would require 256 pointers, so it's not a big deal). Your programs won't get bigger (the instruction size is still 32-bits) they won't use more RAM or HD space, and your downloads won't get longer. And since at the introduction of the PPC970 most programs will still be 32-bit, you won't even see the larger pointers for a while.

Actually, programs are bigger. Constants are always as wide as the registers they go in to, so instructions will expand to accomodate the possibility of 64 bit constants. You can't have "dynamically" sized instructions- if it's a 64 bit program and you throw in a constant "1", it isn't just a binary 1, it's all zeroes and a 1 at the end.

ddtlm
Mar 14, 2003, 10:21 AM
locovaca:

Now admittably I'm a tad rusty with my assembly (where I dealt with memory I would call constants) but I distinctly remember being able to allocate space for constants in byte-sized (and up) chunks. Course that was x86, but I would expect PPC to be able to do it as well.

ktlx
Mar 14, 2003, 11:41 AM
Originally posted by locovaca
Actually, programs are bigger. Constants are always as wide as the registers they go in to, so instructions will expand to accomodate the possibility of 64 bit constants. You can't have "dynamically" sized instructions- if it's a 64 bit program and you throw in a constant "1", it isn't just a binary 1, it's all zeroes and a 1 at the end.

You cannot use this argument to say the program will get larger always. The most common development languages are based on C and the default size of C constants is int. As long as the compiler still assigns an int to be a 32-bit word, this argument will not hold. I don't think there has yet been a consensus on what size longs should be, but it seems that ints remain 32-bit integers even in a 64-bit world. Using long longs seems to be the only sure way of allocating a 64-bit number. Some want longs to stay as 32-bits because a ton of UNIX code out there assumes that sizeof(int) == sizeof(long).

Cappy
Mar 14, 2003, 12:49 PM
Originally posted by Nemesis
From the technnical point of view, they are right. I don't say they are wrong in that sense.

But the real world application of 970 is something different. That's what they didn't bother to talk about, because it is impossible to predict. Do we know how Apple will utilise 970? And do we know if Apple will use it at all?

For example, if Ford produces a V6 engine that is really nice but doesn't improve car speed drastically (from the point of view of general automotive industry), we are observing just the engine.

Of course that V6 will hardly beat V8 models, but it's the car and overall concept of a car that counts, not just engine.

Most of us buy car thinking how safe it is, what's the fuel consumption, is it affordable, does it looks nice, what's the standard equipment included, what's it's colour ... I think, the EXACT type of the engine and how it's built, which alloys it uses and does it produces 15 or 25 more kWs than a standard V6 (let's presume there is one) is totally unimportant for the majority of customers.

Tell me if I'm wrong. Producing a car that runs certain engine is what Apple is doing with 970 (let's presume they will use it). It's the car that matters! We'll be driving cars, sitting in a comfortable chair, with air-con, listenning to the nice music ... we won't be sitting with our asses on a overheated V6.

That's what I meant to say. Sorry for the confusion. ;)

Lets pretend for a moment that Apple does plan to use the 970. You're really comparing apples to oranges here in your analogy. There are multiple markets in the computer world that have a greater need for speed than what the multiple markets in the auto industry requires. This essentially blows your argument out of the water. Speed does matter for many of these markets. Sure the whole package is a factor but speed of the cpu is a much greater reason for most people to buy a system than a fast engine is in an automobile. Some really need the speed while some just want the speed. It really is a bigger deal than the auto market. One tidbit of fact to throw into this mix is that PowerMac sales have been flat. That tells a pretty big story that Apple needs something to happen in the speed dept.

I don't mean to make it sound as if I'm picking on you and others have refuted your posts accurately as well but I have to say that you need to remove the rose colored glasses and blinders off. There are known surgical procedures for this. ;)

wdodd
Mar 14, 2003, 02:06 PM
I understand that the PPC970 will be able to run existing 32-bit powerpc binaries by switching into a compatability mode. I also understand that this is dynamic in that you can alternately execute 64-bit code and 32-bit code. Mac OS X can be rewritten over time so that certain functions can be redone as 64-bit.

Is there a performance penalty on the 970 for executing 32-bit instructions when it really wants to be fed 64-bit instructions? I'm thinking back to the days when we switched to PowerPC and had to deal with fat binaries, compatability mode, context switching performance penalities, etc. That really held back the advantage of PPC for a time. Will we see the same thing as we go to the 970 (where there is no improvement and actually a slight penalty until everything is 80%+ 64-bit native)?

Titian
Mar 15, 2003, 09:18 AM
You are all assuming that Apple will use the PPC970.
Is it a fact that the next Macs will have this processor or is it only your dreams?

wdodd
Mar 15, 2003, 10:18 AM
Originally posted by Titian
You are all assuming that Apple will use the PPC970.
Is it a fact that the next Macs will have this processor or is it only your dreams?
Nothing definitive, we're all assuming that Apple will use it. The strongest evidence is that IBM took the Power4, scaled it down for desktop use and threw in Altivec-compatible features. Why else would they do that, but for the Macintosh platform?

ddtlm
Mar 15, 2003, 01:14 PM
Titian:

Why on earth wouldn't Apple use it? The darn thing is perfect. The biggest problem for them would probably be the system controller, but that hardly seems like a show stopper.

wdodd
Mar 15, 2003, 01:31 PM
Originally posted by ddtlm
Titian:
Why on earth wouldn't Apple use it?
I ran across this article (http://www.realworldtech.com/page.cfm?AID=RWT101502203725&p=2) which implies that Apple would have to rewrite portions of Mac OS X for it to work on the PPC970 and arbitrate for 32-bit apps so they can run unmodified on this hardware.

Makes me think that there might be significant performance problems trying to run 32-bit apps on this new chip. I'm flashing back to the introduction of the PowerPC when we all wanted to know when our favorite apps would get rewritten/recompiled for PPC.

ddtlm
Mar 15, 2003, 01:54 PM
wdodd:

I'm sure that Apple is up to that task. It's a whole lot easier than designing a new system controller, for example.

wdodd
Mar 15, 2003, 02:21 PM
Originally posted by ddtlm
I'm sure that Apple is up to that task. It's a whole lot easier than designing a new system controller, for example.
My question isn't so much, "can they do it?" as it is "can they do it in a reasonable time frame and achieve acceptable performance for 32-bit apps so it still feels like a leap forward for Mac users, particularly for professional users."

If Photoshop doesn't run any faster on a new tower because of context-switching or some similar penalty on running 32-bit apps (which we all experienced during the switch to PPC), then people will be disappointed in the PPC970. If it takes 64-bit native code to realize all the potential performance of the 970, then Apple has a much bigger problem on their hands. They need to convince everyone to rewrite/recompile for a new hardware architecture, just like they had to do with the switch to PPC and then OS X more recently.

Titian
Mar 15, 2003, 02:28 PM
Well, I suppose Apple is more in the ****** with the hardware it has chosen than we think so. And more Apple tries to get out of it more it gets deeper into it....
...while the others have nothing special but no problems...

ddtlm
Mar 15, 2003, 03:17 PM
wdodd:

My question isn't so much, "can they do it?" as it is "can they do it in a reasonable time frame and achieve acceptable performance for 32-bit apps so it still feels like a leap forward for Mac users, particularly for professional users."
There is nothing for you to worry about. There is no reason to suspect that Apple can't get the changes made on time (more complex things are done all the time by Linux kernel programmers), and performance of 32-bit apps is just not a problem because the PPC-970 can run those just great.

wdodd
Mar 15, 2003, 03:26 PM
Originally posted by ddtlm
...and performance of 32-bit apps is just not a problem because the PPC-970 can run those just great.
Do you have a source for this? The articles that I've read are pretty ambiguous when it comes to how much work is actually required to retool the OS to support 32-bit apps and if there is a performance penalty for switching between 32-bit and 64-bit code.

ddtlm
Mar 15, 2003, 03:37 PM
wdodd:

Well IBM has always claimed "native" 32-bit compatibility and the PPC instruction set has always been said to have been designed for seamless 32-bit and 64-bit versions. Since I've never programmed anything in PPC assembly I can't tell you if the instructions for 32-bit and 64-bit are in fact exactly the same such that there has to be a mode-swtich instruction for going between them, but even if that is the case that won't be a big deal since once a 32-bit app starts running it remains in 32-bit till its done, not jumping in and out all the time (so don't worry about switching).

I've also never worked on an OS kennel, but you can trust me, things more difficult than Apple's task are done every day by volunteers working on Linux.

scem0
Mar 15, 2003, 04:27 PM
Is it that hard to make 64 bit programs? If apple makes all its
iApps 64 bit, then that would be great! iTunes running faster,
along withall the other iApps. I think the move to 64 bit processors
is a great move.

ddtlm
Mar 15, 2003, 04:44 PM
scem0:

Stop the madness! Porting the iApps to 64-bit will not make them faster unless at the same time something that actually matters is changed. 64-bitness does not make most programs faster.

wdodd
Mar 15, 2003, 04:46 PM
Originally posted by ddtlm
Well IBM has always claimed "native" 32-bit compatibility and the PPC instruction set has always been said to have been designed for seamless 32-bit and 64-bit versions.

I've heard some similar things too. I just wonder about the implementation in the 970. Guess we'll have to wait to see.

Since I've never programmed anything in PPC assembly I can't tell you if the instructions for 32-bit and 64-bit are in fact exactly the same such that there has to be a mode-swtich instruction for going between them, but even if that is the case that won't be a big deal since once a 32-bit app starts running it remains in 32-bit till its done, not jumping in and out all the time (so don't worry about switching).

I don't really understand the implications either - I'm hoping somebody more knowledgeable than us will step in and provide a little education. The reason I'm on context switching is because this is what killed the first-generation PPC's performance. We're comparing emulation of another chip to 32-bit/64-bit modes, but context switching drove performance on PPC's down below what we were getting on older systems. It wasn't until more of the OS and more of the apps were native PPC that the context switching penalty subsided. It was brutal in the early days.

I'm hoping someone can set my fears to rest.

As for Linux, I don't believe there's much value in saying they do more difficult things every day. So does NASA, right? The devil is in the details and that's where Apple will stumble or succeed or trying to make this transition to a 64-bit hardware platform.

ddtlm
Mar 15, 2003, 04:53 PM
wdodd:

The reason I'm on context switching is because this is what killed the first-generation PPC's performance.
I can't imagine any sort of switching that could counterbalance the huge architectural improvements in a 970 vs a 7455. There could be penalties but I rest assured that they are going to be unimportant overall.

I'm hoping someone can set my fears to rest.
Surprisingly few people know the sort of thing you are seeking.

scem0
Mar 15, 2003, 04:53 PM
Originally posted by ddtlm
scem0:

Stop the madness! Porting the iApps to 64-bit will not make them faster unless at the same time something that actually matters is changed. 64-bitness does not make most programs faster.

What!?!?! A 64 bit application won't run faster on a 64 bit
processor than it would if it was 32 bit?

ddtlm
Mar 15, 2003, 04:56 PM
scem0:

Well yes a 64-bit application runs best on a 64-bit processor, but a 32-bit application may run as well as or better than a 64-bit application on a 64-bit processor.

scem0
Mar 15, 2003, 05:01 PM
Originally posted by ddtlm
scem0:

Well yes a 64-bit application runs best on a 64-bit processor, but a 32-bit application may run as well as or better than a 64-bit application on a 64-bit processor.

so what exactly is the benifit of a 64 bit processor? :confused:

ddtlm
Mar 15, 2003, 05:11 PM
scem0:

The biggest kicker, the thing that really matters, is the ability to have single programs use more memory than 4 gigs, which is the 32-bit limit (without ugly workarounds). In a five years, perhaps iMovie will handle 8 gig raw movie files on an run-of-the-mill PMac without swapping to disk. That would be nice.

scem0
Mar 15, 2003, 05:15 PM
I see. We will be using 64 bit processors eventually, why wait
to jump on the bandwagon?

ddtlm
Mar 15, 2003, 05:18 PM
scem0:

Exactly. It's easy to do, and here's a nice 64-bit processor, so go for it. Well, that and most people hear "64 bit" and think it's faster. :) I expect Apple to drum it up for all they are worth.

Macpoops
Mar 15, 2003, 05:57 PM
Intel has the mhz myth time for the Apple 64bit myth. The shoe is on the other foot now. muhhahahahaha

Rincewind42
Mar 16, 2003, 08:14 AM
When the heck did this thread come active again? =).

Originally posted by locovaca
Actually, programs are bigger. Constants are always as wide as the registers they go in to, so instructions will expand to accomodate the possibility of 64 bit constants. You can't have "dynamically" sized instructions- if it's a 64 bit program and you throw in a constant "1", it isn't just a binary 1, it's all zeroes and a 1 at the end.

Wrong. PowerPC instructions are 32-bits ALWAYS. They are never 16-bits or 64-bits or anything else. If the instruction isn't 32-bits wide, it is not a PowerPC instruction (as currently defined at least). The instructions do not expand to hold constants, that is an x86 (and any other processor that uses variable length instructions) concept. 64-bit constants simply cannot be represented in one instruction (and neither can 32-bit constants). Constants are stored as the datatype that they are defined as. If the data type is 1 byte, the constant is stored as 1 byte, regardless of the CPU architecture. Unless a constant is declared as 64-bits by the programmer, it will likely be stored with less. That is why there are multiple load instructions on the CPU to load data types of various sizes and types (for example: All PowerPC processors have 64-bit floating point registers, but floating point constants can be either 32-bits of 64-bits and the CPU automatically expands 32-bit floats if you use the 32-bit float load instruction. If you try to use the 64-bit float load instruction on a 32-bit float you are hosed and will read 4 random bytes of memory as part of your float).

Originally posted by ddtlm
locovaca:

Now admittably I'm a tad rusty with my assembly (where I dealt with memory I would call constants) but I distinctly remember being able to allocate space for constants in byte-sized (and up) chunks. Course that was x86, but I would expect PPC to be able to do it as well.

You can allocate constants in any type that your programming language will allow. For C, these include 8-, 16-, 32-, and 64-bit integers, 32- and 64-bit floating points, and (assuming vector extensions) 128-bit vector int/bool/floating point types and string types (either 8-bit, 16-bit, or 32-bit 'characters'). Unlike x86 assembly however, you cannot store these constants in instructions, and any integer constant longer than 16-bits must be loaded from memory or constructed with multiple instructions (two instructions for 32-bit constants, I think you can do it in 4 or 5 for 64-bit constants). Floating point and non-trivial vector constants still must come from memory however.

Originally posted by ktlx
You cannot use this argument to say the program will get larger always. The most common development languages are based on C and the default size of C constants is int. As long as the compiler still assigns an int to be a 32-bit word, this argument will not hold. I don't think there has yet been a consensus on what size longs should be, but it seems that ints remain 32-bit integers even in a 64-bit world. Using long longs seems to be the only sure way of allocating a 64-bit number. Some want longs to stay as 32-bits because a ton of UNIX code out there assumes that sizeof(int) == sizeof(long).

'long's should remain 32-bits, 'long long's will be the 64-bit data type. 'int' can't change unless 'long' changes.

Rincewind42
Mar 16, 2003, 09:04 AM
I wish I hadn't missed this one...

Originally posted by wdodd
I understand that the PPC970 will be able to run existing 32-bit powerpc binaries by switching into a compatability mode. I also understand that this is dynamic in that you can alternately execute 64-bit code and 32-bit code.

Is there a performance penalty on the 970 for executing 32-bit instructions when it really wants to be fed 64-bit instructions? I'm thinking back to the days when we switched to PowerPC and had to deal with fat binaries, compatability mode, context switching performance penalities, etc. That really held back the advantage of PPC for a time. Will we see the same thing as we go to the 970 (where there is no improvement and actually a slight penalty until everything is 80%+ 64-bit native)?

1. The compatability mode for running 32-bit PPC code on a 64-bit PPC processor is actually insanely simple. It disables all 64-bit integer instructions, and all architectural registers that are 32 - or 64-bit depending on the base architecture are presented to the program as 32-bit. When a 64-bit PPC implementation is running in 32-bit mode, all of these 32/64-bit registers have their top 32-bits cleared to zero (in hardware). The performance hit is infintesimal if existant.

2. There isn't a concept of 'being fed 64-bit instructions' and is a prime source of confusion. When we talk about 32-bit instructions on a PPC we typically mean instruction size. When we talk about 64-bit instructions on a PPC, we typically mean instructions that are only defined on 64-bit implementations of the PowerPC processor. Both standard PowerPC instructions and 64-bit implementation only PowerPC instructions are 32-bits wide. In fact simply due to the law of averages, a 64-bit PowerPC implementation will likely be running instructions that don't operate on 64-bit integer data types more often than those that do.

3. The context switch from 32-bit to 64-bit and back is mostly a matter of allowing the hardware to operate on 64-bit integer data types natively. Back when we first switched to the PowerPC processor the context switch performance hit was due to having to switch to and run in an emulator (of the 68K processor series). Since switching to PowerPC-32 is not an emulated state, the cost should be near none unless it is done very rapidly (which is not likely).

Originally posted by wdodd
I ran across this article (http://www.realworldtech.com/page.cfm?AID=RWT101502203725&p=2) which implies that Apple would have to rewrite portions of Mac OS X for it to work on the PPC970 and arbitrate for 32-bit apps so they can run unmodified on this hardware.

Makes me think that there might be significant performance problems trying to run 32-bit apps on this new chip.

1. The portion needing rewrite would be minimal. The entire requirement is that for a 32-bit OS to work, it would simply need to switch the CPU to 32-bit mode on startup (since it starts in 64-bit mode) and for the OS to have to deal with anything specific to PowerPC 64-bit implementations (of which nothing major comes to mind).

2. There are no performance issues on running 32-bit applications. Moving an application from 32-bit to 64-bit may be trivial or not depending on how the programmers wrote their code. In general it is not just a recompile, but it is also not a huge reoptimization effort either (beyond optimizations for the processor itself). The main problem in running 32-bit applications on a 64-bit architecture is what happens to the program when the register unexpectely goes beyond 32-bits of useful information. If the register is holding a pointer, then the program will crash, and otherwise the program may start producing bad data (which may lead to a crash later).

Originally posted by wdodd
My question isn't so much, "can they do it?" as it is "can they do it in a reasonable time frame and achieve acceptable performance for 32-bit apps so it still feels like a leap forward for Mac users, particularly for professional users."

If it takes 64-bit native code to realize all the potential performance of the 970, then Apple has a much bigger problem on their hands.

64-bit native code is only required to fully utilize the integer registers and to access memory beyond 4GB. Context switching will likely be a rather minor issue that I would expect Apple to currently place on the shoulders of programs that want to run in the 64-bit address space rather than those that want to run 32-bit.

Originally posted by wdodd
Do you have a source for this? The articles that I've read are pretty ambiguous when it comes to how much work is actually required to retool the OS to support 32-bit apps.

Nothing specific has been said on what needs to be done (publically). However, every source states that the required changes are miminal, and were designed that way. Therefore I'm inclined to think that this is something that IBM has thourougly documented and which they expect an engineer to be able to finish in a week.

Originally posted by ddtlm
wdodd:

Well IBM has always claimed "native" 32-bit compatibility and the PPC instruction set has always been said to have been designed for seamless 32-bit and 64-bit versions. Since I've never programmed anything in PPC assembly I can't tell you if the instructions for 32-bit and 64-bit are in fact exactly the same such that there has to be a mode-swtich instruction for going between them, but even if that is the case that won't be a big deal since once a 32-bit app starts running it remains in 32-bit till its done, not jumping in and out all the time (so don't worry about switching).

I've also never worked on an OS kennel, but you can trust me, things more difficult than Apple's task are done every day by volunteers working on Linux.

The PowerPC instruction set is (currently) logically divided into 3 sets. 1) The PowerPC Core Instruction set. 2) The PowerPC 64-bit Instruction Set. 3) Altivec Instruction Set. (1) is implemented in every PowerPC implementation and includes everything for operating on integers up to 32-bit and 32- and 64-bit floating point types. (2) extends the integer unit and some related architectural registers to 64-bits and includes operations on 64-bit integers. (3) is of course the Altivec unit implemented on the MPC74xx series and now on the IBM PPC970. And you are correct that a 32-bit application will likely run in 32-bit mode for all of it's life, however if there is even a single 64-bit application running on the system, then there will be context switches (since this is a preemptively tasked operating system). A context switch does not limit one to 64-bit instructions (and prevent one from using non-64-bit instructions). This would make the processor fairly useless. This is not MMX on an x86 ;).

And I have never worked in an OS kennel either, but I can imagine that the dogs in there can get pretty loud :D.

Originally posted by wdodd
I've heard some similar things too. I just wonder about the implementation in the 970. Guess we'll have to wait to see.

The reason I'm on context switching is because this is what killed the first-generation PPC's performance. We're comparing emulation of another chip to 32-bit/64-bit modes, but context switching drove performance on PPC's down below what we were getting on older systems. It wasn't until more of the OS and more of the apps were native PPC that the context switching penalty subsided. It was brutal in the early days.


And as you say, context switching killed us because we had to emulate another processor. This context switch will for the most part just lop off the top half of a few registers. Since the OS will be arbitrating the context switch, it shouldn't cause any problems in User code. OS code however will likely need to be aware of which environment it is running in and adapt. This will cause a few cycles here and there, but the advantage would be the ability to run 64-bit applications. How much of an advantage 64-bit applications will be in the near future will depend entirely on Apple and it's developers.

Originally posted by ddtlm
wdodd:

I can't imagine any sort of switching that could counterbalance the huge architectural improvements in a 970 vs a 7455. There could be penalties but I rest assured that they are going to be unimportant overall.

Surprisingly few people know the sort of thing you are seeking.

You are almost certainly right about this. The 970 is so much faster than the 7455 (going on SPEC scores alone) that context switches shouldn't slow it down at all. I wouldn't think that a 32/64 context switch would cost appreciably more than the standard task switch cost that occures when a pre-emptive tasking OS switches between tasks. I expect that IBM would be aware of this issue and would take steps to make sure that the cost is small, and I expect that Apple will take steps to make sure that their OS software runs at maximum performance.

And perhaps surprising few people who do know have been checking this message thread :).

ktlx
Mar 16, 2003, 11:11 AM
Originally posted by Rincewind42
Originally posted by ktlx
I don't think there has yet been a consensus on what size longs should be, but it seems that ints remain 32-bit integers even in a 64-bit world. Using long longs seems to be the only sure way of allocating a 64-bit number. Some want longs to stay as 32-bits because a ton of UNIX code out there assumes that sizeof(int) == sizeof(long).
'long's should remain 32-bits, 'long long's will be the 64-bit data type. 'int' can't change unless 'long' changes.

I think it will depend on what Apple decides but if I had to bet money, I would bet on longs being promoted to 64-bits. Solaris, Linux and the *BSDs have chosen to make longs 64-bits on 64-bit processors. Microsoft has chosen to keep longs 32-bits. I think Apple would rather stick with the UNIX guys to make porting easier.

Rincewind42
Mar 17, 2003, 09:21 AM
Originally posted by ktlx
I think it will depend on what Apple decides but if I had to bet money, I would bet on longs being promoted to 64-bits. Solaris, Linux and the *BSDs have chosen to make longs 64-bits on 64-bit processors. Microsoft has chosen to keep longs 32-bits. I think Apple would rather stick with the UNIX guys to make porting easier.

Good point, and while Darwin/MacOS X may be very 64-bit clean, I doubt that as many user applications are. But I doubt that this will be a big issue right now. While many think it is a shoe in, I seriously doubt that 10.3 will support 64-bit applications right off, even though it looks almost certain that Apple will use the 970. But then again, devs won't know for certain until WWDC, still 2 months away...

Edited to correct quote.