Originally posted by Catfish_Man
Bull. The upcoming G4 (7457) is MUCH more technologically advanced than the 750fx. A better manufacturing process (8 layer .13 micron SOI vs. 6 layer .13 micron SOI), a better floating point unit, a roughly equal bus (166MHz MPX vs. 200 MHz 60x), better branch predicition (a requirement of the longer pipeline), L3 cache support, Altivec, the list goes on and on. To the best of my knowledge, no released G3 has EVER been faster than the G4s of its time in any but the most specialized of tasks (specifically, branch heavy integer code with a working set of less than 512k and more than 256k that isn't vectorizable). The G3 has been targetted at low power low speed applications (3.6 watts @ 800MHz). The 7457 is targetted at moderately low power high performance vector applications (~10 watts @ 1.3GHz). The G4 is crippled by its slow bus and short pipeline, but the G3 has a shorter pipeline and a less advanced bus.
That really sounds more like a list of disadvantages of the G4 to me. It needs a more complex process, with more layers, to be built (and still takes alot more die space than a G3, I'm not sure it even beats it on transistor density, I'll have to look it up).
It has a longer pipeline, so it's getting less done per cycle on alot of applications, and still not clockable significantly higher than G3s. And it's superior branch prediction is more a cost of this longer pipeline than a benefit, it would be unneeded on a G3 with it's short pipes.
The G3s in macs haven't been faster than their G4 mac brethren at any given time, but Apple is always using the fastest G4s they can get their hands on, not so for the G3.
And of course, as you mentioned, the G3 is less power hungry.
It has a better FPU, SIMD, SMP, and uses L3 cache. These are the G4's only real advantages, and are really more of a sign of what market was being aimed at than a sign of good design.
And let's break down your list of what you claim the G3 is as good or better at:
branch heavy integer code with a working set of less than 512k and more than 256k that isn't vectorizable
now some of this is redundant, so we can combine branch heavy and non-vectorizable and simplify to get:
integer code with a working set of less than 512k and more than 256k that isn't vectorizable
And of course, the G3 does comparably well to the G4 when hitting L2, so it'd be fair to say we can eliminate that lower limit of 256K to get:
integer code with a working set of less than 512k that isn't vectorizable
And of course, not all G4s come with L3 cache, witness the 12" PB, thus you can't guarantee that apps that need more than 512k of data won't have to hit main RAM on a G4 too, so let's remove that to get:
integer code that isn't vectorizable
And of course, only a *very* small amount of integer code is ever vectorized, so in practical applications, we can reduce that to:
integer code
Now wouldn't that have been easier to say?
