They didn't say it benefits from OoOE, they said any gains from OoOE on game code are a drop in the bucket since the vast majority of their workload is vector heavy. You tried to claim Frostbite would be limited by single thread performance. I gave you evidence that they've been using a jobs system to spread work across many cores since Bad Company 2.
I know how FB operates, thank you very much (for the umpteenth time - check the discussion a few pages ago). The FLOPS workloads that the engine can handle (as in viable throughput), are one thing. The engine's requirements - an entirely different thing. The entire argument started from:
DICE guy: We tried FB2 on the WiiU and it did not perform well.
forumite: It must be the CPU!
me: how come their well-scalable-with-CPUs engine did not perform well? If they say that did not perform well outside of the context of any game, then the engine's requirements alone (read: for doing
any meaningful workloads) must be pegged at something akin to 3x PPEs (which was a sarcastic statement on my part, I do not honestly expect that to be the case). And since the only advantage Xenon has over Espresso is (SIMD) FLOPS, that would mean the engine eats a significant amount of FLOPS for breakfast. Like how the software occlusion culling should eat FLOPS on the PS3, but that does not have to be the case on other platforms where the trisetup is on the average twice faster than on the RSX.
The Jaguar based CPU in PS4/Durango is a 100GFlop design that should work great in that framework. I only brought up the OoOE thing because you and others in this thread keep touting the OoOE advantage Espresso enjoys over Xenon and Cell as some kind of saving grace, but here we have an engineer at DICE saying explicitly how useless that advantage is in a real game.
Erm, 'real games' this gen are going to do a good portion of their FLOPS on the GPU. If 'real games' were so CPU-FLOPS-bound, we'd be seeing an evolution of the CELL in ps4 today, not 8 Jaguars and a GPU that blows them out of the water in FLOPS and which features dedicated CUs.
So a 15 GFlop processor not being good enough for an engine designed around 100 GFlop processors means a 100 GFlop processor is not good enough for an engine designed around 100 GFlops processors? The situations are not remotely comparable.
I've been aware what you're claiming since the beginning. Here's a hypothetical for you to perhaps help ypu understand what I've been asking you about single-threaded performance: do you expect FB to perform equally well compared to the 'baseline' 3x PPE if the setup contained 10 cores at ~1GHz each? How about 100 cores at 100MHz? If yes - why? If not, then how are you so sure FB would be fine on a bunch of Jaguars? We are still talking SIMD FP here, not even discussing GP code.