Speed goes like this:

Vmware (virtualize processor)
VPC (virtualize processor)
DosBox (emulate processor) Dynamic Recompile
QEMU (emulate processor) Dynamic Recompile
Bochs (emulate processor) No Dynamic?
DosEmu (emulate processor) No Dyanmic?

what does "virtualize processor" mean? Still seems like an emulation to me. I switched my core to dynamic as it seems to be what everyone uses, and I got some extra cpu cycles out of it 😀 Does the dynamic core adjust cpu usage according to what prog DosBox is running (like the core scales to simple on older games, scales up to normal/full on newer ones)? Sorry for all the questions, I'm new to emulators. I'll get an actual username for the forum. Thanks!

Okay, here an overview. Let's imagine we want to run a program written for x86 on a computer with x86 CPU.

If we have the same OS, we just run it. We already know that.
If we have a different OS, we may have to intercept OS calls and emulate them. That's what Wine does in Linux, or Cygwin does in Win32.

If the OS is radically different, we get problems: DOS allowed direct hardware access, something no modern OS can allow. It makes the system unstable. Back then, direct access was fastest, so it was used a lot.

Now what if we "wrap" the old program somehow? Run it, and whenever it tries to do something forbidden (like access hardware or use some advanced CPU features) we take over and emulate the forbidden action in a safe way. That's virtualization. That way, we can run one OS inside another, create simulated sound cards and similar stuff. There's one drawback: it needs support from the host OS, since creating such a "wrapper" is itself a forbidden action.

However, if we don't have a x86 CPU, we can't "just run" the program. It won't run on a different CPU. But there is exact documentation which shows what each x86 instruction does. We could read one instruction at a time, simulate the effects, then go to the next instruction. That's a full emulation.

Full emulation is slow. For each x86 instruction, you might need 10 or 20 host instruction. So what if we read the code up front, create equivalent host code from that (once!), and run that (as often as it is called)? We would perhaps get 2 host instructions or sometimes even just 1 host instruction per x86 instruction. Of course, all the hardware stuff must still be emulated, just like virtualization does. This is dynamic recompilation. It is slower than virtualization, since you have to "compile" code as it is executed, and you have to emulate more parts than virtualization, but in return, it runs unchanged on any OS.

There you go, I hope this understandable. I've simplified some things, to show the principle behind.

Anonymous wrote:

what does "virtualize processor" mean? Still seems like an emulation to me. I switched my core to dynamic as it seems to be what everyone uses, and I got some extra cpu cycles out of it 😀 Does the dynamic core adjust cpu usage according to what prog DosBox is running (like the core scales to simple on older games, scales up to normal/full on newer ones)? Sorry for all the questions, I'm new to emulators. I'll get an actual username for the forum. Thanks!

Virtualisation means that you run most of the code directly on the host CPU (the real CPU inside your computer).
The host CPU must be compatible with the emulated CPU.
You can use virtualisation to run Linux(x86 version) in an emulator that runs in Windows, or DOS in an emulator that runs in Linux.
You cannot use virtualisation to run MacOS in an emulator that runs in Windows, the CPUs are different (x86 and PowerPC).

Virtualisation is the fastest method, because the emulated code runs almost as fast as if it was run directly in the native OS installed on that computer. I say almost because, as `Moe` explained it, hardware calls must be emulated alongside the virtualisation, and it takes some CPU cycles. The virtualiser also eats some cycles. A virtualiser is very difficult to create, and, AFAIK, the virtualisation process has to be tied to the host OS. A virtualiser is not a very practiacal solution, it needs lots of work for a limited audience.

To run MacOSX in an emulator that runs in Windows, there are two solutions write an interpreter core, or a dynamic recompiler (dynarec) core. I'll explain the interpreter, then the dynarec.

An interpreter is in some way, a full software version of a CPU. Performance-wise, imagine the difference between 3d graphics that are hardware accelerated or rendered in software. Even though the analogy is only roughly accurate, it gives you an idea.

Interpretation is a very portable method. As long as there is a compiler for a given target, your emulator will run on it. (things are in fact more complicated, you must be careful to write portable code in the first place. Furthermore, in the cas of DOSBox, you need a SDL version for your target, since DOSBox relies on SDL)

A dynamic recompiler is an intermedate solution: it decrypts the code then compiles in order to run it natively on the host CPU. A dynarec must be written specifically for a given CPU (with parts in Assembly), so it is not portable. But you can write a PowerPC dynarec for an x86 host, or a MIPS dynarec for PowerPC, etc... And, of course, you can write an x86 dynarec for x86, that's what the dynamic core of DOSBox does.

A dynarec is most of the time faster than an interpreter, because the recompiled code runs natively on the host CPU. It is slower than a virtualiser, becuse recompiling the code takes more time than piping it directly to the host CPU.

Some programs will be slowerin the dynarec than in the interpreter, though, because there will be more thime spent on recompiling the code than on executing it. This is especially true in programs that are able to modify their own code (self modifying softawre).

I hope it clears things out 😀

> Speed goes like this:
> Vmware (virtualize processor)
> VPC (virtualize processor)
> DosBox (emulate processor) Dynamic Recompile
> QEMU (emulate processor) Dynamic Recompile
> Bochs (emulate processor) No Dynamic?
> DosEmu (emulate processor) No Dyanmic?
In what order have you sorted that?
- Fastest first? Hmm, vmware is not fastest, and DosBox
is hardly faster than Qemu. And wow, dosemu is slowest?
- Slowest first? Well, dosemu is probably fastest indeed,
but then Bochs is faster than vmware, which is a nonsense.

So what is the order of that list? Or is it that you just haven't
seen most of that emulators yourself? Especially, putting
vmware and dosemu at a different ends of the list, while
vmware is only a little slower than dosemu, makes me
confused.

> DosEmu (emulate processor) No Dyanmic?
Oh, just noticed... DosEmu does *not* emulate the
CPU, it uses the virtualization. Read, for example,
the posts by mirekluza at this forum (search for
Subject: Native x86 DOSBOX?), or read dosemu
documentation.
So my question about the sorting order is answered -
you have not seen these emulators indeed 🙁
I am using dosemu since 1998. Vmware was too slow
on my 486 CPU, but dosemu was quite fine. The only
emulator I've seen that is a bit faster sometimes, was
win4lin, but it is commercial so not counted.

We are talking about speed of Dos games under emulation and which emulator would run them the fastest, including all aspects of emulation, and OVERALL which emulator is the fastest.

Explain to me why wouldn't vmware be fastest?
Why isn't DosBox faster than Qemu? (I could be wrong but I doubt it)

It has been quite awhile since I've used DosEmu but it can't have changed that much. Anyone done any speed comparisons between DosEmu and Vmware?

I just listed the most common emulators for x86 Dos programs. Not trying to list every emulator in existence, shouldn't even have listed Bochs since it's too difficult for the average user to use.

> We are talking about speed of Dos games under emulation and which
Not only the games. I use dosemu for accessing the
serial ports from DOS progs, for IPX networking etc.
But this is an off-topic here, so lets assume we are
talking about the games only.

> emulator would run them the fastest, including all aspects of emulation,
> and OVERALL which emulator is the fastest.
Yes.

> Explain to me why wouldn't vmware be fastest?
It almost is. Why it is not (in general) faster than dosemu,
is because it is virtualizing ring0, which, because of the
specific Intel CPU ISA (Instruction Set Architecture), is not
virtualizable by nature. To virtualize it completely, you have
to use a lot of tricks, like the dynamic code prescanning,
breakpoint injection, using debug registers to trap the
accesses to the certain things, etc. This makes it pretty
much heavy-weight. That's what plex86 aimed to, but
never achieved.
Dosemu is much light-weight. It simply doesn't virtualize
ring0 at all, allowing only the user-mode code to run.
Thats why you can't run, say, WinXP under dosemu, but
you can run Win3.1 under it (with a few tricks).

> Why isn't DosBox faster than Qemu? (I could be wrong but I doubt it)
Sorry, no strong arguments here. They both has the dynamic
translation capabilities, so they should match each other.
It just looks to me that Qemu is a bit faster in most cases,
but that was not my point here.

> It has been quite awhile since I've used DosEmu but it
> can't have changed that much.
Dosemu was almost rewritten from scratch last couple of
years AFAIK, but the speed it still the same, since it still
uses the user-mode CPU virtualization. In your world,
where dosemu emulates the CPU, it may actually be slowest
of all the emulators, but lets get to the real world, where it is
fastest.

> Anyone done any speed comparisons between DosEmu and Vmware?
As I said already, on my former 486-based PC, vmware
was not an option at all. Only dosemu was able to provide
the reasonable speed.

> I just listed the most common emulators for x86 Dos
> programs. Not trying to list every emulator in existence,
I am not asking you to list more emulators. Lets just be
polite about other projects. Dosemu is underrated here
very frequently. I am also reading dosemu lists and I haven't
seen dosbox being underrated there.
I use both the emulators, they all are nice, and I can't
tolerate when either one being underrated by people who
actually never (really) used it. But right now dosemu does
much more for me than DosBox, because the games are
not the main thing I am using the emulators for. So perhaps
I am defending dosemu a bit more than I have to in that
message-board. Hope noone is being hurted:)

Well I have used DosEmu...just not for years. 😉

DosEmu is more general purpose, this site is game oriented which is why DosEmu isn't mentioned that much if at all. Nothing against DosEmu personally it's just that it's not the best solution for Dos gaming. .

> Nothing against DosEmu personally it's just that it's not the best solution
> for Dos gaming.
I agree with that only partially. I know only one real reason
why it is true, and you know what? It is actually because
under dosemu the *very* old games are simply too fast to
be playable!
AFAIK smoothly slowing down the CPU virtualization is not
that easy, and dosemu was developed with the speed being its
main goal, because it was started in 1992, when you couldn't
expect too much from the iron.
That's why I found the fact that you put dosemu at the end
of your speed list, as the horrible, untolerable underrating, so
I started that discussion. But I also like to discuss the
emulators in general, so just couldn't resist:)

>> Why isn't DosBox faster than Qemu? (I could be wrong but I doubt it)
> Sorry, no strong arguments here.
Ah, just a temporary memory leak on my side.
The reason here is that Qemu can (optionally) use the
hardware MMU (with the mmap() syscall), rather than
emulating it. MMU emulation is the rather expensive
thing, which Qemu is trying to avoid. Of course that puts
the limits to the guest os, since in this case it can't use
the memory areas that are used by the host OS and the
emulator itself (so that under Linux, for instance, you
wouldn't be able to use any address above 0xc0000000
(TASK_SIZE) under Qemu), but for DOS it is not a problem,
and that makes Qemu noticeably faster than DosBox.
I can't say too much about VPC, but I wouldn't be surprised
if also that emulator is placed wrongly, if all the other are.

Howdy, it's the guy who asked the original question. Thanks for all the clarification. So a dynamic core takes the prog (ie dos game), breaks it's down and recompiles the code for the OS the emulator is running in (win32 in my case)? So this recompilation takes place before you run a prog? I don't notice much of a delay when I start execution of games in DosBox. I would think that process would take a while. Or is the recompilation done on the fly as the core receives a new instruction that it hasn't converted to host OS instruction yet? I just wanna make sure I know the basic concept of how DosBox works, that way as I stay here longer I can absorb more knowledge in general 😀 Thanks!