Build for amd64 – or x32?

[Not Mr Flıbble]

I've noticed that most binaries are for x86 rather than amd64 [x86_64].

Compatibility with older hardware aside, if the only reasons for sticking with x86 are simple pointer and long integer sizes (at least, in C and C++) and the attendant increased memory usage, why not target x32 instead, at least on GNU/Linux (⇒ also SteamOS)? That way, you get the full register set (and at full width) but long integers and simple pointers are 32-bit.

Or is there not enough speed advantage in doing so…

https://wiki.debian.org/X32Port is directly relevant here.

[Satoru]

x32 is just a 64-bit exe using 32 bit registers. It's still basically a 64-bit exe and thus isn't really relevant when talking about x86 compatiblity.

Most binaries are 32bit x86 simply because there hasn't been a need to go 64-bit for 'most' games and only very recently has 64-bit become ubiquitous enough to even begin rolling it out for games. Few games support it because there hasn't traditionally beeen a need to have that much memory for games.

[Not Mr Flıbble]

You mean 32-bit addressing, not 32-bit registers.

I'm suggesting x32 here exactly because it doesn't (or shouldn't) increase memory requirements but does allow some scope for optimisation at compile time. If a game does need more memory then amd64 is the better choice anyway. Also, there's plenty of broken code out there which contains rather more hard-wired assumptions about data types' sizes than is practical.

Your point regarding user base may have some validity – how recently do you mean? Seems to me that, for Debian, that was around 2 to 3 years ago. Maybe it's a lot more recent for Windows installations…? (Then again, only two choices rather than three there?)

It would be interesting to see some numbers on this, though: CPU type (x86 or amd64/x86_64) v. OS type (Linux-based, Mac, Windows) v. CPU support in the OS.

… and, yes, I'll run amd64 or x32 builds of games where available; and, where an option is presented, it would make sense for that to default to amd64 or (possibly better, after first run) what was selected last time.

[aiusepsi]

Something like X32 seems like a bit of a non-starter except for really specialised applications. I can't think of many occasions where you're going to need absolutely tons of registers to make stuff happen fast, and simultaneously be so memory-constrained that the size of pointers is going to kill you.

The really key win for games in going to x64 is the vast increase in address space, and x32 shoots that in the head. On top of that, changing the ABI is just a pain. You better hope that everyone you want to link with ships source or ships x32 binaries, because otherwise you're in a world of hurt.

Anyways, Steam is really orthogonal to this. Steam's got the amd64 binaries to support Steamworks and the overlay in games.

[Not Mr Flıbble]

Changing the ABI is not relevant; there are no ABI changes being discussed here. Building for a different ABI may require some porting, but ideally only assembly code sections would need to be adapted, Unfortunately, this isn't always the case.

Also, binaries built for x32 can be installed alongside binaries for i386 and amd64; whether they're useable depends on the kernel having been built with the relevant support. Obviously, you'd need the libraries etc., but again, install alongside. This would be the case for SteamOS if it had x32 support (there'd be a set of .debs for x32); it is the case (or should be) for Debian unstable, given a suitable entry in your sources.list and “dpkg --add-architecture x32”.

[aiusepsi]

โพสต์ดั้งเดิมโดย Not Mr Flibble:

Changing the ABI is not relevant; there are no ABI changes being discussed here.

X32 is an ABI for amd64/x86_64 CPUs using 32-bit pointers.

???