correct me if i'm wrong, but don't you care more about maximal throughput of the emulated target, rather than a statistical avertage? i.e. wouldn't you aim to meet the worst case? for instance, that mentioned dot product - indeed quite potent on the sh4 - how would you handle that at it maximal throughput when emulated on the cortex/neon? maybe you could 'catch up' on a statisctically-long sequence of dp's with neon's fused mads, but any short burst of dp's in the emulated flow would create 'lag bubbles' on the emulator, which may or may not be maskable with subsequent faster-than-realtime compensations.Exophase said:You shouldn't trust marketing numbers too easily. Multiple Dreamcast emulator authors claim that real games get as little as 0.5 instructions per clock. And the GFLOP rating is even more misleading because it is based solely on a 1 cycle dot product (that isn't accurate to full 32bit precision, and it has very few other vector instructions) - when it comes to normal floating point operations it's much more ordinary and cannot do more than one at a time under any circumstance. It's better at doing floating point dot products than Cortex-A8, but the flexibility of NEON goes a long way to make up for it. According to drkIIRaziel, Dreamcast games tended to not push more than 1 million polygons a second to begin with, so you don't exactly need all of that geometry transformation power in the CPU.