I'm giving you a "big picture" example. You were implying IPC is the only measure of performance. I'm saying that IPS is a better measure, given that a low-IPC, high-clock CPU can outperform the opposite, if the clock is high enough.
Sure it can. But your assumption that Xenon's clock speed is sufficient to overcome its signofocantly lower IPC is clearly baseless.
What does Cell have to do with it? Please. Stop and read what I'm saying and think about it in context before you respond again. Cell was used as an example of another In-Order console processor that is capable of achieving very high IPS, despite the lack of OoO. You can't see the relevance?
Just because they are both IOE does not mean you can even remotely use one to guage the performance of the other.
Like I said, Cells performance comes mainly from its SPU's and LS and even then its performance in workloads that Xenon may not necessarily be handling in the 360 due to the split of work with Xenos. Im speaking of course about Cell being used as a crutch to RSX for graphics rendering.
Cells performance in the workloads we have seen it excelling in have pretty much zero baring on Xenons performance in its own workloads within the 360.
Physics is not branchy, otherwise GP CPUs would be the only thing capable of physics processing in real-time. Clearly this is not the case, since Cell, GPUs, and PhysX hardware all excel at physics calculations, none of which are known for their branching performance relative to GP CPUs.
Of course physics is branchy. One think hits another thing, are you saying the thing that was hit can only fly off in one direction? Of course not.
Modern GPU's (the ones touted for physics performance) can handle branching just fine and you have no evidence whatsoever that the Ageia PPU doesn't also have decent branching performance. Cell is the exception but partially makes up for that with huge number crunching power.
Huge number crunching power than Xenon lacks.
And run hotter, and be missing half the hardware threads of Xenon, and be more expensive to manufacture... Big picture, man.
I suggest you read my posts more carefully. I already said at the start of this line of conversation and at least once again since that im not suggesting Phenom could be used in place of Xenon. Time, cost and power all make that impossible. This is purely a theoretical discussion about peformance. One I didn't seriously expect anyone to actually argue in favour of Xenon for.
As for the hardware threads, they are still using the same resources. Doubling your threads does not double your resources. Is the P4 faster than a Core 2 because it has Hyperthreading? No. And the difference between a Phenom and a Xenon core is far greater than between a Core 2 and a P4 core.
In a closed architecture, software developers can count on a specific set of hardware. In this case, that's 6 thread concurrent execution. A tri-core phenom can only "emulate" this behavior with time slicing, and it's still not concurrent execution.
I'm suggesting that unless a tri-core Phenom were the original design target for XB360, software would not run as well on a redesigned 360 with a tri-core Phenom in place of Xenon. Seeing as how tri-core Phenoms are not yet available and XB360 has been out for almost 2 years, I'm going to say this is pointless mental masturbation.
Thats why I said originally that im not suggesting replacing Xenon today. I was speculating what would have been possible on the 360 if it originally used a PhenomX3 and I have zero doubt that its total potential performance would have been much greater. The lack of SMT not withstanding.
Based on the fact that Phenom is quite obviously a vastly superior architecture on a per core basis to Xenon. Based also on the fact that its 2 years more advanced and contains more than double the transistors. Based also on the fact that previous benchmarks and developer comments about Xenon have placed its performance below that of an AthlonX2 which is only 2 cores, each of which are slower than a Phenom core.
Need I go on?
Any assertion that Xenon would be faster on the other hand is speculation based on nothing.
You'd have to sample XB360 devs to get a meaningful answer to that question. XB360's design team targeted 6 threads and told devs to expect to utilize them. Any dev that doesn't code to this target is leaving performance on the table and not following XB360 software development guidelines.
No analysis of thread usage I have ever seen has claimed to be using 6 threads all of equal power maxing out the cores. Generally you are talking 2 or 3 primary threads and then 2 or 3 low performance helper threads which is probably exactly what Xenon allows. Its not like 2 threads = 2x the performance of 1 thread and thus using 6 threads in no way means you are accessing twice the power than if you only used one thread per core.
I'm not saying it'd be slower, what I am saying is that your idea, while interesting, is rather pointless when taken in context of reality, for all the reasons already mentioned.
I stated it as an interesting idea to begin with, not something to start an argument of Xenon vs Phenom which I agree is totally pointless given the inevitability of the conclusion.