Stating the obvious that virtualization cannot be as fast
as running on raw HW is not the issue at all.

I am noticing 100% cpu utilization by VBox when I run
apps on guest, which when run on host, do not use more
than 15 - 20 % of cpu. So no matter what "optimizations"
are implemented in VBox, I and others are seeing cpu
utilization that is up to 5 times the utilization as when
app is run on host. On V-Tech cpu's this is likely not as
extreme.
So, I am finding that virtualization in general
is not very practical for these older non-VTech cpu's.

JD

Frank Mehnert wrote:
On Thursday 19 June 2008, Michael Thayer wrote:
JD wrote:
Since the context we are in on this list is
full HW platform virtualization,
each and every guest instruction is "interpreted"
on non-VT platforms, such as on my AMD64 3700+ cpu,
VBOX is  the 100% interpreter of 100% of the guest
OS and guest apps. If this is not the case, please
show evidence in source code of VBOx where it applies
to non-VT hardware.
This is getting a bit silly.  The code is in src/VBox/VMM if you are
interested in reading it.  You might want to do so before making claims
about what is in there or not.

And to second Michaels note: It would just not be possible to
achieve a performance similar to execution on bare metal with
interpretion. Think of pure Java interpreters which are dog slow.
You have _at least_ to recompile the interpreted code. Java does
JIT (just in time compilation). One small part of VBox does the
same where other optimizations don't apply (for instance guest
real mode). But neither will help you recompilation much: compare
the Qemu performance with the VirtualBox performance.

Kind regards,

Frank
------------------------------------------------------------------------

_______________________________________________
vbox-users mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-users
_______________________________________________
vbox-users mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-users

Reply via email to