> Paolo Bonzini <pbonz...@redhat.com> writes: > > I guess that's the register windows. There's only so much you can do to > optimize them, and heavily recursive workloads (like Perl, or the RTL > half of GCC) pay a hefty price. > > Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64, > don't know about 32). > > x86 (32 and 64), arm, and ppc run with a slowdown of < 30 for my bogus > benchmark of GMP configure+make. > > With FreeBSD x86_64 I see a slowdown of just 13. (My reference system > runs FreeBSD, so running FreeBSD under qemu is only far.) > > My claimed slowdown factors are affected by kernel, libraries, and > unfortunately very much by gcc speed, which vary with target. > > If the sparc emulation speed is due to register windows, then why does > mips seem just as slow?
No idea. :) Of all the architectures you listed, MIPS is really the one that I have no inkling of... > If register windows shortage is a problem, it should be easy to pretend > to have lots of them, right? That can help to avoid trapping to the kernel. But you still have to spill the whole window to the stack on every call to a non-leaf function, which can be expensive even if you do it in the translated code. Paolo
