|
|
Post by soltis on Oct 8, 2007 14:39:05 GMT -5
So I imagine a lot of the emu is written in assembler or some-such, but I'm wondering how much benefit one would see from a more optimized build of pSX... I don't know what compiler the author uses, but I'd personally love a -march=k8 build of the emulator, were I to know it was compiled with gcc in Linux, for example.
This would probably not help a *lot*, but it might be nice to see some more targeted builds if any real performance increase could be seen from it (esp. for older/slower platforms).
Just a random idea; feel free to ignore it.
|
|
|
|
Post by Firehawke on Oct 8, 2007 18:42:05 GMT -5
Well, can't speak much on the code side of things, but a 64-bit native Windows build would certainly be nice if possible-- just to try to keep as much off the 32 bit compatibility layer on my Vista 64 install as possible. I wouldn't be expecting any real performance boosting, obviously.
|
|
|
|
Post by Haldrie on Oct 9, 2007 14:39:52 GMT -5
pSX hardly uses any power to run since it focuses on DirectDraw for video. As long as you have the latest drivers for your hardware and the lastest version of DirectX 9c you should easily be able to run it even on a computer that can't run ePSXe at full speeds. As far as the 64-bit stuff I don't have any experiece with that as I'm still runing 32-bit hardware and 32-bit XP Pro.
|
|
|
|
Post by pSX Author on Oct 9, 2007 22:31:19 GMT -5
soltis: this would be nice but it would increase my workload a lot - even just having two builds (Linux and Windows) has complicated things...imagine how bad it would get if I had 10 builds to test  firehawke: at the moment there is very little to gain from doing an x64 version of pSX. Its not as simple as it sounds - its not just a case of flipping a switch in the compiler and getting x64 code. Currently the pSX codebase is not 64bit clean - and also the recompiler actually generates code on the fly so it would need to be rewritten to take advantage of 64bit code. Maybe I'll move to x64 one day, but for now its not worth it (and atm I don't even have a CPU that supports x64!). The 32->64bit transition for OSes and CPUs is NOT like the 16->32bit transition as many people seem to think... for some apps there is NO reason ever to port to x64. I'm expecting to see 32bit apps in existance for a long long time yet. Also, many people are suprised to learn that the same code compiled for x64 can actually be slower than the original 32bit code (due to the extra memory accesses.. ie. all pointers are now 8bytes instead of 4). |
|
|
|
Post by Firehawke on Oct 11, 2007 7:26:33 GMT -5
Well, the problem is that Vista really doesn't seem to deal well with 32-bit code. As more and more commercial software moves up to 64-bit, I expect Microsoft to start depreciating the 32-bit end of it about the same as they did with the 16-bit end.
I certainly knew about the headaches involved-- I'd kinda figured your code was already 64-bit clean, but.. in hindsight, this line of code (emulation in general) is probably the hardest to really do that with for various reasons including optimizations.
Well, again, if you can ever pull it off, it'd be nice, but it's not really a huge deal yet. We'll see if my fears come to pass in a year or two. They might not-- Vista's not really taking off. Not like XP did, certainly.
|
|
|
|
Post by pSX Author on Oct 11, 2007 8:40:29 GMT -5
Well, the problem is that Vista really doesn't seem to deal well with 32-bit code. As more and more commercial software moves up to 64-bit, I expect Microsoft to start depreciating the 32-bit end of it about the same as they did with the 16-bit end. eh? Microsoft never deprecated 16-bit code... win16 apps run just as well on XP as they ever did. They HAD to remove support for 16bit apps in win64 because no CPUs exist that can support 16, 32 and 64 bit apps running at the same time... thats the ONLY reason they removed it (16bit apps still work fine in 32bit Vista). Only in the minds of Lunix fanboys... |
|
