On 6 May 2012 05:22, Anup Patel <anup at brainfault.org> wrote: > Also can you give example of a code sequence which is faster on model and > slower in real world. As far as I know ARM fast models are internally TLM > based models and If a TLM based model is emulating a timer chip of X clock > then it is quite precise X clock. Support for TLM does not require that the underlying model is cycle accurate (you can have 'loosely timed' behaviour). You might want to read the Fast Models documentation, which tries to be clear about what the models do and don't provide. In particular: http://infocenter.arm.com/help/topic/com.arm.doc.dui0423l/ch02s01s02.html "Fast models cannot be used to: * model cycle counting * model software performance " > Ofcourse CPU emulation and computation > power will be less compared to real world. To see this behaviour try to boot > linux on Fast model or QEMU and leave it for hours and come back see the > time elapsed, you will definitely see same amount of time elapsed as real > world. Nobody's arguing that the models are faster than hardware! Let's try a simple example with some numbers representing relative speeds: operation A: h/w: 1 ; model 5 operation B: h/w 3 ; model 30 Where we're comparing two equivalent code sequences "A A A A" vs "B". On hardware "B" will be faster. On the model the "A A A A" beats "B". (both sequences are slower on the model than on the hardware, obviously.) The point is that some operations will be vastly vastly slower on the model, and some operations merely moderately slower. Which of any two code sequences is fastest depends at least as much on whether it's using operations that are disproportionally worse on the model. A trivial example of this is VFP -- certainly QEMU has to do complex software emulation of the floating point ops to maintain bit-for-bit accuracy, which makes them very slow to the point where a hand-optimised-integer-assembly codec is likely to be faster on the model than a Neon/VFP-using codec, even though of course the Neon codec will be faster on hardware. [NB: this is itself a big simplification: model performance will depend on a lot of interacting things and is not purely a same-every-time slowdown per operation. Some operations effectively slow down what happens after them, for instance on QEMU if you do something that makes us flush our cache of translated code. And if for instance you have a periodic timer then the fact the model is generally slower means you execute proportionally more insns in the timer interrupt, so inefficiency or slowness in that code path has disproportionately more effect on overall speed than it does on hardware. There are other complications too...] > The results in the announcemnt are not baseless we have quite amount reasons > to believe Xvisor ARM will perform better than KVM ARM in real-world too. I'm not stating a position on whether KVM will be better or worse than Xvisor. I'm just pointing out that you can't base an argument on the faulty assumption that performance inside a model can tell you anything useful about performance on hardware. -- PMM
