Poll: x64 build faster on x64 OS?
Yes
No
[Show Results]
 
Note: This is a public poll, other users will be able to see what you voted for.
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Could you explain in simple words why a x64 PCSX2 wouldn't be faster than a x86 build
#1
deleted
jesalvein broke my balls, farewell
Reply

Sponsored links

#2
The point is that it would be much faster and much more stable. Almost all games from ps2 got some 64-bit data, that is why pcsx2 is so slow and crush every few minutes. Too much 64-bit data have to be converted for 32-bits by 32-bit program to be made on 64-bit pc hardware and os later that haven't been projected to run 32-bit software the most.
AMD Phenom II 550 Black Edition @3.8GHz
4GB DDR2 1066MHz CL5-5-5-15
ASUS Radeon EAH4770 Formula 512MB DDR5
Reply
#3
I know you want a short answer, but I don't have a short one... (plus I'm known to make long posts lol).

I was gonna switch to x64 along time ago, I have win2003 datacenter x64 vlm.
The os ran good.

The only issue I had with originally was lack of com and exe support.
It only support win32 pe exe's.

Driver support is slightly lacking but if you can get around it it's fine in that respect.

I benched it, comparing it to the x86 ver of win2k3 enterprise.
Using videos, everest and gaming to compare it.
It was no faster, sometimes slower then the x86 ver.
Very little diffrence in performance.
Thumbnails extraction was the only thing I noticed that was quite abit faster (it was kinda like I had 2x the ram).


It wasn't until I starting programming in it when I started to dislike it.
The com+exe support thing I didn't like.
So I started work on a pe app.

That's when I noticed my op codes weren't always doing what they should be doing.
Simple, normal opcodes.
I don't use mmx...

I started to debug it and started to notice which op's where messing up.
I can't remember 100% because it's been 2 years since then.
But at the time I was very much under the impression that windows was emulating all of my opcodes even when it was a native pe app.
x86 or x64 pe, it didn't matter.

With the results of my speed comparisons it convinced me that window x64 was emulating everything.
With the only potential for more speed being in certain instances with x64 codes.
If the emu is x64, and it's sim'ing/emu'ing x64, it can potentially be more efficiant then natively running x86 on a real cpu.
In some instances, and what my results showed, is that that didn't happen very offen.

Later on, a new ver of fasm came out with a few opcodes redone for x64.
Which could of explained some of it.

But I still think it emu's/simulates all of it's client side code.
And therefor worthless.


As for x86 not supporting more then 3gigs of ram, that's bs.
You can hack the x86 kernal to support more ram.
It's not an easy thing to do though.

Even though win7 screwed up it's support for vesa, and int21.
I'de still use the x86.

Maybe someday motherboard's will have a bios that enables x64 from the get go and just runs x86 windows with native x64 support.
(with windows not having a clue about it)

Then you'de have native x64 code running on your cpu, a real speedup.

Not some windows thing parsing every single opcode in your program and messing it up.

That's if you can get into an unreal x64 mode of some sorts and get it into windows without reseting it (I suppose there's always a way of ensuring that don't happing...).

I know x86 dos can support x64.
Windows would be a bit trickier though.


If you want an x64 os, run a ver of linux that is x64.
It's probably 2x faster then x86 linux on half the things you'll do.
(I'm not a linux person so I couldn't really say how that performs)


I dn, I guess the best way of finding out if the os is even worth anything is to bench the fpu with x64 asm using mandelbrot fractals or something I dn.

ASUS CH4, 1090t @ 4ghz, 2x1gb @ 2ghz, GT240
2x1tb Modded WD Green RAID0, Optiarc 7241S
Modded Enermax 350w

Win7 Ent x86 VLM / Win2K3 Svr Ent SP2-R2 x86 VLM
Reply
#4
All of the following are assumptions:
I reckon a 64-bit version of PCSX2 would be indeed faster. However it is difficult to code and not all that many people have a 64-bit CPU + 64-bit OS.
Intel i5 3450
AsRock B75-Pro3-M
Sapphire R9 290 Tri-X OC
8GB DDR3-1333 RAM
Sandisk Ultra Plus 256GB
Seagate 7200.14 1TB x2
Enermax Triathlor 450W PSU
Reply
#5
I suppose that 64-bit version could lower cpu requirements from 3.6GHz to at least 2.6GHz and could give more work to graphics card, part of data that have to be made by cpu now could be given straight to graphics card. But even more important profit is stability. Everyone that have tried to finish any more demanding game than ff knows how it goes now. At the begining it crashes from time to time, few hours of play later it's getting really annoying and you have to restart same level ten times to finish it till you get to point where pcsx2 crashes always. It comes after finishing of 15-20% of game. It seems to be 32-bit bottleneck related.
AMD Phenom II 550 Black Edition @3.8GHz
4GB DDR2 1066MHz CL5-5-5-15
ASUS Radeon EAH4770 Formula 512MB DDR5
Reply
#6
Sure it'd be faster, once the entire recompiler core of PCSX2 has been recoded to be designed to take advantage of x64 instructions properly. And when that's all said and done, expect a 2% to 5% speedup on some games, perhaps less on others. Don't expect more though.

Common misconceptions:

1. The EE is a 64 bit CPU! So x64 would help ALOTSSS!!!

Not really accurate. The EE is barely a 64 bit CPU. It mostly consists of 32 bit and 128 bit instructions (128 bit instructions being SSE-style). Its 64 bit instruction set is pretty limited and rarely used. Currently all 128 bit instructions use the SSE registers and 128 bit ops. They would gain little from x64. Furthermore, several of the x64 instructions are SLOW, in particular 4 bit mul and 64 bit div. So even if we port to x64, we're actually better off using our current 32-bit implementations mul and div than using the CPU's built in 64 bit ones.

2. But x64 gives you MOAR REGISTERS!

Yes, but two problems here: not as many as you think, because a few of the new registers are reserved for addressing, threading, and exception handling features. These are godsends for most standard apps, and are where a big chunk of the speedup for x86->x64 conversions come from. Emulators tend to use exceptions and threading sparingly, thus having those regs reserved out doesn't help us. Furthermore, extra registers are not always useful to emulators anyway. Recompiling code to be emulation-accurate imposes tons of limitations, and that limits the size of the blocks e can recompile and optimize. Recompilation of PS2 code has a hard time making use of the current batch of x86 registers half the time, let alone a batch of new x64 regs.


On top of those, x64 has some notable drawbacks:

* The addressing system is still limited to 32-bit offsets. Dealing with this properly in an emulator (virtual machine) requires an addressing register in use at all times, and adds an extra instruction to almost every memory operation.

* Using the new registers bloats instruction opcode sizes by 1-2 bytes each. This adds up over time and causes your CPU code cache to operate less efficiently.


In the end, the benefits and drawbacks will mostly cancel each other out. Once optimized for x64, PCSX2 would likely still be faster -- mostly because it would still benefit somewhat from the registers reserved for exception handling and threading in the non-recompiled code (event handlers, UI, direct-x, etc); but its just not enough to merit the major rewrites needed just to make it work (let alone optimize it).
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply
#7
(08-01-2010, 10:25 PM)midlothian Wrote: I suppose that 64-bit version could lower cpu requirements from 3.6GHz to at least 2.6GHz and could give more work to graphics card, part of data that have to be made by cpu now could be given straight to graphics card. But even more important profit is stability. Everyone that have tried to finish any more demanding game than ff knows how it goes now. At the begining it crashes from time to time, few hours of play later it's getting really annoying and you have to restart same level ten times to finish it till you get to point where pcsx2 crashes always. It comes after finishing of 15-20% of game. It seems to be 32-bit bottleneck related.

... and this is a bunch of fantasy baloney. I have no earthly idea where you got your head filled with this stuff, but my best and only recommendation is that you flush it out now and acquire new information from new sources that have at least some bearing on reality.

FFX crashes have to do mostly with improper DMA emulation, and 32 bit vs. 64 bit has absolutely no bearing on how the DMA transfers its memory around.
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply
#8
(08-01-2010, 10:25 PM)midlothian Wrote: I suppose that 64-bit version could lower cpu requirements from 3.6GHz to at least 2.6GHz and could give more work to graphics card.
...
It seems to be 32-bit bottleneck related.
Other than merely saying it, you provide zero evidence to support these claims. Crashes are usually a result of programming quality, and/or hardware/drivers issues.

Speed gain from x64 is probably possible, but the exact amount is also highly dependent on the problem domain and on effective usage within the application. IIRC the devs said that current PCSX2 won't gain much from x64, and they do seem quite knowledgeable at the subject.

Bottom line: great claims with zero credibility...
[i7-3630qm/gt650m-2G/Win-7] [i7-4500u/R.HD8850m/Win-8.1] [2010-MBA/OSX-10.9.x]. Scroll smoothly with SmoothWheel for Firefox.
Reply
#9
deleted
jesalvein broke my balls, farewell
Reply
#10
Ehr... that it doesn't benefit PCSX2 much (gotta admit 5% seems too low guess tho Tongue2) 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 Tongue2
Core i5 3570k -- Geforce GTX 670  --  Windows 7 x64
Reply




Users browsing this thread: 1 Guest(s)