[9fans] a quick comparison of qemu and xen

[9fans] a quick comparison of qemu and xen

[ron minnich]

this is qemu without kqemu, since I have had problems with that.

build a kernel, for ppc (bg/l really)

qemu: 4 minutes

59.86u 53.93s 233.60r 	 mk

xen 3
4.90u 5.06s 15.89r 	 mk

This is the identical tree, I tar'ed it up from the qemu instance, put
it in the xen instance, and typed
mk clean && mk
in each one.

that's a ratio of roughly 15:1. Yes, surprised me too. I will try to
get a qemu with a working kqemu to do a more fair comparison.

ron

Re: [9fans] a quick comparison of qemu and xen

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

IIRC, without kqemu, qemu does actual per-instruction emulation, even  
if running on the same platform.
15:1 is actually pretty impressive!

Paul

On 13-Feb-07, at 7:10 PM, ron minnich wrote:

> this is qemu without kqemu, since I have had problems with that.
>
> build a kernel, for ppc (bg/l really)
>
> qemu: 4 minutes
>
> 59.86u 53.93s 233.60r 	 mk
>
> xen 3
> 4.90u 5.06s 15.89r 	 mk
>
> This is the identical tree, I tar'ed it up from the qemu instance, put
> it in the xen instance, and typed
> mk clean && mk
> in each one.
>
> that's a ratio of roughly 15:1. Yes, surprised me too. I will try to
> get a qemu with a working kqemu to do a more fair comparison.
>
> ron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF0o71pJeHo/Fbu1wRArGwAJ9MpHZS+5WKdxCyOV5hQ/C0uuqqZwCgukdF
RZOM/oWSkvIj2IjIZxYCsNY=
=BlnQ
-----END PGP SIGNATURE-----

Re: [9fans] a quick comparison of qemu and xen

[ron minnich]

On 2/13/07, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> IIRC, without kqemu, qemu does actual per-instruction emulation, even
> if running on the same platform.

well, from my reading, that is not actually right. But my reading
might be wrong :-)

last time I had kqemu that worked right, the ratio was 4;1 in favor of xen.

ron

Re: [9fans] a quick comparison of qemu and xen

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Without kqemu, qemu uses dynamic translation/jit compilation to  
emulate the target architecture.  kqemu bypasses the jit engine and  
traps exceptions in the user code.  It does not use the hardware  
virtualization features, giving Xen the advantage there.

Paul

On 13-Feb-07, at 8:42 PM, ron minnich wrote:

> On 2/13/07, Paul Lalonde <plalonde@telus.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> IIRC, without kqemu, qemu does actual per-instruction emulation, even
>> if running on the same platform.
>
> well, from my reading, that is not actually right. But my reading
> might be wrong :-)
>
> last time I had kqemu that worked right, the ratio was 4;1 in favor  
> of xen.
>
> ron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF0rn5pJeHo/Fbu1wRAsNeAKCyNMU//eHHdjnk8gbFPOsi264S0wCfd/iw
ZxbealKr9+hGTbf/KBe3Hyc=
=yuXr
-----END PGP SIGNATURE-----

Re: [9fans] a quick comparison of qemu and xen

[ron minnich]

On 2/14/07, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Without kqemu, qemu uses dynamic translation/jit compilation to
> emulate the target architecture.

Right. So once you get a bit of jit compiled you're native.

>kqemu bypasses the jit engine and
> traps exceptions in the user code.  It does not use the hardware
> virtualization features, giving Xen the advantage there.

my measurements were on a box without hardware virtualization.

ron

Re: [9fans] a quick comparison of qemu and xen

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

But a quick perusal of the qemu papers shows that they only use a 16  
meg code cache, and flush the whole cache when full.  I'm betting  
compiling a kernel takes a few re-jittings.

That said, 15:1 is still a huge difference.

Paul

On 14-Feb-07, at 6:13 AM, ron minnich wrote:

> On 2/14/07, Paul Lalonde <plalonde@telus.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Without kqemu, qemu uses dynamic translation/jit compilation to
>> emulate the target architecture.
>
> Right. So once you get a bit of jit compiled you're native.
>
>> kqemu bypasses the jit engine and
>> traps exceptions in the user code.  It does not use the hardware
>> virtualization features, giving Xen the advantage there.
>
> my measurements were on a box without hardware virtualization.
>
> ron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF0xzqpJeHo/Fbu1wRAvwnAJ0Vw/VHE0dhNWhsT87oF5S86YfkhQCgzmkM
hmjWyh3rZKe69hFsef4gLpY=
=hRdy
-----END PGP SIGNATURE-----

Re: [9fans] a quick comparison of qemu and xen

[erik quanstrom]

i wouldn't think so.

; size 8c 8l rc mk
228248t + 35040d + 35960b = 299248	8c
65004t + 17368d + 69540b = 151912	8l
82972t + 10436d + 13528b = 106936	rc
82781t + 8344d + 32412b = 123537	mk

what am i forgetting that's 15.5MB of code?

- erik

Re: [9fans] a quick comparison of qemu and xen

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The flush after each separate pass is run on each file?  That would  
be my first guess.

But this is all theoretical - I've not stopped to actually measure  
the thing.

Paul

On 14-Feb-07, at 6:34 AM, erik quanstrom wrote:

> i wouldn't think so.
>
> ; size 8c 8l rc mk
> 228248t + 35040d + 35960b = 299248	8c
> 65004t + 17368d + 69540b = 151912	8l
> 82972t + 10436d + 13528b = 106936	rc
> 82781t + 8344d + 32412b = 123537	mk
>
> what am i forgetting that's 15.5MB of code?
>
> - erik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF0zoXpJeHo/Fbu1wRArUYAJ4vp8PhVRivuLVVWOUDgV69TJioDACg14lr
S00hhfxeFMgyXtF7GGl7iiA=
=05Ux
-----END PGP SIGNATURE-----