Will Apple move to the POWER 5 instead of PPC?

24567

Comments

  • Reply 21 of 121
    Quote:

    Originally posted by slughead

    Altivec was vastly overrated anyway.



    Not true. It was vastly misunderstood by non-technical people and (as usually happens with such things) unrealistic expectations were developed. The technical community familiar with what AltiVec is realize that it is an important architectural feature for delivering maximum performance in computationally intense media algorithms. The x86 world still doesn't have a competitive SIMD solution, despite about 5 attempts at it. The way to get maximum performance in these kinds of algorithms on a G5 is to use AltiVec, just like that was true on the G4.



    Quote:

    I'd rather have 2x Dual Core 3ghz PPC-64 processors (yes I wrote that right) than 10 G4s



    Even better if those PPC-64 machines had AltiVec.



    You do realize that the POWER5 is clocked lower than the 970, right? It is designed for high reliability and massively multiprocessor applications. The POWER team's idea of "low end" starts about where Apple's high end maxes out.



    As for the 440 cores, they are individually rather weak and it is primarily through a vast number of them that IBM builds its supercomputers. The dual FPUs in the 970 are more capable than the dual FPUs in 440 (aside from the pseudo-vector capabilities, which the 970's AltiVec does a better job of anyways).



    The next processors Apple is likely to use will be a derivative of the 970. Some combination of the following will be added: multi-core, higher clock rates, lower power, SMT, AltiVec2, on-chip memory controller, larger cache(s), improved execution units, etc. Exactly what gets added to which variant only time will tell, but it will not be a POWER4/5/6 or a 440... nor should it be. The 97x series is the right choice for Apple.



    My own feeling is that next we'll see, as rumored, a refined process and slightly extended pipeline delivered in single and dual core variants with larger caches. The process will hopefully improve the clock rate slightly (at high end, probably not >3 GHz) and reduce power consumption (to enable notebooks). We can hope that the yield situation is under control. This will probably show up in the first few months of '05. After that I still think they'll introduce SMT into the 97x series. I don't think we'll see an onchip memory controller in the next 2 versions... more cores will probably come first.
  • Reply 22 of 121
    wizard69wizard69 Posts: 13,377member
    Quote:

    Originally posted by slughead

    Altivec was vastly overrated anyway.



    OH my are we a bit off base here. Altvec provides solutions to problems that could not be handled with other approaches. There is power in Altvec, but accessing that power is not always easy. When proper efforts are undertaken to exploit AltVec there is very little that can compete with it.



    Think about where Apple hardware has been installed for no other reason than to exploit AltVec. Naval submarines are one good example, you don't really think uncle Sam would stuff Xserves into a sub for the hell of it do you?



    The problems with Altvec revolve around getting people to adopt it and having the background to properly apply the facility. Altvec is not bad but then agian it is not used to its full potential.



    Quote:



    I'd rather have 2x Dual Core 3ghz PPC-64 processors (yes I wrote that right) than 10 G4s



    Well this is something that I can't totally disagree on. For the things I do at the moment, a multiprocessor would certain pay off just as well as Altvec, probally better. The problem is that there is a large body of software that still makes good use of AltVec and always will be. If you make use of that software Altvec is important to you.



    As to the G4's themselves I think you are vastly underating the processor. Given the proper interfaces to the real world it has very good potential. Stuff a bunch of these on one chip and things could get very interesting. Other than the fact that you would soon run out of address space.



    Dave
  • Reply 23 of 121
    mellomello Posts: 555member
    Quote:

    Originally posted by Programmer



    The next processors Apple is likely to use will be a derivative of the 970. Some combination of the following will be added: multi-core, higher clock rates, lower power, SMT, AltiVec2, on-chip memory controller, larger cache(s), improved execution units, etc. Exactly what gets added to which variant only time will tell, but it will not be a POWER4/5/6 or a 440... nor should it be. The 97x series is the right choice for Apple.




    Does anyone have any details about AltiVec2?
  • Reply 24 of 121
    Quote:

    Originally posted by mello

    Does anyone have any details about AltiVec2?



    yes. There's no such thing, nor are there any plans for any such thing.
  • Reply 25 of 121
    onlookeronlooker Posts: 5,252member
    It's not called Altivec anymore, and it has changed slightly. I think the similar function is an SIMD unit which should evolve eventually.
  • Reply 26 of 121
    Quote:

    Originally posted by onlooker

    It's not called Altivec anymore, and it has changed slightly. I think the similar function is an SIMD unit which should evolve eventually.



    AltiVec was just the Motorola brand name for it. IBM uses it in places, Apple generally calls it "Velocity engine" to consumers, and AltiVec to developers. The original code name, and the name that IBM uses instead of AltiVec at times, is VMX. The 970's implementation is slightly different but 99% compatible.



    It is a SIMD unit, I'm not sure what you mean by "the similar function". It will evolve if they introduce AltiVec2, meaning modifications to the instruction set and/or registers.
  • Reply 27 of 121
    onlookeronlooker Posts: 5,252member
    What I mean by the similar function is this is not the exact same Altivec that Motorola designed. I read a paper on it. It works the same, and still uses the same programming instructions that Altivec uses, but its not the exact same processor design.
  • Reply 28 of 121
    Quote:

    Originally posted by onlooker

    What I mean by the similar function is this is not the exact same Altivec that Motorola designed. I read a paper on it. It works the same, and still uses the same programming instructions that Altivec uses, but its not the exact same processor design.



    No kidding. The Motorola 7400 and 745x use different designs too. The 970 is a long pipeline machine with a 5-wide superscalar group issue scheme, so of course it is going to have a different AltiVec implementation. That is mostly irrelevant except to people doing code optimization.
  • Reply 29 of 121
    onlookeronlooker Posts: 5,252member
    Quote:

    Originally posted by Programmer

    No kidding. The Motorola 7400 and 745x use different designs too. The 970 is a long pipeline machine with a 5-wide superscalar group issue scheme, so of course it is going to have a different AltiVec implementation. That is mostly irrelevant except to people doing code optimization.



    No need to get snippy. You didn't seem to know what I meant, and your also the one that asked.
  • Reply 30 of 121
    amorphamorph Posts: 7,112member
    Quote:

    Originally posted by Programmer

    As for the 440 cores, they are individually rather weak and it is primarily through a vast number of them that IBM builds its supercomputers. The dual FPUs in the 970 are more capable than the dual FPUs in 440 (aside from the pseudo-vector capabilities, which the 970's AltiVec does a better job of anyways).



    Just to expand on this point: It's not at all new for a supercomputer to be built from hordes of individually low-power CPUs. During the reign of the G4, IBM was still shipping supercomputers built on 604s.



    Also, the kind of power provided by this sort of solution has to be harnessed explicitly (in other words, you have to write code that can be made massively parallel: broken down into lots of little chunks that can run independently and distributed—a design strategy that is totally alien to PC application development). Also, if the problem you're trying to solve can't be solved in a massively parallel way, then the vast majority of the theoretical power of the machine is squandered. The worst case for the above supercomputer would be a single-threaded app, which it would run on a single PPC440. That's a near-zero bang for the buck.



    Quote:

    The next processors Apple is likely to use will be a derivative of the 970. Some combination of the following will be added: multi-core, higher clock rates, lower power, SMT, AltiVec2, on-chip memory controller, larger cache(s), improved execution units, etc. Exactly what gets added to which variant only time will tell, but it will not be a POWER4/5/6 or a 440... nor should it be. The 97x series is the right choice for Apple.



    I don't know what "AltiVec2" is, except that it's an old, old rumor. But I can definitely imagine a beefed up version of the unit in the 970 which has more of the capabilities and efficiencies of the 7447's exemplary implementation.



    The rest of it sounds right. POWER4 is too hot. PPC440 is too cold. PPC970 is juuuuust right.
  • Reply 31 of 121
    Quote:

    Originally posted by Amorph

    I don't know what "AltiVec2" is, except that it's an old, old rumor. But I can definitely imagine a beefed up version of the unit in the 970 which has more of the capabilities and efficiencies of the 7447's exemplary implementation.



    Same here, by the way. I included it because everyone is always talking about it, but I think it would actually be a bad idea -- changing instruction sets always has a tendency to fragment the software base and developers. Few enough develop for AltiVec as it is, how many would use AV2? The capabilities of AV2 would have to be remarkably compelling to make it worthwhile, and I think most of the potential is possible with a new implementation behind the same instruction set. Discussion around AV2 is usually about doubling the register width or adding double precision support -- neither of which is compelling enough in my mind to justify it.
  • Reply 32 of 121
    amorphamorph Posts: 7,112member
    Quote:

    Originally posted by Programmer

    Same here, by the way. I included it because everyone is always talking about it, but I think it would actually be a bad idea -- changing instruction sets always has a tendency to fragment the software base and developers. Few enough develop for AltiVec as it is, how many would use AV2? The capabilities of AV2 would have to be remarkably compelling to make it worthwhile, and I think most of the potential is possible with a new implementation behind the same instruction set. Discussion around AV2 is usually about doubling the register width or adding double precision support -- neither of which is compelling enough in my mind to justify it.



    All of this is very true.



    Anyone pushing for "AltiVec 2" should realize that AltiVec adoption is (according to AV wizard hobold at Ars) just now starting to really catch on, nearly five years after introduction. Developers have seen enough of these flash-in-the-pan implementations to ignore them by default, for the most part. By now, it has shown that it has staying power, an installed base, and ubiquity in the Mac lineup (and elsewhere, since Mot and Freescale have been selling G4s into the embedded market for all these years as well). Having IBM on board probably doesn't hurt either. It would be insane for Apple or IBM or Freescale to introduce a new version right now, especially since they got it right the first time. All AltiVec has needed, since its introduction, is refinement. The basic design is brilliant.
  • Reply 33 of 121
    pbpb Posts: 4,248member
    Quote:

    Originally posted by Amorph

    All of this is very true.



    Anyone pushing for "AltiVec 2" should realize that AltiVec adoption is (according to AV wizard hobold at Ars) just now starting to really catch on, nearly five years after introduction.




    If I remember correctly, Tiger's developer tools will have an updated GCC version supporting automatic vectorization. If true, this will be the first attempt in those five years to offer to developers a compiler specially designed for the G4/G5 processors (I mean taking into account that there is a special unit sitting in there). Of course there was already a third party automatic vectorization tool, but not free with the OS .
  • Reply 34 of 121
    Quote:

    Originally posted by Amorph

    All of this is very true.



    Anyone pushing for "AltiVec 2" should realize that AltiVec adoption is (according to AV wizard hobold at Ars) just now starting to really catch on, nearly five years after introduction.




    Well, that is nice because an introduction of AltiVec 2 should really get the ball rolling then. Those that know how to do it, really have en advantadge (sp?) then, and those that dont know have a really good reason to catch up, since AV2 will probably be 2x as fast as AV1.
  • Reply 35 of 121
    Quote:

    Originally posted by Tomb of the Unknown

    yes. There's no such thing, nor are there any plans for any such thing.



    Any info to back this up, or pure speculation? There's a lot of good reasons to roll out a AV2 unit..
  • Reply 36 of 121
    wizard69wizard69 Posts: 13,377member
    Quote:

    Originally posted by Programmer

    Same here, by the way. I included it because everyone is always talking about it, but I think it would actually be a bad idea -- changing instruction sets always has a tendency to fragment the software base and developers.



    Well I would hope that AltVec2 or and improvements to the current hardware simply extend the instruciton set. It would be pretty stupid to change the instruction set, that is not haow most hardware developers work thankfully. Extending an instruction set is not a problem.



    As to the software base that always lags hardware development, nothing new there at all. Much of what may be a problem software wise can be taken care of by compilers and libraries. The people that code dierectly in AltVec assembly probally will be thankfull for any extension developed for AltVec2. That is if it exists.

    Quote:

    Few enough develop for AltiVec as it is, how many would use AV2?



    Well hopefully much of this would be taken care of either via the compiler or a library. But again the people that exploit such resources as AltVEc, at a low level, will very likely find good use for well thought out enhancements.

    Quote:

    The capabilities of AV2 would have to be remarkably compelling to make it worthwhile, and I think most of the potential is possible with a new implementation behind the same instruction set.



    All Altvec2 would need to be is an extension to AltVec to be worthwhile. Obviously those extensions would have to solve real problems in hardware for people. An improved implementation would be ideal, the very act of improvign the implementation though frees the designers to implement new instructions.



    Quote:

    Discussion around AV2 is usually about doubling the register width or adding double precision support -- neither of which is compelling enough in my mind to justify it.



    Either of these improvements can be compelling when the right problems are being solved on the hardware. There are certainly situations where wider register handling capabilities would be handy. Doubles may be harder to justify but that doesn't mean that somebody out there couldn't use the ability.



    Beyond that there are lots of things that the AltVec could be enhanced to do that would be beneficial to certian markets. Possibilities include true BCD math processing, addtional signal processing capabilities, and bit operations.

    Sure just about anything or function can be emulated in software. But that is true even for an eight bit processors. The trick to enhancing AltVec is to add those capabilities that can give a substantial payoff for developers in the future. The pay off should be much faster performance relative to the standard execution units or even AltVec itself. Ultimately that is it, if a few thousand gates can lead to speeding up certian algorithms substantially then lets go for it.



    Abviously we do not want anything done to AltVec to reduce its capabilities. On the other hand we do not want to see PPC stagnate, frezzing the instruction set could very well do that.



    Dave
  • Reply 37 of 121
    Quote:

    Originally posted by wizard69

    Well I would hope that AltVec2 or and improvements to the current hardware simply extend the instruciton set. It would be pretty stupid to change the instruction set, that is not haow most hardware developers work thankfully. Extending an instruction set is not a problem.



    That's what I meant... I figured that it went without saying that anything named "AltiVec 2" would be an extension (just like SSE3 is an extension of SSE2 which is an extension of SSE1). In any case, that still has the property of fragmenting the target platform. You can't write AV2 code and expect it to run everywhere, so now you need to write 2 versions if you support AV2 at all. SIMD instructions are notoriously hard for compilers to support (especially in C/C++) so developers need to hand-code for these things, even if it is in C/C++ using the intrinsics that AIM defined for AltiVec originally.





    Quote:

    Either of these improvements can be compelling when the right problems are being solved on the hardware. There are certainly situations where wider register handling capabilities would be handy. Doubles may be harder to justify but that doesn't mean that somebody out there couldn't use the ability.



    The problem is not that the extensions wouldn't be useful in some situations -- it is instead that are they useful often enough to justify the amount of hardware devoted to them. For a given transistor budget the CPU designer needs to evaluate the cost/benefits of each feature against the software most likely to run on it. If they added double precision support but nobody used it because it was only 1-10% of the Mac market for the first couple of years, then they missed the opportunity to speed up the processor in some other way (e.g. add another FPU, more rename registers, more cache, better integer execution units, etc) that would have sped up all of the existing and new software.



    Considering that AltiVec (as it stands) is still better than even the latest SIMD extensions in the x86 camp, the PowerPC is hardly "stagnating". Changing (i.e. extending) the instruction set isn't necessary to improve the processors, it is disruptive to developers, confuses consumers, and it distracts from the real issue of making the processors faster. Even worse, it adds to the legacy that needs to be supported in future PowerPCs... now they need to support even more instructions!





    Changing an instruction set is generally a really bad idea. Even the guys at Intel realize this even though they are among the worst offenders -- that may be why they realize it now. If you look at most code running on an x86 it typically doesn't use all the instructions that have been added over the decades. The last big transition was going 32-bit, and even that took years to happen despite huge realized benefits to doing so. Since then additions like MMX, SSE, SSE2, SSE3, and odds&ends like the cmov instruction have been added but the amount of software that uses these is very low. Even the problem of how to optimize code for the whole x86 family (including AMD & Cyrix flavors) is a huge issue -- despite using exactly the same instructions! Often different processors prefer dramatically different instruction sequences. Never mind trying to figure out which processor(s) support which instructions. And if you do choose to use a given set of extensions do you limit which hardware you run on, or ship multiple versions that use different combinations of extensions? That blows out your testing matrix. The new x86-64 that AMD defined just makes the problem worse, and isn't helped by Intel having a slightly different version of it. Its no wonder that developers aren't flocking to it despite several of the most dramatic improvements ever in the x86 ISA.



    The PowerPC guys have been very smart about minimizing changes to their ISA (including defining 64-bit right up front back in 93-94), and have tended to make it possible for one instruction stream to be reasonably optimal on all PowerPCs. The only major ISA change to PowerPC since it was introduced was the introduction of AltiVec, and they spent a great deal of effort getting it right the first time (unlike Intel who seems to have the philosophy of "keeping trying and we'll get it eventually"). Even the 970, a radical architecture departure from the previous PowerPCs, does a pretty good job of running existing code... and optimizing for the 970 doesn't overly cripple older chips. The same cannot be said even within Intel's lineup, never mind when you consider AMD's.
  • Reply 38 of 121
    Quote:

    Originally posted by T'hain Esh Kelch

    Any info to back this up, or pure speculation? There's a lot of good reasons to roll out a AV2 unit..



    Uhmmm, IBM and Apple have both said they have no plans for any major revision to Altivec. Not, we're looking at how to do this, it'd be tough. Not someday we might think about it. Just plain and simple: no.



    There is no such thing as Altivec 2. I mean, what would be the specs? Hmmm? You are all discussing this as if someone actually knew what it was you were talking about. What exactly are you talking about? You don't know, do you?



    That's because there is no such thing.



    It doesn't freaking exist, OK? It never did exist, and it's never going to exist. All it ever was was some wanker, who had no clue what he was talking about, speculating that it'd be nice if Altivec was twice as wide as it currently is, so obviously that will be Altivec 2.



    Unless you think paying four times as much per CPU is a good idea, you'd better give up the notion of seeing this "Altivec 2" (whatever the hell you think it is) any time this decade.
  • Reply 39 of 121
    Quote:

    Originally posted by Tomb of the Unknown

    Uhmmm, IBM and Apple have both said they have no plans for any major revision to Altivec. Not, we're looking at how to do this, it'd be tough. Not someday we might think about it. Just plain and simple: no.



    Steve also said no Photo iPod..
  • Reply 40 of 121
    amorphamorph Posts: 7,112member
    Quote:

    Originally posted by T'hain Esh Kelch

    Steve also said no Photo iPod..



    When? Where? And who cares, anyway, since there have never been any significant technical obstacles to putting a color screen on an iPod? (For the record, in his original introduction of the iPod, when he explained the name, he was quite clear that Apple had intentionally called it a "container" rather than narrowly restricting it to music. Music is just the "killer app.")



    Besides, this isn't something Steve has or hasn't said. This is something Motorola and IBM and Apple engineers have said. There is simply no need for a double-width AltiVec 2. There is no indication that it would faster, and in fact it might be slower. There is no technical analysis that I've seen where a 256-bit-wide AltiVec unit comes out ahead, especially not on a design like the 970 that already takes a hit from having to burn a cycle to synchronize all the copies it keeps of its register sets.



    The 970 has two full-featured, blazing fast 64-bit FPUs. Every PowerMac has two 970s. That's as close to an "AltiVec 2" as you're going to get for a very, very long time. And to answer a previous post of yours, it makes no sense to roll out a new version just as people are warming up to the first one. This isn't an accessory like an iPod. It's hardware that people have to spend long hours learning, and optimizing for, and investing in. In system software and hardware, change is bad for adoption. It's viewed as pulling the rug out from under your developers. Look at the last big run-up in video cards: New technology came so fast and so furious that hardly any games adopted any of it. So the GPU vendors would show these gorgeous demos, and then the next year's crop of games would look a lot like the previous years', with higher framerates a few minor enhancements. It's only now that a common set of functions have been defined in OpenGL and DirectX, and implemented broadly, that we're seeing advanced support for programmable textures and other capabilities that had been neglected for the previous three or four years. Or, look at all the attempts at vector engines on the x86 side, which have simply resulted in hardly any of them being supported at all (most of the support consists of using SSE as an FPU, since the x86's onboard FPU sucks).



    Apple, IBM and Motorola did AltiVec once. They got it right the first time. I have seen exactly zero pressure from those people who actually use it for a version 2.0. For comparison, the PowerPC spec, approved in 1994, is also still on version 1. It's only ever been tweaked here and there, and somehow that's not a problem.
Sign In or Register to comment.