Is DMD 2.052 32-bit?

[Jonathan M Davis]

On Thursday, March 10, 2011 09:29:01 dsimcha wrote:
> == Quote from Jonathan M Davis (jmdavisProg at gmx.com)'s article
> 
> > Linux distros _definitely_ prefer to have native binaries, and those that
> > try and be 64-bit pure _can't_ use 32-bit binaries unless those binaries
> > are completely statically linked - though multilib is still the most
> > common scenario for 64-bit versions of most Linux distros.
> 
> Out of curiosity, what's the advantage of this purity, other than a fairly
> inconsequential amount of disk space and bandwidth savings?  32-bit can
> even be _more_ efficient for certain things because pointers are only 4
> bytes instead of 8.

Probably the biggest advantage of purity is that it simplifies the system and 
makes life easier on package management and whatnot. For multilib, you have to 
have duplicate lib directories (lib and lib32, or lib and lib64, or possibly 
even lib, lib32, _and_ lib64). You have to make sure that everything is set up 
correctly so that the 32-bit stuff is where the 32-bit stuff goes and the 64-bit 
stuff is where the 64-bit stuff goes. You have to make sure that stuff doesn't 
clash. Some stuff doesn't deal very well with having mutliple architectures on 
the same box. You have to have more versions of all of the packages that get 
duplicated. You have to maintain 32-bit versions of packages targetted for 64-
bit systems in addition to the normal 32-bit versions and the 64-bit versions of 
packages. Etc. Etc.

It's not always trivial to mix 32-bit and 64-bit on the same machine, and it 
does create a fair bit of work for those managing the distros. On some level, 
it's the same as supporting a whole other achitecture.

From the perspective of the user, while they may not have to worry about sorting 
out all of the lib directories and making sure that packages mix correctly, they 
_do_ have to worry about getting whatever 32-bit packages they need for 
something to work. As long as all you're using is distro-released packages, that 
isn't too bad, but using a 32-bit binary on a 64-bit box when you're not 
installing it with the package manager can be a pain, because you have to figure 
out exactly which packages you need for that particular binary to work. There 
have been plenty of problems with people trying to get dmd working on their 64-
bit machines. It doesn't just work out of the box.

Now, assuming that all of that is taken care, if you're using a 32-bit binary on 
a 64-bit system, you're still going to be restricted on how much that program 
can use. It doesn't use the native word size of the machine to do what it does, 
and in many cases, running a 32-bit program on a 64-bit machine is slower than 
running a 64-bit version of that program on that machine (though that's going to 
vary from program to program, since there are  obviously quite a few factors 
which affect efficiency).

And then of course, there are the people who want the purity of 64-bit for the 
sake of purity. They don't want to be running 32-bit programs in a 64-bit 
environment any more than they'd want to be running 16-bit programs in a 32-bit 
environment. They want a 64-bit machine to be running 64-bit code.

And I'm sure that there are other reasons/advantages/disadvantages, but I 
believe that the average user who is aware of the issue wants to be running 64-
bit programs on 64-bit machines, not 32-bit programs. And there _are_ a number 
of problems and disadvantages in mixing architectures and running 32-bit 
programs on 64-bit machines. It's worse for the folks maintaining a distro than 
the user of a distro, but it can be a definite issue having to deal with 32-bit 
stuff on a 64-bit box.

- Jonathan M Davis