Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Static Recompilation .. ?!
#1
as i can see in the emulator PS2 DVDs are recompiled "on the fly", but why?
A complete recompiled build of a PS2 DVD may take some time but its much faster than doing it "on the fly".
Reply

Sponsored links

#2
(05-10-2010, 05:29 PM)tommy87 Wrote: as i can see in the emulator PS2 DVDs are recompiled "on the fly", but why?
A complete recompiled build of a PS2 DVD may take some time but its much faster than doing it "on the fly".

it may be faster than doing it "on the fly" but do you have a few hundred GB's of memory? i suspect not..

The PS2 processes tens of GB's per second, usually completely different to the last lot, all of that will need to be stored in memory for your idea to work.

BTW its called Static Recompilation, a technique used by several N64 emulators
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#3
Also it won't be "much" faster Wink
Reply
#4
First of all, you are rigth, i should use the technical terms Happy

(05-10-2010, 08:43 PM)refraction Wrote: The PS2 processes tens of GB's per second, usually completely different to the last lot, all of that will need to be stored in memory for your idea to work.
maybe you are mistaken, but no PC sytem can processes tens of GB's per second Wink.

(05-10-2010, 08:43 PM)refraction Wrote: it may be faster than doing it "on the fly" but do you have a few hundred GB's of memory?
as i tried to show you above, you dont need thad much GB. You still need a lot but not that much! And this is not so important, because you only need that much in the preprocess.
The essentially problem is, that the preprocess need a lot of time.

(05-10-2010, 09:15 PM)rama Wrote: Also it won't be "much" faster Wink
sorry to say that, but you are wrong. The Just-in-time recompiler used in PCSX2 is a lot of slower than a static recompiler.
The Just-in-time recompiler used in PCSX2 is using PS2 machine code and the PS2 machine code is PS2 optimized.
To work with this code, you need to transform this code in assembler code and than you need to optimise the code before you can execute it...that means you need a lot memory accesses and code transformation before you can execute and that is realy slow.

Biggrin
Reply
#5
Wow, you sure know PCSX2's recompilers well.
Except you missed that we do all those optimizations, lol.
It doesn't matter *when* you recompile code, as long as you do the optimizations.
PCSX2 is currently *very* good at optimizing code!
Doing it at runtime only ever becomes a problem if your buffers are too small, or the game engine has self modifying code.
In those cases you'll be constantly recompiling, which is indeed slow.
We have all known cases of that covered though.
Reply
#6
(05-11-2010, 11:50 AM)tommy87 Wrote: First of all, you are rigth, i should use the technical terms Happy

Oooh multi quote time Laugh
(05-11-2010, 11:50 AM)tommy87 Wrote: maybe you are mistaken, but no PC sytem can processes tens of GB's per second Wink.
I wasnt talking about PC's and i meant potentially the PS2 can (26gb/sec to be precise). and FYI, my PC has over 10gb/sec memory bandwidth (thats over 10,000mb) in sisoft benchmarks Tongue

(05-11-2010, 11:50 AM)tommy87 Wrote: as i tried to show you above, you dont need thad much GB. You still need a lot but not that much! And this is not so important, because you only need that much in the preprocess.
The essentially problem is, that the preprocess need a lot of time.

It really depends on the game, if you take a really intensive game where most of the disc isnt just movies, or what about multi disc games? you cant squeeze a full dvd in to memory unless you have 4gb in the first place (thats free, not without OS), the only way around that would be to keep them external and only have the main program in memory, but even with that overhead removed, you still need a hell of a lot of memory. I recall N64 requiring a good couple of hundred megabytes, but we arent talking the same generation of console here, we're talking one far more advanced. Remember a large chunk of our userbase still only has 1-2gb of memory, many are moving to windows 7 with that, static recompilation on this spec machine just isnt feasable.

(05-11-2010, 11:50 AM)tommy87 Wrote: sorry to say that, but you are wrong. The Just-in-time recompiler used in PCSX2 is a lot of slower than a static recompiler.
The Just-in-time recompiler used in PCSX2 is using PS2 machine code and the PS2 machine code is PS2 optimized.
To work with this code, you need to transform this code in assembler code and than you need to optimise the code before you can execute it...that means you need a lot memory accesses and code transformation before you can execute and that is realy slow.

Biggrin
as rama said above, we've done a hell of a lot to optimize everything we can, however in many cases, there are just things which the PC can only dream of doing, there are just no instructions for it. We usually have to use 3-4 SSE instructions to achieve 1 PS2 instruction, but with all the reg caching and peephole optimization and block optimizations we use in the current recompiler, in some cases it isnt far off static recompilation anyway, so as rama said, it wont be much quicker, no.

Putting it bluntly, i appreciate your feedback, but you are infact wrong in this case Biggrin
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#7
whoa then its multi quote time again^^
And dont forget i just want to help. Wink

(05-11-2010, 12:40 PM)refraction Wrote: I wasnt talking about PC's and i meant potentially the PS2 can (26gb/sec to be precise). and FYI, my PC has over 10gb/sec memory bandwidth (thats over 10,000mb) in sisoft benchmarks
yeah i belive that you have this memory bandtwith, but that doesnt mean that you can use this theoretical maximum and it also doesnt mean you need that much memory, its only the speed of the memory access. And not even the PS2 can processes 26gb/sec, i think you talking about a special part of the PS2 which have such a great rate, but the whole PS2 system cant do that!

(05-11-2010, 12:21 PM)rama Wrote: Wow, you sure know PCSX2's recompilers well.
Except you missed that we do all those optimizations, lol.
when you dont do these steps, than you dont have a recompiler Wink. But Please tell me how this Compiler exactly works.

(05-11-2010, 12:21 PM)rama Wrote: It doesn't matter *when* you recompile code, as long as you do the optimizations.
thats only true when there are enougth CPU cycles left do recompile the code. And i think this is exactly the problem Wink

(05-11-2010, 12:21 PM)rama Wrote: PCSX2 is currently *very* good at optimizing code!
i know that they are the one of the best, but i think they can be better

(05-11-2010, 12:21 PM)rama Wrote: It really depends on the game, if you take a really intensive game where most of the disc isnt just movies, or what about multi disc games? you cant squeeze a full dvd in to memory unless you have 4gb in the first place (thats free, not without OS), the only way around that would be to keep them external and only have the main program in memory, but even with that overhead removed, you still need a hell of a lot of memory. I recall N64 requiring a good couple of hundred megabytes, but we arent talking the same generation of console here, we're talking one far more advanced. Remember a large chunk of our userbase still only has 1-2gb of memory, many are moving to windows 7 with that, static recompilation on this spec machine just isnt feasable.
phew this is a large comment...maybe i should explain myself a little bit more Wink
im not talking about fully recompile a Game when starting PCSX2, i mean "converting" a game iso in usefull data and store them into a file. And then Just-in-time recomiling this optimized file.

ok, before i talking more, im waiting for your feedback and sorry for quoting that much^^
Reply
#8
I think there's still plenty of optimisation left to do on the recompilers (I have a few ideas for the EE recompiler in particular) but preprocessing has no benefits. (The space requirements aren't as silly as refraction suggests btw, games always have much less code than the total PS2 main memory of 32MB. Converting textures ahead of time would save a lot of processing in the GS plugin but it's also absolutely impossible to do in a generalised fashion, plus we have a runtime optimisation for this planned that will perform even better.) In fact, static recompilation has less optimisation potential than dynamic recompilation because many future optimisations are based on knowing the machine state at time of first execution of any block.

In any case, besides having no incentive we have absolutely no concrete idea of how to do this and nor do you.
Reply
#9
thanks for that answer, thats what i want to know. But dont say that static recompilation has less optimisation potential than dynamic recompilation...the full potential can only be reached of you combine both...

(05-11-2010, 07:22 PM)pseudonym Wrote: Converting textures ahead of time would save a lot of processing in the GS plugin but it's also absolutely impossible to do in a generalised fashion
never say, that something is impossible, its maybe very vrey difficult, but not impossiple...maybe i can help you in this point when i have the time, but in the moment i have very much to do Wink
Reply
#10
Uh, no. It's impossible. Games can and do store the textures and everything else any way they please in data files distributed on the disc in any fashion that suits them and hidden in any way the developer deems necessary (e.g. squaresoft games deleting their data packs from the iso directory listing and using a separate index of the start sectors and sizes.)

Please trust that we know a little about what we're doing.

(And for that matter who the hell are you that you think you know better how to write a PS2 emulator than us?)

(And another thing: ignoring your claims about static recompilation allowing better optimisation, the only real benefit is no recompilation time during execution, which is admittedly an issue (many brief sharp drops in fps during loading that cause sound breaks are because of this, though the sound breaks can be resolved separately). This could potentially be resolved by storing relocatable recompiled blocks in a file for each game during execution and reusing these if available on the next run. However, recompilation times aren't really high enough to justify this currently and our blocks aren't relocatable at the moment either.)
Reply




Users browsing this thread: 1 Guest(s)