GP32 How to optimize an emulator ?


ConsoleTom

Member
Joined
Dec 4, 2003
Messages
106
Age
47
Location
Germany
Website
Visit site
Hi !

I am trying to get the Atari Lynx emulator faster rewriting important parts in assembly. (The routine that displays the video data works already).

Which parts of an emulator need the most cpu-power ? Rewriting which part could cause a speed up ?

Either i manage to make the emu faster or i've had good assembly practise ...

Greetings

Tobias
 
A good thing is to profile the emulator to see where the bottlenecks are..
I have a very very simple PC sample based profiler on my page
http://gp32.misantrop.org
What it does is to find out which function is currently beeing executed a couple of houndred times per second, and based on that information it can say which function probably took most processing time.

---
mithris
 
More to point.. it all depends.

CPU emulation is a limiting facotr in simpler machines, but in more complex emulations, its usually the interplay between processors and the complex rendering. ie: A SNES is not too difficult to emulate at all, but its rendering that makes it slow a hell.. simulating hardware in software is rough.

Handy on the other hand.. has always been slow; I never looked into why, but that sucker always chugged more than I thought it should.

My first guess, without lookiung at the code in a decade, is that he proabbyl calsl too many fucntions or sometyhing.. perhaps hes depending on a good aggressive c++ compilation, and the fucntion calls are going through vtables or something.. ie: Good C++ is just as fast as anythign else, but if hes depending on some ugly c++ features, it could get goofy. But hopefulyl hes got it simple and full of inlining and it shoudl run fast..

But even then.. a funciton call to handl eeach opcode isn't so bad.. that doesn't really slow it down that much on a gp32 (ie: CaSTaway uses a funcall per opcode, through either an array of funptrs or through a giant switch statement, and both are plenty fast).

So in the end its liekly the desing of the emu, or perhaps its threottling waiting for certain cpu state to occur in sync, or other artificial limits.. or maybe its jsut the fact theres 2 or 3 little cpus going on there, and they're using floating point or something..

So dig through the code; you can't just guess.. you need to understand the design (the intercpu stuff); is it float based a lot (kills performance on gp32 badly), or ...

(assuminfg you've already done the display, thats one main part ruled out; or maybe even with assembly its still slow to render :)

jeff
 
Back
Top