GP2X Dosbox Dynamic Recompiler V2


M-HT

Very Active Member
Joined
Nov 30, 2007
Messages
688
Location
Bratislava
Website
github.com
Hi,

I finished newer and faster version of my DOSBox dynamic recompiler backend.
Some changes to the recompiler framework were required, but the result is a nice speedup - at least according to my benchmark.

You can find the source and some instructions here.

The changes to the recompiler framework are not reflected in backends for other architectures (x86, x64, mips), so these become unusable.

Edit: Added slightly faster version that requires -mthumb-interwork switch when compiling dosbox
 
M-HT said:
Hi,

I finished newer and faster version of my DOSBox dynamic recompiler backend.
Some changes to the recompiler framework were required, but the result is a nice speedup - at least according to my benchmark.

You can find the source and some instructions here.

The changes to the recompiler framework are not reflected in backends for other architectures (x86, x64, mips), so these become unusable.

P.S. Slightly slower version, but with lot less changes to the recompiler framework can be made, should anyone be interested in such version.


Woohoo! how much faster? I will plug this in and build this up tonight and get it to the people.

Update: building! done, time to run home and try it!
 
Last edited by a moderator:
euro48k said:
any results?
Sure, ive tried a bit. Duke and DDave HM seem fullspeed. Keen4 seems to be smoother.
Maybe a hard number benchmark, for pinball fantasiesi used to get 25 fps normal core and now its around 35 fps.

Edit: I guess a good way to descibe it as 2 smaller updates in speed add up to a decent increase in speed compared to a normal core.
 
Last edited by a moderator:
Tobriand said:
Not bad at all... 10fps is nothing to be sneezed at. Must try this once it's out!
Just to clarify, Im not saying this latest update is giving 10 fps, but using the dynamic core does as compared to the normal core.

Im going to upload the new version. Although theres probally going to be a wait period.

Update: Im done uploading, just have to wait for approvals
 
Last edited by a moderator:
Pickle said:
Tobriand said:
Not bad at all... 10fps is nothing to be sneezed at. Must try this once it's out!
Just to clarify, Im not saying this latest update is giving 10 fps, but using the dynamic core does as compared to the normal core.

Im going to upload the new version. Although theres probally going to be a wait period.

Update: Im done uploading, just have to wait for approvals


Great, seems dosbox can have more optimization done!
On my list is writing a nice SDL frontend to dosbox/dosbox.conf/mapper.txt, I even started it, but work is killing me.
 
Last edited by a moderator:
Hitnrun said:
Pickle said:
Tobriand said:
Not bad at all... 10fps is nothing to be sneezed at. Must try this once it's out!
Just to clarify, Im not saying this latest update is giving 10 fps, but using the dynamic core does as compared to the normal core.

Im going to upload the new version. Although theres probally going to be a wait period.

Update: Im done uploading, just have to wait for approvals


Great, seems dosbox can have more optimization done!
On my list is writing a nice SDL frontend to dosbox/dosbox.conf/mapper.txt, I even started it, but work is killing me.



Oh that would be great........so so great...I think we would all appreciate the having a front end for dosbox, as its a pain to have to customize 3 to 4 files per game, and then not having something working correctly, and not being sure what it was.

Even if it is for just the mapper portion, every little bit helps.


DSR
 
Last edited by a moderator:
Pickle said:
Woohoo! how much faster? I will plug this in and build this up tonight and get it to the people.

Update: building! done, time to run home and try it!
I did some benchmarking with the various recompilers against the simple core and here are the results:

thumb instructions recompiler - new, faster version - ~49% speedup   <-- this is the version I posted 4.8.2008
thumb instructions recompiler - new, slower version- ~45% speedup   <-- this is the version I posted 29.7.2008
arm instructions recompiler - faster version - ~29% speedup
arm instructions recompiler - slower version - ~25% speedup
thumb instructions recompiler - old - ~9% speedup

Of course it doesn't mean, that games will run 45% (Edit: 49%) faster, but every little bit helps :)
 
Last edited by a moderator:
M-HT said:
Pickle said:
Woohoo! how much faster? I will plug this in and build this up tonight and get it to the people.

Update: building! done, time to run home and try it!
I did some benchmarking with the various recompilers against the simple core and here are the results:

thumb instructions recompiler - new - ~45% speedup <-- this is the version I posted yesterday
arm instructions recompiler - faster version - ~29% speedup
arm instructions recompiler - slower version - ~25% speedup
thumb instructions recompiler - old - ~9% speedup

Of course it doesn't mean, that games will run 45% faster, but every little bit helps :)


45% fits my benchmark for pinball fantasies of about 40%. Almost all of the games I run I can tell the difference.
Any plans to take it any further or is this the limit?
 
Last edited by a moderator:
Pickle said:
45% fits my benchmark for pinball fantasies of about 40%. Almost all of the games I run I can tell the difference.
Any plans to take it any further or is this the limit?
Well, this was the case of relatively simple changes leading to big speed boost.
At the moment I can't think of any more optimizations to the existing code, so I will call this the limit for now.

More speed could probably be gained by significant rewrite of the recompiler framework (or by writing new one), but the prospective speedup is not assured. For example - I applied the recompiler changes to the arm instructions backend and it actually became slower - the added overhead was bigger than the gained speedup.
 
Last edited by a moderator:
pupnik said:
Pickle, any interest in helping make some progress on Xbak?

Well its not actually my project its run by Guido, the project is hosted on sourceforge. I have been following the progress, currently the 3d engine is being built up. If he adds significant features I will release another version.
If your interested in helping him reverse engine the game contact him.
 
Last edited by a moderator:
pupnik said:
M-HT: Are you compiling all of dosbox for thumb, or interleaving thumb / 32-bit instructuns using the BX register?
http://www.codesourcery.com/archives/arm-gnu/msg00032.html


Neither of the switches mentioned in the link (-mthumb, -mthumb-interwork) are used at the moment.
I think that compiling whole dosbox to thumb instructions would be slower than the current state, but using -mthumb-interwork could bring some speed when I remove some overhead when calling arm functions from thumb code.

I will test it and post the results later.
 
Last edited by a moderator:
After using switch -mthumb-interwork and the relevant changes to the recompiler backand I gained 4 more percent in my benchmark, which means 49% speedup against the simple core.

I added the new version to the page mentioned in the first post.
 
M-HT said:
After using switch -mthumb-interwork and the relevant changes to the recompiler backand I gained 4 more percent in my benchmark, which means 49% speedup against the simple core.

I added the new version to the page mentioned in the first post.


nice, keep it up! This is really going to pay off with pandora, since we get an possible 3x performace gain.

Update: Ive added the new file and added -mthumb-interwork to my CC flags and I have the new version. I cant test it until later though.

Update 2: Ok ive tried and I cant say I see a difference, the fps counter is all over the place sometimes. I hope I compilied it correctly. It feels the same as the last version.
 
Last edited by a moderator:
I've been following this thread with some interest and have a couple questions - which I may have asked already but I'm happy to ask them again:

1). How much RAM does DOSBOX need to run? Although a simple question, I know there will be a complicated answer.
a). If you are emulating a smaller machine, say 640KB, how much RAM is required to run this?
B). Can DOSBOX be compiled to leave things out that are not required to decrease the size of executable? ie. If you don't want any fancy sound-card support for instance.
c). Basically is it possible to get DOSBOX running in 8MB of RAM?
 
Pickle said:
Update 2: Ok ive tried and I cant say I see a difference, the fps counter is all over the place sometimes. I hope I compilied it correctly. It feels the same as the last version.
4% speed increase (in my benchmark) is not so big, and in the game you are testing, the increase is probable less than that, so the difference may not be noticable.
Other thing is - you say, that the fps counter is all over the place sometimes, was it the same in the previous version or is it only in this version?


slaanesh said:
I've been following this thread with some interest and have a couple questions - which I may have asked already but I'm happy to ask them again:

1). How much RAM does DOSBOX need to run? Although a simple question, I know there will be a complicated answer.
a). If you are emulating a smaller machine, say 640KB, how much RAM is required to run this?
B). Can DOSBOX be compiled to leave things out that are not required to decrease the size of executable? ie. If you don't want any fancy sound-card support for instance.
c). Basically is it possible to get DOSBOX running in 8MB of RAM?
B) yes
c) I don't guarantee it, but it may be possible. Of course only without dynamic recompiler, because it requires lot of memory for translation cache.

These questions are probably better asked in the dosbox forum - you might get better answers there.
 
Last edited by a moderator:
Back
Top