xbox/ps3 binaries 32/64bit?
- Thread starter slapnutz
- Start date
TheWretched
Regular
IIRC, the Linux binaries for the PS3 use the 64bit PPC ones, but I haven't used it in a while, so I am not 100% sure.
64bit exes on PC are mostly of no use, because you would a) cut your installed base by more than half and b) the gain is nearly none (I see no difference in performance between HL2 and HL2 64bit)
64bit exes on PC are mostly of no use, because you would a) cut your installed base by more than half and b) the gain is nearly none (I see no difference in performance between HL2 and HL2 64bit)
Game executables for both Xenon and PS3 are 32-bit.
There is one big advantage of x64 on PC that will be the driving force for adoption and that is that on 32-bit even with /LARGEADDRESSAWARE a single process (the game) may only allocate a max of 2 GB of memory, even on a 64-bit OS.
This is a hard limit esp. for game pipelines/editors during development so many developers, us included (DICE), are creating 64-bit versions of our tools as a solution to handle editing & processing of large complex environments. Feels a bit silly to have 4-12 GB of memory in your machine and simply not be able to utilize it as you are still on x86
Eventually the retail versions of the games will run into this limitation as well and force migration for the high-end to x64. But there will be a long transition period while both x86 and x64 binaries are available before x64 (and 64-bit OS:es) are so widely available that you can support only x64 executables, though I am looking forward to it! If you are a gamer and are buying a new OS now, you would be crazy to buy a 32-bit OS.
On 64-bit Windows the maximum amount of memory a process may allocate is 8 TB which should be enough for a while
There is a good article about all of this in MSDN: "64-bit programming for Game Developers"
http://msdn.microsoft.com/en-us/library/bb147385.aspx
There is one big advantage of x64 on PC that will be the driving force for adoption and that is that on 32-bit even with /LARGEADDRESSAWARE a single process (the game) may only allocate a max of 2 GB of memory, even on a 64-bit OS.
This is a hard limit esp. for game pipelines/editors during development so many developers, us included (DICE), are creating 64-bit versions of our tools as a solution to handle editing & processing of large complex environments. Feels a bit silly to have 4-12 GB of memory in your machine and simply not be able to utilize it as you are still on x86
Eventually the retail versions of the games will run into this limitation as well and force migration for the high-end to x64. But there will be a long transition period while both x86 and x64 binaries are available before x64 (and 64-bit OS:es) are so widely available that you can support only x64 executables, though I am looking forward to it! If you are a gamer and are buying a new OS now, you would be crazy to buy a 32-bit OS.
On 64-bit Windows the maximum amount of memory a process may allocate is 8 TB which should be enough for a while
There is a good article about all of this in MSDN: "64-bit programming for Game Developers"
http://msdn.microsoft.com/en-us/library/bb147385.aspx
I think an important point here is the distinction between 64 bit as memory address and as internal workspace and associated performance. In the Olden Days, an 8 bit processor would perform calculations on 8 bits at a time, a 16 bit processor on 16 bits at a time. If you wanted big numbers on an 8 bit processor, you had to work around the register limits. Then the same with 16 bit and 32 bit registers - if you were dealing with 32 bits of data at a time, a 32 bit processor was faster than using a 16 bit processor.
That's irrelevant now. We have 128 bit vector processing units. The 'bit-ed-ness' of CPUs, always misleading (see Motorolla 68000) is now just a matter of memory addressing, not internal performance. Internally they're all 128 bit vectors in calculations.
That's irrelevant now. We have 128 bit vector processing units. The 'bit-ed-ness' of CPUs, always misleading (see Motorolla 68000) is now just a matter of memory addressing, not internal performance. Internally they're all 128 bit vectors in calculations.
On 64bit windows, /LARGEADDRESSAWARE allows full use of 4GB of address space available with 32bit pointers (link dates back 4 years and refers to XP-64, but Vista has the same behaviour, AFAIK).
Of course, you're still constrained to the 2GB/2GB split when running on a 32bit OS (or, technically, 3GB/1GB on systems booted with the /3GB switch, but i doubt that applies to many gaming systems
), so to really take advantage of that you'd have to mandate only running on 64bit OSes, at which point you might as well just switch to 64bit anyway (unless someone's doing truly evil things with pointers somewhere in your codebase and you're not 64-bit clean...).Thing to note here, PS3 started with a 64bit ABI but it got unanimously boo-ed by developers until they replaced it with 32bit later.repi said:
Yea and this - 32bit ABI/exes don't use 64bit addressing, but the code still happily uses 64bit(and higher) registers and arithmetic, giving it all the performance benefits that were traditionally associated with "bitness".Shifty Geezer said:
Similar threads
- Locked
