ID:1182623
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
As said here - http://www.byond.com/ forum/?post=132464&hl=lib32#comment655963

Tom wrote:
[edit] Eventually we'll do a 64-bit build for the various unix systems. The holdup right now is that our 64-bit machine uses a different gcc and it is having some issues with our hacky code.

Is your 64bit machine's GCC still a different version? come on it's been years :)

You can get around this by installing ia32-libs but still a 64bit flavor would be nice.
A.T.H.K wrote:
As said here - http://www.byond.com/ forum/?post=132464&hl=lib32#comment655963

Tom wrote:
[edit] Eventually we'll do a 64-bit build for the various unix systems. The holdup right now is that our 64-bit machine uses a different gcc and it is having some issues with our hacky code.

Is your 64bit machine's GCC still a different version? come on it's been years :)

You can get around this by installing ia32-libs but still a 64bit flavor would be nice.

+1..this would be nice.
Could we pretty please have this? I've found myself in a position where a server has limited space, and a few hundred MB of libraries just for BYOND is less than ideal.
Any news on this?
Bump...
bamp BAMP BAMPPPPPPPPPPPPPPPPPPPPP
While I would love to see this feature, I would like to note that Linux servers can run 32-bit operating systems with more than 4GBs of RAM. PAE is your friend. =)
It's also worth noting that PAE comes out of the box on most distributions, similarly.

Not that this particularly alleviates the multilib concerns Murrawhip has raised, mind, which is possibly the only big benefit of a native 64 bit build.

All other benefits make an assumption that BYOND would go about changing data-structures and algorithms to take advantage MMX, SSE and wider registers, which makes those a much bigger feature request than "just build an x64 gcc output target".
Reiterating what Stephen001 said, there is very little practical benefit from a 64-bit build since most of our limitations are defined by the VM's data structures. But since linux makes compatibility a pain in the arse, we do want this or else have a better way of distributing the supporting libraries.

I have attempted to build the 64-bit in the past but, unfortunately, it fails due to some poor design on our part relating to the sizeof(pointer) (BYOND uses some very low level structure mapping). This is certainly fixable but it will require some time to track down. A higher priority regarding 64-bit is to just get the hub code to build this way (it uses an intersection of the BYOND code and has the same issues)-- since there is actual benefit for us for that. Hopefully this elucidates somewhat.
In response to Stephen001
Stephen001 wrote:
It's also worth noting that PAE comes out of the box on most distributions, similarly.

Not that this particularly alleviates the multilib concerns Murrawhip has raised, mind, which is possibly the only big benefit of a native 64 bit build.

All other benefits make an assumption that BYOND would go about changing data-structures and algorithms to take advantage MMX, SSE and wider registers, which makes those a much bigger feature request than "just build an x64 gcc output target".

Yea, I did forget to mention that with PAE.

Really though, if someone is going to deploy a BYOND server, I recommend just installing a 32-bit version of your *nix flavor of choice. Unless you're running high-performance applications requiring a 64-bit OS (highly improbable you will REQUIRE 64-bit) then you're going to have 100% compatibility with everything you run.