you cant know from the disk how the game would run.
this is best to see with condition jumps.
you cant know where the next jump would take you, so you cant know what instructions will come after it until you calculated the condition for jump.
thats why dolphin only recompiles until next jump, then executes code, then takes jump, starts to recompile what comes after jump... and so on.
(just explained simple, if you need more info, i think ector wrote this part)
theoretically(!!!) it would be possible to calculate 2 upcoming paths on a 3rd and 4th core and depending on what jump is taken, this path is chosen and allready recompiled.
But i have really NO idea if this would make it faster at all, as the usual parts are like ~50 instructions till next jump, as far as ive seen in debugger.
So synchro between cpu-cores must be in low nano-second time which is really fast.
Thats why i doubt its possible.
I'm not saying to pre-process the entire game as it is, i'm well aware of all the conditions there are,
but you can pre-process all the code between the jumps (like it is now) ahead of time, still do the same compares needed and jump to the new section.
this isn't as trivial as i might make it sound, you still need to remap all the jumps so they will go to the correct addresses of the "new" code. but still, it might be possible, and if so, it will definitely speed things up a lot.
i give you a little example :
(hope its right, as i have no idea of ppc asm instructions
but the intention should be clear)
li r9,5
bne far_position
...
lots of code
...
far_position:
li r4,r9
how would you pre-recompile that ?
you need to write the 5 to a register, lets say eax : mov eax,5
now you go ahead in code and few thousand lines of code later you come to this "far_position" and have to write the stuff from r9 into r4.
but how do you know NOW that r9 is stored in eax at execution time ?
You cannot know that, you used eax in this thousand of lines hundreds of times.
R9 could be anywhere.
So if you pre-recompile you would have to take care of any R-Register from PPC and store it allways at the same place, so that you later in execution know where it is.
That only leaves memory -> slow as hell.
this is just one problem that came into my mind, but i bet there are many more.
So, basically the problem is that ppc has more registers than x86?
Do you really thing it would be slower to address the RAM than to re-compile the current section?
What does dolphin do right now if a single section uses more registers than available?
i really should start going over the code...
Quote:So, basically the problem is that ppc has more registers than x86?
for my example, yes. for other examples there might be other problems.
Quote:Do you really thing it would be slower to address the RAM than to re-compile the current section?
you would have to access ram for nearly ALL instructions, for some of them twice.
no doubt that is much slower then recompile it.
the recompile isn't that hard in time.
Think about wii running at 729mhz and in some games a 3ghz core can achieve full speed.
If you keep in mind that the code will be blown up by 200-300% in average, that is allready 730*3 -> 2200mhz/3000 mhz execution.
making it even more vital to speed up execution instead of recompiling.
before trying some fancy stuff, you should put some counters in to measure exactly how much % of time is needed for recompiling. i bet its not worth sacrificing execution time for that.
(06-10-2009, 03:56 AM)Iulius Wrote: [ -> ]Quote:So, basically the problem is that ppc has more registers than x86?
for my example, yes. for other examples there might be other problems.
Quote:Do you really thing it would be slower to address the RAM than to re-compile the current section?
you would have to access ram for nearly ALL instructions, for some of them twice.
no doubt that is much slower then recompile it.
the recompile isn't that hard in time.
Think about wii running at 729mhz and in some games a 3ghz core can achieve full speed.
If you keep in mind that the code will be blown up by 200-300% in average, that is allready 730*3 -> 2200mhz/3000 mhz execution.
making it even more vital to speed up execution instead of recompiling.
before trying some fancy stuff, you should put some counters in to measure exactly how much % of time is needed for recompiling. i bet its not worth sacrificing execution time for that.
Yeah, pretty obviously translating the code isn't what takes time. The problem is finding an efficient way to translate one instruction set into a completely different one - taking into account different memory maps, different endianness (yeah, ouch), different numbers of registers, different status flag functionality, etc etc, and also counting cycles to keep time correctly (of course we count cycles per block, but we have to check the counter after every block)!
This is NOT EASY. We have two attempts currently in Dolphin, JIT and JITIL. JITIL can generate more optimized x86 code but it's more complex and has at least a couple of really hard to find bugs.
If anyone thinks they can do better, well go right ahead, it's open source
Some ideas for optimization:
The big one is adding various "profile guided optimizations" to the jit. The "profile" option for JITIL has one such optimization to speed up memory accesses.
Allowing blocks to branch and keep compiling along one of the branches would probably help speed a bit. Which branch to go down in each case could be decided by some profiling, and after a block has executed 1000 times we know the common path so we'd recompile the block and inline along that path. This would probably take at least several long weekends of hacking to get working and bug free.
Once that's done, we could allow longer profiled chains of blocks to be compiled together, allowing more optimization. Etc etc. Lots and lots of work for the interested.
ector, could you please answer to his request : making the precompile (at least partly) before running dolphin itself.
do you think its possible at all, at least for some parts ?
i think its not, but im not that much in this recompile stuff that i can imagine every possible situation that might occur.
Thank you
Possible yes, partially. Beneficial? No.
Would it be possible to make some sort of a setting file that give the correct settings (as long as the game is stated as perfect ) for each games to dolphin (the settings used to check if the game is perfect), so that when you start a game you won't need to set things up ? ^^
(06-12-2009, 11:26 PM)abfab126 Wrote: [ -> ]Would it be possible to make some sort of a setting file that give the correct settings (as long as the game is stated as perfect ) for each games to dolphin (the settings used to check if the game is perfect), so that when you start a game you won't need to set things up ? ^^
There's already limited per-game options, but yeah, it could be useful to make more options settable per game. Not really sure about a good UI though..
It's better to fix bugs in the emu to try to remove the need for options in the first place