VOGONS

Common searches


First post, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

As I said in a previous thread, from my point of view, the priority
in dosbox development is the speed, since I find it reliable enough.
I'm an average programmer and I would help improving this project,
even just play around with the code, but I really don't know where to
start. So, I would ask to the devs: what can I do? What can be improved?
which part of the code or emulation needs more work and study?
I think that the answers to these questions can push people into dosbox
development, don't you?

Edit: changed topic title to explain better the content.

Reply 1 of 19, by MiniMax

User metadata
Rank Moderator
Rank
Moderator

I am not a developer, but I would like to make just 2½ comments:

1. Unless one wants to make short-cuts in the emulation, e.g. pass whole sections of x86 code to the physical CPU (which will not work for users on PowerPC and SPARC and platforms!), the easiest way to speed up the emulations is to throw extra hardware at the problem.

2. That extra hardware can come in different forms. Either as has been the case for the last 25 years with CPU speeds steadily raising, or when multi-core CPU's become commonplace. DOSBox today is NOT well suited to take advantage of extra CPU cores, so rewriting the code to use an extra core, would be very advantagous. But it is not a given that it can be done, as the overhead incurred in synchronisation and communication between the thread can be substantial.

½: You could do something radical... Q: What is the most powerful CPU in a modern PC? A: The GPU, so if you want to do something truely amazing, rewrite the x86 emulation to run on the graphics card 😀

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 2 of 19, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Yes, GPUs on modern cards are very powerful, but these processors are not suited for serial processing. The most speed comes from the fact that graphics can be computed in parallel, that's why today's cards have 12 or even 16 pixel pipelines. Running a x86 program would be very slow since it could, at most, use 1 pipeline per thread. Right now the fastest processor that can run x86 code is x86 itself 😁
(better 1/2 point would be to use GPU for graphics processing, rather than cpu emulation 😜)

Reply 3 of 19, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Hmm... there is already OpenGL-HQ scaling... 😀

No seriously, some things are simply not parallelizable, so extra CPUs do not work there. In DosBox, sound could theoretically made multithreaded, then the two big CPU hogs (CPU emu and sound emu) could run on different physical CPUs. But that's not a trivial task, and as far as I can tell, it is nearly all that can be done. Most likely, it would make dosbox slower for single-cpu users.

Some really clever optimizing dynamic recompilation (for different CPUs, of course) could be the successor of the dynamic core, but that takes a lot of skill and even more time.

And finally: dosbox is fast enough if you know how to configure it. Don't bother to go past sampling rates of 22050, for example - there are very few games that use more. I've switched from 333MHz to 3700+ (amd64), and while it definitely _is_ a more pleasant experience, most of the CPU cycles are thrown at 48kHz sampling rate (why? simply because I don't need more dosbox cycles and my sound hardware is a bit weird) and OpenGL-HQ scaling with fullfixed 1280x800.

Reply 4 of 19, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

thanks for replying, guys!
besides these proposals, I was thinking about optimizing current code,
and then, eventually, implement some new techiques.

I really don't think this code couldn't be written better. There are surely
bottlenecks caused by some loops or little pieces of code here and there
that can be rewritten and let us gain some speed.

Now, only devs knows the code so good, so my proposal is that they could
write a list of all corrections and improvement that could be done to the
current code and make it available to the community so everyone that
wants to help only must read what's left to do.

Reply 5 of 19, by user222

User metadata
Rank Member
Rank
Member
MiniMax wrote:

You could do something radical... Q: What is the most powerful CPU in a modern PC? A: The GPU, so if you want to do something truely amazing, rewrite the x86 emulation to run on the graphics card 😀

The GPU can only do graphics processing.

Reply 6 of 19, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

One interesting point about speed improvement would be
fixing some things in the dynamic core. I don't have a
clue if this is possible or not though.
Example: in descent1 the paging system gets wrong
register contents (at least differing when using normal
or full core), causing a crash at some later point.

wd

Reply 7 of 19, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Yes, I'd love to see that fixed. I'll probably try to help out there after OpenGL-HQ is fully fixed, but for now, the dynamic core is a little mystery to me 😀

Reply 8 of 19, by 93143

User metadata
Rank Newbie
Rank
Newbie

>>The GPU can only do graphics processing.<<

It's a processor. It may be best at graphics processing, but in theory it can do any task that can be reduced to a computer program. For instance, there's currently some research being done into running high-quality raytrace reverbs for music production (ie: sound processing) using the GPU.

Reply 9 of 19, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

I think there are some design problems in dynamic core;
first of all the recompilation engine is unnecesarily heavy,
then there is no page caching system to avoid recompilation
of already-compiled, not-self-modified code pages.
I don't know if it's better to fix this core or make a new one,
maybe a virtualization solution like qemu, plex, vm-ware and vpc.

Reply 10 of 19, by Freddo

User metadata
Rank Oldbie
Rank
Oldbie
93143 wrote:

>>The GPU can only do graphics processing.<<

It's a processor. It may be best at graphics processing, but in theory it can do any task that can be reduced to a computer program. For instance, there's currently some research being done into running high-quality raytrace reverbs for music production (ie: sound processing) using the GPU.

Indeed. There's a finnish soundcard released during the second half of the 90s. It never got a big hit, but it got a "sound" processor on it, and an assembler and C compiler was released for it. It could do all sorts of things that weren't related to sound.

Reply 11 of 19, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie
93143 wrote:

>>The GPU can only do graphics processing.<<

It's a processor. It may be best at graphics processing, but in theory it can do any task that can be reduced to a computer program. For instance, there's currently some research being done into running high-quality raytrace reverbs for music production (ie: sound processing) using the GPU.

yup...I think there's a proof somewhere that current GPUs are Turing equivalent. That means that anything can run on the GPU...but anybody who ever worked with theoretical Turing machines knows how very inefficient they are. It could take hundreds of cycles just to calculate 1+1.

Reply 12 of 19, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Another story from the "do not expect this to happen for real" department: while planning OpenGL-HQ scaling, I thought about what else could be done with the GPU. Two things came to my mind: GUS and Adlib. GUS does mixing of multiple sound samples, with resmapling and interpolation. Funnily, this is just as if someone did multitexturing on 2d-textures. Adlib is a lot of sine/cosine in several combinations, also something which is (comparably) easy to do on the GPU.

But now for reality: An average graphics card is struggling to keep up with OpenGL-HQ scaling. If you own one of the most recent cards, you probably don't have to bother with CPU speed - it's more than likely you already have all the speed you want. There is no magic cookie in your PC that makes games go fast. There's no way around tweaking dosbox config for your individual PC. No one else than you can do that, and no amount of optimizing will free you from finding your personal optimum settings.

Reply 13 of 19, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

So, no news about the question of this topic?

I would ask to the devs: what can I do? What can be improved? which part of the code or emulation needs more work and study? I […]
Show full quote

I would ask to the devs: what can I do? What can be improved?
which part of the code or emulation needs more work and study?
I think that the answers to these questions can push people into dosbox
development, don't you?

I was thinking about optimizing current code, and then, eventually, implement some new techiques. […]
Show full quote

I was thinking about optimizing current code,
and then, eventually, implement some new techiques.

I really don't think this code couldn't be written better. There are surely
bottlenecks caused by some loops or little pieces of code here and there
that can be rewritten and let us gain some speed.

Now, only devs knows the code so good, so my proposal is that they could
write a list of all corrections and improvement that could be done to the
current code and make it available to the community so everyone that
wants to help only must read what's left to do.

Reply 14 of 19, by Guest

User metadata

Everything they can do they likely do. The thing to speed up things at this jucture is cpu virtualization, which by the way is hard and fucks up portability. Maybe a better option is keeping a map of traslated pieces of code in the dynamic core in case they are used again. I don't know if this is likely to happen in the 86x dos arch. Before you ask "why don't they do virtualization on the 86x side". I can think of a few causes.

Fist and foremost is portability. Nothing assures me that there is not a new super-duper new arch around the corner that is completely incompatible.

The second is division of work. It requires specialized knowlegde to create and maintain, at the cost of something that works everywhere.

Third, it won't be relevant in a few years. I'd much prefer having a bug free dynamic core in 5 years than a buggy virtualization one.

Reply 15 of 19, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

I totally agree. Let's leave virtualization.

Now, what can be done to speed up what we already have?
Where dynamic core is too cpu-expensive and needs to be
cleaned/optimized/redesigned?
Where we can improve video emulation, sound, interrupts,
hardware...?

Reply 16 of 19, by collector

User metadata
Rank l33t
Rank
l33t

If you want a virtualizer, there are already other solutions, like VirtualPC. VirtualPC is very well developed and you can even install Windows XP on it. However, emulation is the whole point of DOSBox. As good as VirtualPC is, your games can suffer from the same speed bugs that you get on any modern machine.

Last edited by collector on 2005-04-05, 04:04. Edited 1 time in total.

Reply 17 of 19, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Also agree on virtualization. What needs to be done: find out what code DOSBox spends the most time running over and over when running resource-demanding games/applications and optimize it - redesigning it from scratch if necessary

Reply 18 of 19, by Guest

User metadata

Dosbox needs to focus on the things it does best. Qemu for instance is lightning fast with or without virtualization (kqemu module) compared with any of the cpu cores of dosbox. Dosbox should use qemu and focus development on the dosbox version of dos and improve the sound support of qemu. Portability is less wide with qemu so the current cores can still be used for platforms not supported by Qemu.

Reply 19 of 19, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

Lately I was thinking about an hybrid static recopilation, which fully
recompiles executable code while switches to another core when
an out-of the-code jump is detected.
A static recompiler could also be written in C, to make it compatible
on all platforms, and still having a good execution speed.
There are several solutions and optimizations on the net, (look
staticrecompilers on yahoo) which not only make this way possible,
but even a fast and portable solution.