So a 2.4Ghz P4 then?..
Seriously though the P3 was quite a bit faster then a P4 clock for clock.
Ok, full interview from anonymous third party about Wii GPU.
- Thread starter DeadlyNinja
- Start date
So a 2.4Ghz P4 then?..
Seriously though the P3 was quite a bit faster then a P4 clock for clock.Running P3 optimized code. Which is gonna affect any high-latency/high-clocking designs, as they are sensitive to certain things low-clock CPUs aren't, and I disagree you should generalize that to overall performance.Teasy said:
Eg. - in a benchmark that flushes texture cache on every polygon, I'd expect GS to wipe the floor with Xenos, RSX, and WiiGPU combined - not just per clock, but in absolute terms. Should I conclude it's the fastest GPU overall?
I also have an issue with the whole "per-clock" performance thing when comparing over 3-4x Mhz gap. Memory subsystems don't scale linearly with clockspeed, and neither do execution pipelines - if they did, High-clocked CPUs would not be making design decisions they do in the first place.
On final note, can someone please point me to benchmarks(preferably not some synthetic nonsense) that demonstrate how a 750x series CPU is supposed to noticeably outperform a P3 - let alone by a factor of 2?
Here you go faf.
http://www.macintouch.com/g3p3.html
At worst you got 10% overall perfmance difference(that is using comparimg P3 SIMD optimised filter tests.
But 1.4GHZ is a bit too much.
http://www.macintouch.com/g3p3.html
At worst you got 10% overall perfmance difference(that is using comparimg P3 SIMD optimised filter tests.
But 1.4GHZ is a bit too much.
I thought the consensus (from developers) was that the Gekko@485MHz in GC was roughly equivalent to the 733MHz P3 in Xbox? Going by that, wouldn't a bone stock Gekko@729MHz be equivalent to a 1.1GHz P3? Since Broadway isn't just an overclocked Gekko (faster FSB, more cache etc), wouldn't it be safe to assume it's equivalent to a 1.4GHz P3 at most?
And how he can see it from the sdk?
No. Maybe a G4 class processor running some Altivec-enhanced code, but real world performance of the PPC750 rate it at perhaps 10-15% faster than the equivalent P3 at some tasks (but not all)
Apple used to hawk that line for years, but it never panned out.
Huh? So what is the equivalent P3 to a 485Mhz Gekko???
What does that have to do with what I said? I'm not talking about the good and bad points of different design decisions. I'm just saying that a lower clocked Pentium 3 often outperformed a much higher clocked original Pemtium 4 AFAIR (not sure about the newer P4's).. simple as that.
Last edited by a moderator:
See what?, the 16 stage TEV? Well I'd imagine it would tell you that in the SDK.
I still don't think that people properly appreciate what the 750CL accomplishes.
It is small (inexpensive), fits within a very tight power envelope, and performs reasonably.
If we compare to the P-III for instance, the smallest die size was 79mm2 (at 130nm) more than five times the size of the 750CL, and the TPD of the mobile part at 866 MHz was 19.5W. TPDs are not maximum power draw, so lets estimate this as a factor of 5 higher power draw than the 750CL at Wii clocks.
It is difficult to directly compare the two processors in terms of performance, partly because the 750 series is typically coupled to 100-133MHz SDRAM in public benchmarks, whereas the Wii CPU is coupled to quicker 1T-SRAM, and we don't know if it uses a custom bus - the memory controller is definitely a custom job, and other aspects of the chip/system might be somewhat modified. The 750CL does have some niceties in its extremely short pipeline, low latency single cycle FPMADD et cetera, but comparing performance across architectures is damn hard to do even when you have hands on access to the systems. Back of the envelope estimations only go so far.
But it should be obvious that the 750 CL is a vastly more efficient product, both in terms of power use and in terms of die size/cost, than the P-III. Lets not even start on the P4.
It should also be obvious that comparing it to for instance the Cell-BE at roughly 15 times the die size and power draw is pretty pointless other than possibly to marvel at that they serve the same purpose in competing products. "Better" or "worse" are useless descriptions unless you take into account the design goals, but since those goals are worlds apart, there is little common ground to base a comparison on.
The 750CL is nice. In a sympathetic environment perhaps even very nice, for what it is: A backwards compatible game console CPU with quite stringent cost and power draw constraints.
It is small (inexpensive), fits within a very tight power envelope, and performs reasonably.
If we compare to the P-III for instance, the smallest die size was 79mm2 (at 130nm) more than five times the size of the 750CL, and the TPD of the mobile part at 866 MHz was 19.5W. TPDs are not maximum power draw, so lets estimate this as a factor of 5 higher power draw than the 750CL at Wii clocks.
It is difficult to directly compare the two processors in terms of performance, partly because the 750 series is typically coupled to 100-133MHz SDRAM in public benchmarks, whereas the Wii CPU is coupled to quicker 1T-SRAM, and we don't know if it uses a custom bus - the memory controller is definitely a custom job, and other aspects of the chip/system might be somewhat modified. The 750CL does have some niceties in its extremely short pipeline, low latency single cycle FPMADD et cetera, but comparing performance across architectures is damn hard to do even when you have hands on access to the systems. Back of the envelope estimations only go so far.
But it should be obvious that the 750 CL is a vastly more efficient product, both in terms of power use and in terms of die size/cost, than the P-III. Lets not even start on the P4.
It should also be obvious that comparing it to for instance the Cell-BE at roughly 15 times the die size and power draw is pretty pointless other than possibly to marvel at that they serve the same purpose in competing products. "Better" or "worse" are useless descriptions unless you take into account the design goals, but since those goals are worlds apart, there is little common ground to base a comparison on.
The 750CL is nice. In a sympathetic environment perhaps even very nice, for what it is: A backwards compatible game console CPU with quite stringent cost and power draw constraints.
No.The more pipeline.That managed from .lib,and you have to go to assembly level to be able to see no of the pipelines
Maybe Nintendo should've gone with a 65nm Core Solo? Or some semi-custom 90 nm Dothan (i.e. a Celeron M but w/ speedstep enabled)? Either would surely destroy that special little 750CL, especially in performance per clock, if not power. But, it wouldn't have the backwards-compatibility-of-questionable-worth.
And of course, it wouldn't be as near-free as I bet 750CL most likely is. And that's what matters to Nintendo.
Last edited by a moderator:
That seems the issue, and one I wish Nintendo didn't base so much emphasis on. It's not like the GC was a runaway success and everyone wants to carry their existing GC libraries over! Heck, Nintendo were wanting new customers who'd never played a console before anyway. so why worry about BC with titles they've never heard of? I guess ultimately they wanted the same dev tools as they have now, and weren't willing to develop new tools for new hardware.
After hearing things like the Wii SDK is a copy-paste job of the Cube SDK, I think I'll agree 120% with you here. They want to save money across the board, and reusing previous development work is definitely one heck of an extra way to do that over simple hardware price.
I would imagine that the final documents list such details. No matter where this is managed it would seem pretty neccesary for a developer to know such basic info about the hardware he's working on.
Last edited by a moderator:
So the 2,5xGC holds true
I dont think that BC and BC of the SDK/tool would be enought, I mean they could have put a second core/CPU and keep all the BC and over time isntead of spending money in very specific optimizations that give litle gain they could just upgrade them slowly to the second core with much more gains and it shouldd be much easier (and with higer real world results) than doing it on the 360/PS3 given the amount of of gfx tasks that the CPU do in a TnL based console. Still giving significant increase in the qualitity of the tech (I imagine that having such a CPU almost only for gfx could easly give you D3 like shadows and a lot of others fx, while letting the other CPU much more free for things like AI, animation, physics and such).
I really think they did this to (at launch) save (or better said to steal) 10$ in each console.
I dont think that BC and BC of the SDK/tool would be enought, I mean they could have put a second core/CPU and keep all the BC and over time isntead of spending money in very specific optimizations that give litle gain they could just upgrade them slowly to the second core with much more gains and it shouldd be much easier (and with higer real world results) than doing it on the 360/PS3 given the amount of of gfx tasks that the CPU do in a TnL based console. Still giving significant increase in the qualitity of the tech (I imagine that having such a CPU almost only for gfx could easly give you D3 like shadows and a lot of others fx, while letting the other CPU much more free for things like AI, animation, physics and such).
I really think they did this to (at launch) save (or better said to steal) 10$ in each console.
Since the beginning, I've said that Nintendo should have made the case just a bit bigger (smaller than the original PS2) and ditch BC completely. Let's be honest, very few would mourn the loss of being able to play GC games.
I think you're missing the point. The PS3 is backwards compatible even down to PS1 games. You don't have to throw out BC to be able to achieve a certain performance goal. Nintendo could've easily kept BC and still made it more powerful than Wii turned out to be. We've talked about dual cores and whatnot many times before. Basically Nintendo wanted to keep the price of the hardware and R&D spending to a minium so it overclocked the GC and added a new form of control.