Will the G6 be the G5 everybody's been waiting for?

2»

Comments

  • Reply 21 of 34
    mmicistmmicist Posts: 214member
    [quote]Originally posted by Programmer:

    <strong>Note that while the Athlon has 3 FPUs, it isn't 3 times faster than the G4's 1 FPU (even with a 50% clock rate advantage). And that 30% improvement in the Hammer apparently (I'm just going on what I've read about the Hammer in various articles) comes primarily from moving the memory controller on-chip. The actual core of the beast is not hugely different from the Athlon's core. If the same benefits show up when the G4 gets an on-chip memory controller and an 80% clock boost, then perhaps it doesn't actually need a second FPU. Of course the competition is a moving target, so a second one would be awfully nice...</strong><hr></blockquote>



    Small point, G4 actually has two FPUs, a simple (multiply/add/subtract) and a complex (divide/sqrt). I personally would like to see a second simple FPU, but this adds complexity to instruction issue / register porting and renaming / instruction retire etc., as I work very hard to avoid any of the complex (ie: very slow) instructions.



    Michael
  • Reply 22 of 34
    snoopysnoopy Posts: 1,901member
    Maybe a few things we already know can tell us more about what new processor is coming to the Mac.



    First, Apple has been buying companies that make high end video special effects applications, which require powerful systems to run well. They have also announced that the Windows versions will be discontinued soon, in several cases. What this tells me is that there will soon be a Macintosh that can do the job well, possibly better than anything else on the market. Apple has become less idealistic and more practical in their business decisions, so I believe these are signs that Apple wil have the hardware before long, not off in the distant future. A processor for this hardware must be very powerful, almost certainly 64 bit architecture.



    Second, Apple is working hard to get developers turned on to OS X and cranking out application. For the next year of two, Apple is not going to rock the boat, and make a big change in the processor. The only architecture that makes sense is a PPC with the ability to handle the Velocity Engine instructions. Likely this means either Motorola or IBM. There is nothing in the plans of these companies that shows this kind of processor coming out soon, if ever. Yet if our logic says it will be soon, then we must conclude that this will be a custom processor for Apple, which does not show up on any chart. A custom chip can be kept secret more easily too.



    Third, Apple has been hurt by problems and lack of commitment at Motorola. There has been nothing in the last couple years that shows things are going to be much better. We also know that management at Apple does not take kindly to this sort of thing. IBM, on the other hand, has a couple things going for it. First, it has some very powerful processors, the Power4 and its brothers. We also know that IBM seems willing to work with another company to develop a custom processor. Consider what they did for Nintendo and the Game Cube. Some time ago Apple hired processor design talent, and these people may have been working with a vendor for a new processor for quite a while. IBM would certainly be the most likely to follows through with its commitments, and this is very important for Apple's future. Some in this forum have question whether IBM would get enough out of the deal to agree to it. Well, I think they would. With Apple, IBM gets their high end technology into the mainstream, and I believe IBM sees this as a benefit for the long term.



    I hope what really happens is at least this good. I would be glad to be wrong if it turns out even better.
  • Reply 23 of 34
    woozlewoozle Posts: 64member
    Why is Altivec only 32bit - an explaination:



    In the rest of the cpu processing is done in 32 bit amounts. That means that if I want to add two numbers together both of those numbers will be 32 bits, and the answer will be 32 bits. This applies in general to the integer part of the processor.

    The fpu is a little different, it can work with 32 bit values, and 64 bit values. 32 bit floating point is lacking in precision, and so tends to be used in games and consumer applications. Scientific apps typically use 64 bit floating point ( this does not make the cpu a 64 bit cpu ).



    It has been observed that a lot of code does the same thing over and over and over to a big heap of data. 3D and video are good examples ( and were targeted by Intels MMX, and SSE, and AMD's 3DNow extensions ). Altivec is apparently a much better design ( maybe just being matched by SSE2 ). The way it works is to take 4 32bit numbers, and perform one operation upon all of them at the same time.

    So if I want to add a whole heap of numbers together I can do this:



    a1 + a2 = a3

    b1 + b2 = b3

    c1 + c2 = c3

    d1 + d2 = d3



    Because a1 - d1 are all in one of altivecs 128 bit registers, and a2 - d2 are in another, altivec will add them all together in one go ( programs have to be explicitly written to do this ).



    Altivec has a whole of variations on what it can, but the key point is that when it is working with floating point ( as it is when performing 3d or scientific code ) it can only use 32 bit numbers. This makes it less useful for scientific code ( or professional apps, like Maya ). In comparison, SSE2 can work with 64 bit values as well ( but it can only 2 in a register ).



    This has the unfortunate effect that if you want to use a Mac to do professional or scientific work, you need to fall back on the floating point unit, rather than altivec, and it aint no super computer then.
  • Reply 24 of 34
    programmerprogrammer Posts: 3,457member
    The whole "bit-ness" thing is very over-used, and has become less meaningful over time. The G4 is a 32-bit processor insofar as its integer registers are 32-bits, and therefore its address space is 32-bits.



    Other interesting "bit-nesses":



    - AltiVec unit has 128-bit registers

    - AltiVec registers can be used as 4 x 32-bit floats, 4 x 32-bit integers, 8 x 16-bit integers, and 16 x 8 bit integers.

    - Some internal busses on the G4 are 128-bits wide (in fact there might be some 256-bit busses, I can't remember)

    - The G4's MPX bus is 64-bits wide.

    - The FPU has 64-bit registers and thus can operate on 64-bit floating point numbers (called double-precision for historical reasons). It can also do 32-bit floating point operations in the same registers.

    - The integer units have 32-bit registers and thus operate on 32-bit integers and pointers. In "64-bit" PowerPCs these are 64-bit registers and they operate on 64-bit integers and pointers. The main improvement here is the ability to address 4 billion times as much memory.
  • Reply 25 of 34
    bartobarto Posts: 2,246member
    [quote]Originally posted by Programmer:

    <strong>I pointed out in another thread (causing you to sit in the corner for 10 minutes), the "G5" terminology is very loose.</strong><hr></blockquote>



    Yes, but this time I put it in context, damnit!



    Barto
  • Reply 26 of 34
    lemon bon bonlemon bon bon Posts: 2,383member
    "Well, I think they would. With Apple, IBM gets their high end technology into the mainstream, and I believe IBM sees this as a benefit for the long term."



    Then there's the publicity IBM would get out of Apple's product launches. IBM inside. Duh-dah-dur-dah.



    Programmer. When Altivec first came out. I thought, great...now we can use it to do an extra 4 fpu ops per second. Now we'll murder the opposition.



    I seem to remember reading somewhere that this isn't quite the case...ie you have to have certain types of operations or blocks of parallel code for Altivec to shine..?



    ie I'm guessing from Lighwave benchmarks etc, altivec can't be treated as an fpus...powerhouse?



    Lemon Bon Bon



    [ 07-29-2002: Message edited by: Lemon Bon Bon ]</p>
  • Reply 27 of 34
    bartobarto Posts: 2,246member
    Like Programmer said, AltiVec instructions are 128-bit vectors, and it can also handle 4x32-bit floating points.



    However, because those floating points are executed all at once, the results of one can't be required for the results of another.



    One thing I don't get is do you need to program you app so it can use the 4x32-bit FPU, or is it done automatically buy the CPU like the G3s 3 instructions per clock cycle (for example)?



    Barto
  • Reply 28 of 34
    rhumgodrhumgod Posts: 1,289member
    [quote]Originally posted by Agent Cooper:

    <strong>Any of you running 64 bit apps? Nope... I didn't think so..</strong><hr></blockquote>



    Kinda hard without a 64-bit OS!
  • Reply 29 of 34
    rhumgodrhumgod Posts: 1,289member
    [quote]Originally posted by snoopy:

    <strong>Maybe a few things we already know can tell us more about what new processor is coming to the Mac.</strong><hr></blockquote>



    Excellent points - they echo my feelings exactly!
  • Reply 30 of 34
    come on! whatever the archiatecture is Apple's still going to call it the G5 for marketing reasons.
  • Reply 31 of 34
    programmerprogrammer Posts: 3,457member
    [quote]Originally posted by Barto:

    <strong>Like Programmer said, AltiVec instructions are 128-bit vectors, and it can also handle 4x32-bit floating points.



    However, because those floating points are executed all at once, the results of one can't be required for the results of another.



    One thing I don't get is do you need to program you app so it can use the 4x32-bit FPU, or is it done automatically buy the CPU like the G3s 3 instructions per clock cycle (for example)?



    Barto</strong><hr></blockquote>



    The vector unit must be coded for specifically -- normal C/C++ don't have any way to describe operations on fixed-length vectors of floats or ints so Moto & Apple defined an extension to the language to allow programmers to write their AltiVec code without having to resort to assembly (but you still can if you don't trust the compiler). This is something I haven't seen any other CPU vendors do for their SIMD units (i.e. Intel, AMD, Sun, DEC). Its probably just as well because then we'd have a dozen different language extensions! The developer still needs to arrange his data in a way that it can be treated as vectors, and carefully write his code so that the vector unit can burn through it efficiently.



    There are one or two C/C++ compilers out there which try to "auto-vectorize" normal code. This means they look for places where the vector unit could be used automatically by the compiler. This isn't very effective though because C/C++ is a fairly low-level description of what the code is doing.



    The new Cg language from nVidia has vector primitives built in and is designed to process streams of data in parallel. This is one example of a language that could be used to generate vector code quite effectively. I really really really hope that somebody clues in and realized that a better compute language is needed to describe intensive calculations and the data that it operates on. If this is done then all sorts of hardware can be used much more effectively and easily, including AltiVec.



    One other problem is that many developers write their code so that it is memory intensive rather than CPU intensive. They get data from memory, do a little bit of work on it, then put it back or put it somewhere else... then they do all that again for the next little piece of work. And it isn't organized as one big block, it is scattered amongst other data. Once you understand the way this kind of hardware works, its not hard to change how you build the data & code so that the hardware can load it once, do a lot of work on it, and then put it back. This doesn't apply to everything, but it could be done a heck of a lot more often than it currently is... and it can be made to apply to most things which are processor intensive enough for the user to care.



    [ 07-29-2002: Message edited by: Programmer ]</p>
  • Reply 32 of 34
    amorphamorph Posts: 7,112member
    [quote]Originally posted by Programmer:

    <strong>

    - Some internal busses on the G4 are 128-bits wide (in fact there might be some 256-bit busses, I can't remember)</strong><hr></blockquote>



    The busses to on-die cache are 256 bit.
  • Reply 33 of 34
    snoopysnoopy Posts: 1,901member
    [quote]Originally posted by MaCommentary:

    <strong>come on! whatever the archiatecture is Apple's still going to call it the G5 for marketing reasons.</strong><hr></blockquote>



    Of course! I agree. Is someone disputing this? I'm not, and I don't remember reading any other ideas for naming the processor.
  • Reply 34 of 34
    I'm expecting the g4 to be used in only 1 or 2 more powermac revisions. Probably the one next month, and if there's a rev around january it may or may not use the g4.



    Steve Jobs has said that apple is waiting for a wider adoption of Os X. Which he expects to be around the beginning of next year. Then they'll have some real options, and everyone likes options



    So maybe we'll see a high end mac or xserve for video editing and such that uses a power4 derivative. New powermacs with G4+/G5 and imacs and such still using g4's. To me, this is a strategy that makes sense.



    There are also rumors of AMD as a supplier, this doesn't sound very likely though, considering that they seem to be really focusing on the clawhammer.



    Who knows what we'll get in the next year, that's half the fun of being an apple user.
Sign In or Register to comment.