Could you explain in simple words why a x64 PCSX2 wouldn't be faster than a x86 build

[nosisab Ken Keleh]

Air already explained where 64bits helps the most, Threading and Exceptions handling. This last is the main reason is so difficult to actually crash a 64bits OS comparing with 32 and anyone that remember Win9x (an actual 16 bits with some 32 wrapping) understand how lacking this feature 16 bits was...

There is that joke about the guy that got the idea to put Linux in his dear grandmother's PC... the lovely elderly lady answered when asked she didn't like it much because it was so different. So the guy implemented a GUI that emulated the win98 to perfection. Some days later he comes to her house and ask how she was liking the new computer.

She so tell she was liking it but was feeling tad insecure... -Why? asks the guy, how is it you feel insecure?
-It's I keep expecting it to hang and crash all the day and it does not happens anymore...

well... at least 64bits OS gives some security and more crash free day after day experience and life is not only one thing.

[Air]

Ehr... that it doesn't benefit PCSX2 much (gotta admit 5% seems too low guess tho ) doesn't mean it doesn't benefit other apps, besides 7 is much better OS than XP64 which is what you should be comparing to. If you had upgraded to XP64 or from Win 7 x86 to Win 7 x64 then I'd be concerned about that increase

Indeed, typical modern C++ apps recompiled as x64 usually get 8-15% speed boost right out of the gates; but almost all of that is attributed to the extra registers being thrown at exception handling, threading, and calling conventions. x64 is also more efficient at executing typical object-oriented code, but is less efficient at running code that relies on globals and lookup tables (most games and emulators).

So yeah. x64 is an improvement, and it allows the use of over 4gb of ram; but its not ideal for emulators especially.

[Air]

Air already explained where 64bits helps the most, Threading and Exceptions handling. This last is the main reason is so difficult to actually crash a 64bits OS comparing with 32 and anyone that remember Win9x (an actual 16 bits with some 32 wrapping) understand how lacking this feature 16 bits was...

Wrong. Windows 95 was always a 32 bit OS. It provided all 16 bit libraries for backwards compatibility, and a few utilities and drivers were still running under the 16 bit layer (such as the print spool and notepad), but everything else was plain and proper 32 bit code; little different than code used in Windows 7 32-bit today. Its biggest limitation in "bits" was that it had some oddball limitations with regard to GDI object handles (a max of roughly 2048 system-wide handles, or something). But that had nothing to do with being 16 or 32 bits. That was just a bad decision by the programmers.

Where Win9x and Windows2000 differed is in how they managed threads, processes, drivers, and GDI. In Win9x, processes were weakly separated (especially with regard to DLLs), and there was no support for Data Execution Prevention. Furthermore, non-critical drivers often had extended access rights to system memory, including kernel subsystems and sometimes other processes. Video drivers in particular could be used to crash a system pretty reliably, due to the lack of protective rights applied to them.

Thus, the most frequent causes of crashes in Win9x were apps that used windows system DLLs improperly, and corrupted memory of either the shared/system DLLs themselves, or other kernel components. The system would subsequently become unstable and eventually crash.

By Win98 SP2, most of the GDI and system DLL-related crashes were fixed. It was still pretty easy to blow up the system via DirectX (which was by design, really-- made terribly unsafe at the time on purpose in order to ink out another 0.5fps of performance), via leaking GDI objects (which were global system resources as mentioned above), and it was still pretty easy to crash the system via use of buggy drivers (audio and video drivers being the most common culprits). But if your drivers were stable, your DirectX apps not buggy, and nothing leaked GDI resources, Win98 could run quite well for weeks.

[nosisab Ken Keleh]

I fear not, Air. Great part of it's kernel was 16 bits and the whole thing constructed over the MS-DOS base architecture. ME (Millenium Edition) was the first attempt to a pure 32bits code and ill implemented. XP became the "de fact" 32 bits OS and even so became really stable only after many updates and the SPs.

[NEOAethyr]

I've gotten win7 to use from 400-500megs of ram.
Which is still quite a bit when I only got 2gigs.
It's about 3500 thread handles at startup.
I've gotten windows 2003 (xp) to use 2000 thread handles and around 90megs of ram.

Back when I used the x64 os I would of thaught the vga driver's would of been much faster.
Didn't seem to be the case at the time.

Comparing xp os'es with the 64bit counterparts, both are very diff beasts.
They are somewhat more simuler in win7 though, win7 lacks alot of legacy support.
And the way it hangs onto files after use or even seeing them is a real pain.

Ie.
Compiling my bios'es and os code is impractical in win7 because if I test a com or exe file, it hangs onto the file handle for a good min or 2.
Not letting me compile over it or del it.
If I'm compile a bios, changing up my make files is impossible for a few mins after running the compile, because of the mix of batch+asm make files I have, the batch being the prob.

Legacy dos support is gone, accessing a protected ver of the 1st meg is lacking.
Instead I've heard that there's an api ver of the same thing but what is the point of that when you can't access it from a normal dos app.

Indeed it might be time for me to switch to x64 as my main os and xp/win2k3 as my os for coding...
The advantages that kept me sticking to x86 windows are gone.
Now the real ? to me anyways, is if windows 2008 r2 is as buggy as the 1st service pack was lol...


Cpu wise, most people have x64 cpu's these days.
To put it simply, if they don't have an x64 cpu, it's not likely they even have the speed to run the emulator at decent speeds anyways.

Amd x86 cpu's can't even run the emu right anymore (no sse2 and with agp support, no dx11 unless they have one of the later ati cards).

Only some of the p4 cpu's can run the emu while still being a x86 cpu that has sse2.

I suppose I have to admit...
If you move to x64 you will leave people like me in the dark with no emulator.
But I suppose that may be for the best, it might be time to move on to a slightly diff env.


The opcode length is a good arguement.
I don't know the details on the x64 opcodes, if it's 1-2 bytes to make the opcode type, or if it's 3-4 bytes to mark as a x64 opcode.
However, in such cases, it would improve speed if you used them correctly.
I mean, don't be using x64 opcodes to move a dword into eax lol.
That may double the opcode length and slow the speed down to a crawl.

I now taking care of the upper bytes of the registor would be a issue.
you can't just leave values in them and read them from a generic x64 function hoping those unused bytes won't effect it.
Same with shifts.

Maintaining such code, that uses both 32 and 64bit ops would decrease the speed of the app overall.
(making sure the extra's are zero'ed or parsed correctly).
I suppose a way of doing do would to write a 1 byte flag in mem to say if the last code was a 8,16,32 or 64bit value.

Anyways, whatever the case may be, it would not be an easy thing to do.
If you made the emu into straight x64, it would take alot of work to get it to the point where it was worth it I think.

Doing your own handling of such code, might not be possible using a c compilier ^^.
It might just assume to do most 32bit op's with x64 ver's to just ensure that there are no bugs.

64bit reg's to handle 128bit stuff for the emu.
Would be alot better then using 32bit reg's.
I know you guys use sse instead for that...
the overhead for doing it that way might be ok'ish.
In a c compiler the overhead to sim 128bit reg's might be to much, I don't know.

The cache line size.
This might be a big issue.
Unreliable cache size in x64, might take an already limited intel cpu's l1 data cache and limit it to the point where there's nothing left.
Making the overall overhead that much more a problem when working with code in the same 2meg mem page/seg.

I think the overall speed increase from going to x64 in such an app would be less then 5%, more like %3 in some cases.
And 10% slower in others.

I think it's really all down to how much pcsx2 uses generic 32bit reg's like eax, ebx, ecx and edx.
If it uses them alot for data that is generally larger then 32bit, then yes it's probably that it could improve with x64 code.
If it barely uses them, for anything more then 32bit values, then there's no reason at all to switch to x64 for that emu.

I'm not sure, but can an x64 cpu use say:
mov [ebx], rax ????
Moving a 64bit value of rax into the 32bit memory offset ebx.
If it can't then what in the world was the point in making x64 in the 1st place...


Sorry for the long post.
I'm sure there will be someone that will say stop posting bs lol.

[Dangerousd777]

I used to use Win98 on an old dell with a Pentium II @ 266 mhz and a 4 MB integrated GPU. I was playing Doom II and Duke Nukem 3D with occasional bouts of 2D and limited 3D games. I even played a some games that recommended Pentium III and Athlon... with no problems either. ;D

I miss native DOS support... DOSBox still isn't quite the same unfortunately, but it comes close enough that I didn't dual boot 98 and XP.

Thank DOSBox for that one.

I used to remember that doing scientific calculations in Win Calc would take a couple of moments... lol, I'll never have that problem again.

[nosisab Ken Keleh]

Some the reasons for not making the changes in PCSX2 code to 64bits a priority were already spoken. What most can bring real performance increase to the emulator would come in the form of real, scalar multithreading, able to make consistent usage of available cores and consistently distribute the load among them. But it's too the complicated thing, hardware oriented code benefits the maximal of pipeline models, sequential and with no or small space for out of order programming.

And this is how PS2 is designed, and so PCSX2 follows. Just remaking the whole system to use 64bits codes does not promises advantage enough to be worth the work. Only a complete change in the emulator`s very structure could benefit from the scalability of multicore hardware, and again it clashes with the PS2 original design, when and if it can be achieved soon enough, the final result would not be the PCSX2 as we know it.

It`s not so different from the problem faced by graphic hardware manufacturers since the birth of ARB`s OpenGL around the 1990 first years, itself coming from SGI`s Iris GL a decade before. At this time, soon before OpenGL, Pixar developed a system With RenderMan as it`s frontline and from it the PixelFlow Shading Language what Stanford`s worked together the RenderMan Concept to create what came out around 2001 and became the RTSL (Real Time Shading Language).

Nowadays graphics architecture is for what is found commonly in actual hardware implementation is based in OpenGL and DirectX (this born from OpenGL itself and the Reality Lab from RenderMorphics) and forms the base to Graphics APIs and brings with them their own shading languages, GLSL (OGL) and HLSL (dx). C and C++ are themselves incorporated to complete the Graphical Processing base.

This long speech with date references means to provide a background that may help to understand those timespams of decades and with it to understand things aren't this simple and quick. But in what it could help to understand the topic question?

The answer is in the way OpenGL (and directX) are actually implemented and how RenderMan was designed.

While OpenGL/DX are directed to hardware and so pipeline oriented, RenderMan was designed as tree oriented. The former the best suited for hardware implementation and the second for software and provides a model that can be more easily implemented in a multithread environment.

This could lead to think another way to reinterpret the original game code and transform it in something playable on the PC environment, but it would not be a PS2 emulator anymore. It would be just a way to play PS2 designed games in PC and it could be judged piracy or at least abuse of the fair use concept.

So to be true to the emulation, the original hardware model need to be followed, and in doing it, implementing multithreading becomes an overwhelming task. And then recoding the whole system to 64bits more prolix than this whole post.

Sorry OP, It was not a short and in simple words way to tell it.

[haxor]

How to put it short.

The implementation for x64 uses the same core techniques than the actual x86 code.
The extra adress range is kinda useless cause the memory still needs to be mapped twice - for PS2 and recompiled code and data.
The extra general purpose and SSE registers are negligible cause the execution of the instructions runs thru the same stages of the CPU's pipelines. Parallel execution of SSE instructions is barely possible anyway cause the most demanding code - VU code - needs to check flags alot. Thus creates kinda dependancy - reading flags and registers back and forth.

For example: a simple matrix multiplication in native SSE code doesn't really care about flags. But the VU's and the VU's recompiler does.

Most important fact. The VU's speed depends on the raw floating point performance of a single core - cause it doesn't multithread. The bottleneck is right there. Even splitting VU programs between cores doesn't work well cause the whole VU memory needs to be transferred between cores. And this solution isn't really practical cause of the dependencies between programs and their data.

Short enough?

[nosisab Ken Keleh]

Yes, short of saying the bottleneck is the whole pipeline model and the tree model would not be a PS2 emulator anymore. And a tree model would be much better suited to a software solution from the emulating machine viewpoint.

The former post's middle part hopped to let a bit more clear why the pipeline is ideal for the hardware implementation (the actual PS2) but a cloggyness for the emulating software. And how it was and is still a quest for hardware manufacturers to get that flexibility and tightly integrate the CPU and GPU.

[haxor]

Yes, short of saying the bottleneck is the whole pipeline model and the tree model would not be a PS2 emulator anymore. And a tree model would be much better suited to a software solution from the emulating machine viewpoint.

The former post's middle part hopped to let a bit more clear why the pipeline is ideal for the hardware implementation (the actual PS2) but a cloggyness for the emulating software. And how it was and is still a quest for hardware manufacturers to get that flexibility and tightly integrate the CPU and GPU.

Dunno what ya writing about. It's all a lil offtopic.

And what pipeline model? Fetch code - fetch data - compute - writeback result or send to buffer for another processor. This one?

Nah.

The only difference between x86 and x64 is the extra registers and adressing range and the possibility of merging instructions reading 64 bits instead of 2x32 bits. Everything else has kinda nothing todo with the topic.

Even the thought of multithreading/multicoring the emulation has nothing todo with the x64 topic. It's just a lucky given that computers use multiple cores these days. But they still can't be used efficiently cause synching all the PS2 components is a nightmare doing it multithreaded on multiple cores. Even tho it's possible to do - rewriting the whole system.

Ok. This is the Xst discussion about PCS2x64. It will probably not happen soon. Over.

This isn't even a developer thread. They should know all the answers. And Air gave a lil.