* Re: [Qemu-devel] full speed ?
2004-06-05 17:32 [Qemu-devel] full speed ? vaise
@ 2004-06-05 17:15 ` Hetz Ben Hamo
2004-06-05 18:22 ` Derek Fawcus
0 siblings, 1 reply; 3+ messages in thread
From: Hetz Ben Hamo @ 2004-06-05 17:15 UTC (permalink / raw)
To: qemu-devel
vaise@votreservice.com wrote:
> Well, on my Athlon 1800+, Qemu is too slow to be usable... So my question is :
> when Qemu does not do input/output,( for example calculus) , does it run at
> nearly full speed ? (on x86 on x86 of course). Will it be possible one day,
> or is it impossible due to its nature ?
That really depends...
Do you mean the graphics are too slow? you might want to try to enable
Remote Desktop connection and use either rdesktop or Windows native
client to connect and see the speed (if it's Windows XP)..
QEMU is still in development stages and as time goes on, it will be
faster. There are other plans to make it much faster (X86 on X86) but it
cannot be discussed it at the moment..
Thanks,
Hetz
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Qemu-devel] full speed ?
@ 2004-06-05 17:32 vaise
2004-06-05 17:15 ` Hetz Ben Hamo
0 siblings, 1 reply; 3+ messages in thread
From: vaise @ 2004-06-05 17:32 UTC (permalink / raw)
To: qemu-devel
Well, on my Athlon 1800+, Qemu is too slow to be usable... So my question is :
when Qemu does not do input/output,( for example calculus) , does it run at
nearly full speed ? (on x86 on x86 of course). Will it be possible one day,
or is it impossible due to its nature ?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] full speed ?
2004-06-05 17:15 ` Hetz Ben Hamo
@ 2004-06-05 18:22 ` Derek Fawcus
0 siblings, 0 replies; 3+ messages in thread
From: Derek Fawcus @ 2004-06-05 18:22 UTC (permalink / raw)
To: qemu-devel
On Sat, Jun 05, 2004 at 08:15:13PM +0300, Hetz Ben Hamo wrote:
> There are other plans to make it much faster (X86 on X86) but it
> cannot be discussed it at the moment..
Cannot be discussed? Well the obvious approach is to split the program
such that user mode code runs in a seperate process, then arrange for
that process to be controlled by the main process as a debugee.
Then the main process has complete control over the child, and can mess
with it (including memory mappings, cataching signals and syscalls) to
it's heart's content. This would allow user space to run at full speed,
while still having the system space running in the emulated dynamic
translation system.
It'd take some work to do this, and get the synchronisation working
correctly, but as I said it's the 'obvious' approach. It also has
the advantage that it would work well on x86-64.
DF
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-06-05 18:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-05 17:32 [Qemu-devel] full speed ? vaise
2004-06-05 17:15 ` Hetz Ben Hamo
2004-06-05 18:22 ` Derek Fawcus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).