Next Generation Emulation banner

VM Build Running Slower

1K views 9 replies 4 participants last post by  _hyde_ 
#1 ·
First of all I'd like to congratulate the authors for doing such an outstanding job with this emulator.

I'm experiencing a strange issue when running the BIOS under PCSX2 0.9.4. The VM build runs the System Configuration menu at about 50 FPS whereas the non-VM build runs it at 140 FPS. Both builds share the same settings, so I'm wondering whether this is happening because of an OS compatibility issue or a hardware issue. Here are my specs:

Q6600 @ 3.5GHz
EVGA 9800 GX2
4GB RAM
Windows XP 64

Thanks for the help.
 
#2 ·
Happens to me too on XP64 and Server2008 64bit not sure what causes it, it makes some games slower also but in all it isnt much of a big difference (maybe 1-2 fps less compared to 32bit versions of this OSs). However in some parts like when running between menu options or memcard spaces (like in FFX) it makes the FPS slowdown a lot.

Never figured it out but doesnt happen in 32bit OSs as far as I know.
 
#4 ·
I only tested a couple games that are very fast for me but the difference wasnt much more than 1-2 fps so about 2-4% not really noticeable. Only problem was in 2D parts (menus) mostly slowing down.

Hmmm what is your sound card and are you using any modded drivers? just trying to figure this :p
 
#5 ·
It's just a plain Realtek HD chip from my MSI P35 Platinum. According to my understanding PCSX2 has a 32-bit dynarec engine, right? Improper alignment could cause some performance issues, but then I'm not sure whether that's an issue going from 32-bit to 64-bit code. Maybe one of the PCSX2 authors can offer some insight on this?
 
#7 ·
It's just a plain Realtek HD chip from my MSI P35 Platinum. According to my understanding PCSX2 has a 32-bit dynarec engine, right? Improper alignment could cause some performance issues, but then I'm not sure whether that's an issue going from 32-bit to 64-bit code. Maybe one of the PCSX2 authors can offer some insight on this?
When executing 32-bit code I don't think there are alignment issues, I've never considered it when coding either C or assembly and haven't noticed a performance hit on my 64-bit dev machine.
RAM is still addressed in byte increments, with proper cache design you shouldn't notice any alignment issues that may exist.

There really isn't a problem going 32 to 64 bit, it's doing it in a way that increases speed that's the problem. 64-bit processors are backwards-compatible with 32-bit code, whether it runs well is up to the OS and related systems.
 
#8 ·
RAM is still addressed in byte increments, with proper cache design you shouldn't notice any alignment issues that may exist.
Thanks for the reply. If I remember correctly, a 32-bit Intel processor takes more cycles to execute 1-byte operations than to execute 4-byte operations. Also -for optimal performance- 32-bit operations should be done with dword-aligned adresses. I've done a bit of research and came across the following article:

Data Alignment when Migrating to 64-Bit Intel® Architecture - Intel® Software Network

What are your thoughts on this?
 
#9 ·
The article is more about what can go wrong if you don't align data for a 64-bit program, but a good read nevertheless. Basically, it's a warning to always align on a relative boundary or you'll run the risk of causing an exception. Don't know if it's related to 32-bit programs, my reading comprehension isn't so good at 3am.
I'm going to leave it up to programmers much more talented than I to work out these issues :p

When (if) a 64-bit version of the core binary translator/dynarec is ever created, it just shows that the developers can't possibly be payed enough at their day jobs. They deserve to be in $PARADISE_OF_CHOICE sipping margaritas for all they have accomplished.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top