Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Quote from Arstechnica on 64bit processors
- Thread starter caveman_uk
- Start date
- Sort by reaction score
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.
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.
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).
MacBandit:
Good.
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.
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...
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...
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.
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 
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
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.
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.
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 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).
Re: Re: Re: Re: I think that
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.
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.
Performance in 32-bit mode?
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)?
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)?
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?
Is it a fact that the next Macs will have this processor or is it only your dreams?
I ran across this article 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.
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.
Well, I suppose Apple is more in the s**t 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...
...while the others have nothing special but no problems...
wdodd:
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.
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.