Mostly not. There is a little amount of parallelism in SDL, sound output runs in a different thread, and if you use the OpenGL-HQ addon, it uses a different thread as well, but the main portion of DOSBox is single-threaded.

There isn't much you can do about that - emulation can only run single-threaded, since you're emulating a single CPU. Theoretically, some of the emulated hardware might work in a second thread, but the gain wouldn't be all that much. If you are a programmer, go ahead -- I'd think it is worth a try to see how much you could gain, but it may turn out that multithreading doesn't help at all.

Sound output is another thread? Didn't know that 😀

Emulated hardware in separate threads would be neat. I wonder how much of a performance gain one would see if the graphic card emulation was in one thread, sound card emulation in one thread and maybe graphic output aswell?

No doubt it would require lots of work, though. 😖

Well, the sound thread thing is just SDL's way of dealing with the translation SDL-API <-> Native API. It has nothing to do with DOSBox's sound processing, and it doesn't chew up much CPU anyways.

Before kronuz's scaler optimizations, I suppose it would have been a nice thing to have the scalers run in a different thread/core. Perhaps it's still not a bad idea considering how common dual core is becoming. If/when accurate composite colour emulation is added into dosbox, perhaps there'd be reason enough to put that into another thread assuming it's not too difficult and that it really is easy enough to decouple it to get the benefit.

Putting video output into a separate thread is possible (I did it for the first version of OpenGL-HQ) but at a major pain. Messy, to say the least. A clean solution would probably mean a rewrite of some important parts of the video output code. Which means: I doubt anyone will tackle this soon.
Additionally, on fast machines (which dual-cores inevitably are) scalers aren't nearly as problematic as on slower singlecores. I own a fast singlecore and have no scaler-related performance problems. But as always: If you want to, go ahead and write it yourself 😉

a major pain

But basically, the video thread reads from the emulated memory and display, when cpu thread just write into that memory ?

I ask, because I will buy X2 in near future (mostly, for make -j3 😜). And extending dosbox for it would be a quite a task for me...

Hmm I mean if game draws a 640x480 screen (magic carpert?:P) all the time, it has to cost hasn't It ?

Pardon my ignorance, I didn't read to much dosbox code so far. Could you share your thoughts Moe ? As i see you know the topic..

Video performance is not a problem in DosBox. There really is no point in multithreading the video.

DosBox only renders the changes to the screen, it doesn't update the screen all of the time. As you can image this reduces the video processing hit significantly.

The big hit is DosBox's processor emulation.

On my XP 2800 I'm roughly equal to a P90/DX4-100 for Drhystone and a DX2-50 for Whetstone.

Most DOS games don't seem to use the FPU as much so it's not that big of a deal.

That's why I mentioned Magic Carpet, It's 3d so it updates all screen all the time.... I thought it's the video..

Yes it works on my sytem like it worked on 486.. The cpu emulation really drain so much power ? Wow I would never guess that (Magic Carpet runs on dynamic core)

If it's really the cpu - there is nothing to split 🙁

Efficient video output modes (like overlay, ddraw, opengl on nvidia and my d3d) draw pixels from cpu directly to the video memory. This is fast because of write combining, doesn't put stress on memory bandwidth (pixels are read from emulated framebuffer, processed by scalers then written directly into video memory) and the graphics card will do rest of the work. So in this section of video updates dosbox has improved a lot. There's still an optimization of skipping screen updates if nothing has changed that I include in my builds and that has been left out of official cvs (for some reason), but other than that video updates only take a minimal amount of cpu. The big hit is cpu emulation and from what I've heard the sound emulation. These could probably be split into seperate threads but it's a lot of work.

Two processors never have the same exact frequency. Using both processor for emulation would compromise the fluidity and constance of the emulation itself, not to talk about crappy sound.
I think it the taking advantage of dual core was alredy expreimented with MAME unsuccessfully.

CPU frequencies and bus latencies in dual-core/dual-proc situations aren't a problem, it's race conditions, data exchange, and deadlocks that are the bane of multiprocessing and cause so many crashes for the unwary, and sometimes cause degraded performance for single-cores.

The developers of Oblivion seem to have used multi-core CPUs well enough. They used a lib called OpenMP I believe.

Tests I've seen online show some significant benefits to having a dual core CPU, but the game is far more reliant on GPU speed. So, unless you run the game at a detail level where your GPU is not the limiting factor (unlikely), there's little benefit.

DOSBOX is all about CPU power though so I would think the potential would be there for it.