• teo (3/3) Mar 08 2011 Is my understanding correct that dmd 2.052 itself is a 32-bit executable...
• David Nadlinger (3/6) Mar 08 2011 Yes, you're right.
• Trass3r (1/4) Mar 08 2011 Yes, but you can compile an x64 dmd yourself on Linux.
• teo (4/9) Mar 08 2011 Is there any "how to"?
• Daniel Gibson (4/15) Mar 08 2011 Download DMD as a zip, the code is included.
• Trass3r (1/3) Mar 08 2011 IIRC you have to edit linux.mak to use -m64 instead of -m32.
• Walter Bright (2/6) Mar 08 2011 It has worked in the past, but the 64 bit build is not regularly tested.
• Jason E. Aten (12/22) Mar 08 2011 When I tried this last week, changing -m32 to -m64 got me a clean 64-bit
• Daniel Gibson (3/20) Mar 09 2011 since 2.052 the -m64 flag should be supported to compile 64bit binaries
• jam (5/36) Mar 09 2011 In addition to changing the MODEL env variable in the makefiles, I also
• Russel Winder (13/21) Mar 08 2011 Sounds like there is a need for a build test farm. Buildbot or Jenkins
• Nebster (3/10) Mar 09 2011 Does the toolchain compile on windows in 64 bit too?
• Jonathan M Davis (11/23) Mar 09 2011 No. Regardless of whether you could build dmd itself as 64-bit (which is...
• Nebster (6/45) Mar 09 2011 Hehe, thanks for the response. I know about the linker but I was looking...
• Walter Bright (3/5) Mar 09 2011 What is the gain? The only thing I can think of is some 64 bit OS distri...
• Jonathan M Davis (23/29) Mar 09 2011 Well, the fact that you then have a binary native to your system is obvi...
• Gour (9/12) Mar 09 2011 +1
• Nick Sabalausky (5/49) Mar 09 2011 Specifically?
• Walter Bright (3/6) Mar 10 2011 Adding another set of binaries doubles the testing time and download tim...
• Gour (13/15) Mar 10 2011 Maybe some buildbot could be configured to automate such tasks.
• KennyTM~ (4/12) Mar 10 2011 It doubles download time only because binaries of all platforms are
• Russel Winder (15/17) Mar 10 2011 Separate them out? I would prefer not to have the Windows stuff in the
• Jonathan M Davis (20/27) Mar 10 2011 The testing time, I understand. The download times seems pretty inconseq...
• dsimcha (4/8) Mar 10 2011 Out of curiosity, what's the advantage of this purity, other than a fair...
• Jonathan M Davis (74/85) Mar 10 2011 Probably the biggest advantage of purity is that it simplifies the syste...
• Andrej Mitrovic (10/13) Mar 10 2011 Except for the fact that Walter is the only person with the legal
• Jason E. Aten (9/9) Mar 10 2011 An alternative: I would point out that LDC2 is 64-bit and open source. ...
• lurker (3/34) Mar 11 2011 I think porting DMD to 64 bits would be a pragmatic solution to this. Co...
• Jonathan M Davis (14/61) Mar 11 2011 It's not that bad. dmd has some serious memory leaks with regards to CTF...
• Don (6/40) Mar 12 2011 No. This has nothing to do with memory leaks. The slowdown and excessive...
• teo (25/30) Mar 09 2011 Ok, I wrote a simple bash script:
• Nick Sabalausky (3/12) Mar 08 2011 It's in the "src" subdirectory.
• lurker (2/9) Mar 11 2011 The efficiency claim is true. 64-bit architures have much more registers...
• Nick Sabalausky (3/23) Mar 11 2011 OTOH, 32-bit code on 64-bit already vastly outperforms 32-bit code on a
• Russel Winder (23/29) Mar 11 2011 There are a large number of assumptions in the claim of "twice as much

teo <teo.ubuntu yahoo.com> writes:

Is my understanding correct that dmd 2.052 itself is a 32-bit executable?
It can cross compile for 64-bit platforms, but is not a native 64-bit 
compiler.

David Nadlinger <see klickverbot.at> writes:

On 3/8/11 9:37 PM, teo wrote:
 Is my understanding correct that dmd 2.052 itself is a 32-bit executable?
 It can cross compile for 64-bit platforms, but is not a native 64-bit
 compiler.

Yes, you're right.

David

Trass3r <un known.com> writes:

 Is my understanding correct that dmd 2.052 itself is a 32-bit executable?
 It can cross compile for 64-bit platforms, but is not a native 64-bit
 compiler.

Yes, but you can compile an x64 dmd yourself on Linux.

teo <teo.ubuntu yahoo.com> writes:

On Tue, 08 Mar 2011 21:45:28 +0100, Trass3r wrote:

 Is my understanding correct that dmd 2.052 itself is a 32-bit
 executable? It can cross compile for 64-bit platforms, but is not a
 native 64-bit compiler.

 
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?
If not I will figure it myself out, but need to know where to get the 
source code from.

Daniel Gibson <metalcaedes gmail.com> writes:

Am 08.03.2011 22:03, schrieb teo:
 On Tue, 08 Mar 2011 21:45:28 +0100, Trass3r wrote:
 
 Is my understanding correct that dmd 2.052 itself is a 32-bit
 executable? It can cross compile for 64-bit platforms, but is not a
 native 64-bit compiler.

 Yes, but you can compile an x64 dmd yourself on Linux.

 
 Is there any "how to"?
 If not I will figure it myself out, but need to know where to get the 
 source code from.

Download DMD as a zip, the code is included.

Cheers,
- Daniel

Trass3r <un known.com> writes:

 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.

"Jason E. Aten" <j.e.aten gmail.com> writes:

On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright
<newshound2 digitalmars.com>wrote:

 On 3/8/2011 1:23 PM, Trass3r wrote:

 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 IIRC you have to edit linux.mak to use -m64 instead of -m32.

 It has worked in the past, but the 64 bit build is not regularly tested.

When I tried this last week, changing -m32 to -m64 got me a clean 64-bit
build of dmd2, with no build errors.  Very easy.

A caveat-- I tried the same search and replace s/32/64/ in places on the
druntime and phobos makefiles, but there was something more subtle going
on--the generated libraries built fine but were still 32-bit objects inside
the .a archives.  Somehow I wasn't passing the right flags to generate
64-bit libraries.

Is there a flag to tell dmd to compile to 64-bit objects?

Thanks,
Jason

Daniel Gibson <metalcaedes gmail.com> writes:

Am 09.03.2011 08:24, schrieb Jason E. Aten:
 On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

     On 3/8/2011 1:23 PM, Trass3r wrote:

                 Yes, but you can compile an x64 dmd yourself on Linux.


             Is there any "how to"?


         IIRC you have to edit linux.mak to use -m64 instead of -m32.


     It has worked in the past, but the 64 bit build is not regularly tested.


 When I tried this last week, changing -m32 to -m64 got me a clean 64-bit
 build of dmd2, with no build errors.  Very easy.

 A caveat-- I tried the same search and replace s/32/64/ in places on the
 druntime and phobos makefiles, but there was something more subtle going
 on--the generated libraries built fine but were still 32-bit objects
 inside the .a archives.  Somehow I wasn't passing the right flags to
 generate 64-bit libraries.

 Is there a flag to tell dmd to compile to 64-bit objects?

 Thanks,
 Jason

since 2.052 the -m64 flag should be supported to compile 64bit binaries 
(on Linux).

jam <gr0v3er+d gmail.com> writes:

On Wed, 09 Mar 2011 01:24:56 -0600, Jason E. Aten wrote:

 On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:
 
 On 3/8/2011 1:23 PM, Trass3r wrote:

 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 IIRC you have to edit linux.mak to use -m64 instead of -m32.

 It has worked in the past, but the 64 bit build is not regularly
 tested.

 When I tried this last week, changing -m32 to -m64 got me a clean 64-bit
 build of dmd2, with no build errors.  Very easy.
 
 A caveat-- I tried the same search and replace s/32/64/ in places on the
 druntime and phobos makefiles, but there was something more subtle going
 on--the generated libraries built fine but were still 32-bit objects
 inside the .a archives.  Somehow I wasn't passing the right flags to
 generate 64-bit libraries.
 
 Is there a flag to tell dmd to compile to 64-bit objects?
 
 Thanks,
 Jason

In addition to changing the MODEL env variable in the makefiles, I also 
had to pass the -m64 flag to the dmd binary to build x64 libphobos.a and 
libdruntime.a

i.e. make -f posix.mak DMD="PATH_TO_DMD -m64"

Russel Winder <russel russel.org.uk> writes:

On Tue, 2011-03-08 at 22:55 -0800, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 IIRC you have to edit linux.mak to use -m64 instead of -m32.

=20
 It has worked in the past, but the 64 bit build is not regularly tested.

Sounds like there is a need for a build test farm.  Buildbot or Jenkins
would provide good infrastructure.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Nebster <Evil.Nebster gmail.com> writes:

On 09/03/2011 06:55, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 IIRC you have to edit linux.mak to use -m64 instead of -m32.

 It has worked in the past, but the 64 bit build is not regularly tested.

Does the toolchain compile on windows in 64 bit too?
It's awesome you're finally starting the transition :)

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Wednesday, March 09, 2011 16:23:15 Nebster wrote:
 On 09/03/2011 06:55, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

 
 Is there any "how to"?

 
 IIRC you have to edit linux.mak to use -m64 instead of -m32.

 
 It has worked in the past, but the 64 bit build is not regularly tested.

 
 Does the toolchain compile on windows in 64 bit too?
 It's awesome you're finally starting the transition :)

No. Regardless of whether you could build dmd itself as 64-bit (which is 
questionable), the linker is only 32-bit, and since it's written in assembly, 
you _definitely_ can't compile that as 64-bit. So, you don't have 64-bit on 
Windows - either the dmd binary or the binaries that it produces. And honestly, 
I'd be _very_ leery - make that _extremely leery - of using a 64-bit build of 
dmd on _any_ OS before Walter actually makes sure that it works as 64-bit and 
maintains it as such.

Much as I'd love to have a 64-bit binary of dmd, I don't think that the gain is 
even vaguely worth the risk at this point.

- Jonathan M Davis

Nebster <Evil.Nebster gmail.com> writes:

On 10/03/2011 00:30, Jonathan M Davis wrote:
 On Wednesday, March 09, 2011 16:23:15 Nebster wrote:
 On 09/03/2011 06:55, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 IIRC you have to edit linux.mak to use -m64 instead of -m32.

 It has worked in the past, but the 64 bit build is not regularly tested.

 Does the toolchain compile on windows in 64 bit too?
 It's awesome you're finally starting the transition :)

 No. Regardless of whether you could build dmd itself as 64-bit (which is
 questionable), the linker is only 32-bit, and since it's written in assembly,
 you _definitely_ can't compile that as 64-bit. So, you don't have 64-bit on
 Windows - either the dmd binary or the binaries that it produces. And honestly,
 Path: digitalmars.com!not-for-mail
 From: Sean Kelly<sean f4.ca>
 Newsgroups: digitalmars.D
 Subject: Re: If D becomes a failure, what's the key reason, do you think?
 Date: Fri, 07 Jul 2006 13:17:17 -0700
 Organization: Digital Mars
 Lines: 5
 Message-ID:<e8mfgd$1hqe$1 digitaldaemon.com>
 References:<e8khb5$160j$1 digitaldaemon.com> 
<e8klm3$1b23$1 digitaldaemon.com>  <e8kp39$1fol$1 digitaldaemon.com> 
<e8l426$26o3$1 digitaldaemon.com>  <e8m6pv$15bp$1 digitaldaemon.com> 
<e8m9m3$19t5$1 digitaldaemon.com>  <e8mbuv$1cm4$1 digitaldaemon.com> 
<e8meq3$1go2$2 digitaldaemon.com>
 Mime-Version: 1.0
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 X-Trace: digitaldaemon.com 1152303437 51022 216.127.61.99 (7 Jul 2006 20:17:17
GMT)
 X-Complaints-To: usenet digitalmars.com
 NNTP-Posting-Date: Fri, 7 Jul 2006 20:17:17 +0000 (UTC)
 User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
 In-Reply-To:<e8meq3$1go2$2 digitaldaemon.com>
 Xref: digitalmars.com digitalmars.D:39708

 Walter Bright wrote:
 Not for 1.0.

 Thanks :-)

Hehe, thanks for the response. I know about the linker but I was looking 
into the new version of UniLink which has support for D now afaik!

It's not that much of a problem for me at the moment anyway :)

Thanks,
Nebster

Walter Bright <newshound2 digitalmars.com> writes:

On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the gain is
 even vaguely worth the risk at this point.

What is the gain? The only thing I can think of is some 64 bit OS distributions 
are hostile to 32 bit binaries.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

 
 What is the gain? The only thing I can think of is some 64 bit OS
 distributions are hostile to 32 bit binaries.

Well, the fact that you then have a binary native to your system is obviously a 
gain (and is likely the one which people will cite most often), and that _does_ 
count for quite a lot. However, regardless of that, it's actually pretty easy
to 
get dmd to run out of memory when compiling if you do much in the way of CTFE
or 
template stuff. Granted, fixing some of the worst memory-related bugs in dmd
will 
go a _long_ way towards fixing that, but even if they are, you're theoretically 
eventually supposed to be able to do pretty much anything at compile time which 
you can do at runtime in SafeD. And using enough memory that you require the 64-
bit address space would be one of the things that you can do in SafeD when 
compiling for 64-bit. As long as the compiler is only 32-bit, you can't do that 
at compile time even though you can do it at runtime (though the current 
limitations of CTFE do reduce the problem in that you can't do a lot of stuff
at 
compile time period).

In any case, the fact that dmd runs out of memory fairly easily makes having a 
64-bit version which could use all of my machine's memory really attractive.
And 
honestly, having an actual, 64-bit binary to run on a 64-bit system is
something 
that people generally want, and it _is_ definitely a problem to get a 32-bit 
binary into the 64-bit release of a Liunx distro.

Truth be told, I would have thought that it would be a given that there would
be 
a 64-bit version of dmd when going to support 64-bit compilation and was quite 
surprised when that was not your intention.

- Jonathan M Davis

Gour <gour atmarama.net> writes:

On Wed, 9 Mar 2011 19:08:04 -0800
Jonathan M Davis <jmdavisProg gmx.com> wrote:


 Truth be told, I would have thought that it would be a given that
 there would be a 64-bit version of dmd when going to support 64-bit
 compilation and was quite surprised when that was not your intention.

+1


Sincerely,
Gour

--=20
=E2=80=9CIn the material world, conceptions of good and bad are
all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA

"Nick Sabalausky" <a a.a> writes:

"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2408.1299726495.4748.digitalmars-d puremagic.com...
 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

 What is the gain? The only thing I can think of is some 64 bit OS
 distributions are hostile to 32 bit binaries.

 Well, the fact that you then have a binary native to your system is 
 obviously a
 gain (and is likely the one which people will cite most often), and that 
 _does_
 count for quite a lot.

Specifically?

 However, regardless of that, it's actually pretty easy to
 get dmd to run out of memory when compiling if you do much in the way of 
 CTFE or
 template stuff. Granted, fixing some of the worst memory-related bugs in 
 dmd will
 go a _long_ way towards fixing that, but even if they are, you're 
 theoretically
 eventually supposed to be able to do pretty much anything at compile time 
 which
 you can do at runtime in SafeD. And using enough memory that you require 
 the 64-
 bit address space would be one of the things that you can do in SafeD when
 compiling for 64-bit. As long as the compiler is only 32-bit, you can't do 
 that
 at compile time even though you can do it at runtime (though the current
 limitations of CTFE do reduce the problem in that you can't do a lot of 
 stuff at
 compile time period).

 In any case, the fact that dmd runs out of memory fairly easily makes 
 having a
 64-bit version which could use all of my machine's memory really 
 attractive. And
 honestly, having an actual, 64-bit binary to run on a 64-bit system is 
 something
 that people generally want, and it _is_ definitely a problem to get a 
 32-bit
 binary into the 64-bit release of a Liunx distro.

 Truth be told, I would have thought that it would be a given that there 
 would be
 a 64-bit version of dmd when going to support 64-bit compilation and was 
 quite
 surprised when that was not your intention.

I'd be more interested in a build of DMD that just doesn't eat memory like 
popcorn.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/9/2011 7:08 PM, Jonathan M Davis wrote:
 Truth be told, I would have thought that it would be a given that there would
be
 a 64-bit version of dmd when going to support 64-bit compilation and was quite
 surprised when that was not your intention.

Adding another set of binaries doubles the testing time and download times for 
users.

Gour <gour atmarama.net> writes:

On Thu, 10 Mar 2011 01:57:37 -0800
Walter Bright <newshound2 digitalmars.com> wrote:

 Adding another set of binaries doubles the testing time and download
 times for users.

Maybe some buildbot could be configured to automate such tasks.

Download time is, imho, not significant obstacle to have 64bit
release.

Actually, I do not know about any 32bit compiler which goes 64bit code
generation...all of 'em have native binaries...


Sincerely,
Gour

--=20
=E2=80=9CIn the material world, conceptions of good and bad are
all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA

KennyTM~ <kennytm gmail.com> writes:

On Mar 10, 11 17:57, Walter Bright wrote:
 On 3/9/2011 7:08 PM, Jonathan M Davis wrote:
 Truth be told, I would have thought that it would be a given that
 there would be
 a 64-bit version of dmd when going to support 64-bit compilation and
 was quite
 surprised when that was not your intention.

 Adding another set of binaries doubles the testing time and download
 times for users.

It doubles download time only because binaries of all platforms are 
packed into one zip file. ;)

(Not that I think 64-bit dmd is needed.)

Russel Winder <russel russel.org.uk> writes:

On Thu, 2011-03-10 at 21:19 +0800, KennyTM~ wrote:
[ . . . ]
 It doubles download time only because binaries of all platforms are=20
 packed into one zip file. ;)

Separate them out?  I would prefer not to have the Windows stuff in the
download pack.

[ . . . ]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday 10 March 2011 01:57:37 Walter Bright wrote:
 On 3/9/2011 7:08 PM, Jonathan M Davis wrote:
 Truth be told, I would have thought that it would be a given that there
 would be a 64-bit version of dmd when going to support 64-bit
 compilation and was quite surprised when that was not your intention.

 
 Adding another set of binaries doubles the testing time and download times
 for users.

The testing time, I understand. The download times seems pretty inconsequential 
to me and not a big deal at all (and as Gour points out, you could have
separate 
zip files for separate architectures). However, it's a given that people are 
going to want a full 64-bit binary and to some extent will expect it. It's not 
at all normal to produce 64-bit binaries from a 32-bit compiler. Obviously such 
cross-compiling _can_ be done and sometimes is, but it's not at all the norm, 
and the more naive folks probably don't even think that you can do that, so 
having a 32-bit binary produce 64-bit code will confuse the less experienced.

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. Still, they lean heavily towards 64-bit and 
generally try to use absolutely as little 32-bit as possible.

So, having a 32-bit binary produce 64-bit binaries works, and it's better than 
having no 64-bit support, but in the long run, it really is preferable to have
a 
64-bit binary for dmd. I understand if that's not exactly a high priority at
the 
moment (and I agree that there are more important issues), but I would still 
expect that we'd get a 64-bit dmd binary eventually.

- Jonathan M Davis

dsimcha <dsimcha yahoo.com> writes:

== Quote from Jonathan M Davis (jmdavisProg 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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, March 10, 2011 09:29:01 dsimcha wrote:
 =3D=3D Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
=20
 Linux distros _definitely_ prefer to have native binaries, and those th=


at
 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.

=20
 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 a=
nd=20
makes life easier on package management and whatnot. For multilib, you have=
 to=20
have duplicate lib directories (lib and lib32, or lib and lib64, or possibl=
y=20
even lib, lib32, _and_ lib64). You have to make sure that everything is set=
 up=20
correctly so that the 32-bit stuff is where the 32-bit stuff goes and the 6=
4-bit=20
stuff is where the 64-bit stuff goes. You have to make sure that stuff does=
n't=20
clash. Some stuff doesn't deal very well with having mutliple architectures=
 on=20
the same box. You have to have more versions of all of the packages that ge=
t=20
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 versio=
ns of=20
packages. Etc. Etc.

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

=46rom the perspective of the user, while they may not have to worry about =
sorting=20
out all of the lib directories and making sure that packages mix correctly,=
 they=20
_do_ have to worry about getting whatever 32-bit packages they need for=20
something to work. As long as all you're using is distro-released packages,=
 that=20
isn't too bad, but using a 32-bit binary on a 64-bit box when you're not=20
installing it with the package manager can be a pain, because you have to f=
igure=20
out exactly which packages you need for that particular binary to work. The=
re=20
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 bina=
ry on=20
a 64-bit system, you're still going to be restricted on how much that progr=
am=20
can use. It doesn't use the native word size of the machine to do what it d=
oes,=20
and in many cases, running a 32-bit program on a 64-bit machine is slower t=
han=20
running a 64-bit version of that program on that machine (though that's goi=
ng to=20
vary from program to program, since there are  obviously quite a few factor=
s=20
which affect efficiency).

And then of course, there are the people who want the purity of 64-bit for =
the=20
sake of purity. They don't want to be running 32-bit programs in a 64-bit=20
environment any more than they'd want to be running 16-bit programs in a 32=
=2Dbit=20
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=20
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 num=
ber=20
of problems and disadvantages in mixing architectures and running 32-bit=20
programs on 64-bit machines. It's worse for the folks maintaining a distro =
than=20
the user of a distro, but it can be a definite issue having to deal with 32=
=2Dbit=20
stuff on a 64-bit box.

=2D Jonathan M Davis

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 3/10/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 The download times seems pretty
 inconsequential
 to me and not a big deal at all.

Except for the fact that Walter is the only person with the legal
right to distribute DMD + downloading is slow from digitalmars.com. I
get around ~100Kb/sec average and often times much slower download
speeds even though my download speed easily reaches 500Kb/sec on other
websites.

What will happen when D gets more popular? The site will likely slow
down to a crawl. I'm saying we'll eventually need mirrors to download
from, but this isn't going to happen with the current legal
shenanigans.

"Jason E. Aten" <j.e.aten gmail.com> writes:

An alternative: I would point out that LDC2 is 64-bit and open source.  It
lets you target a multitude of architectures, including, recently, OpenCL
for GPGPU.  Heck, you might even be able to cross compile from Linux and
target your system of choice.

So if you really want 64-bit support for platform X, you could likely add it
to LDC2 without too much work.

Jason

-- 
Jason E. Aten, Ph.D.

lurker <a a.a> writes:

Jonathan M Davis Wrote:

 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

 
 What is the gain? The only thing I can think of is some 64 bit OS
 distributions are hostile to 32 bit binaries.

 
 Well, the fact that you then have a binary native to your system is obviously
a 
 gain (and is likely the one which people will cite most often), and that
_does_ 
 count for quite a lot. However, regardless of that, it's actually pretty easy
to 
 get dmd to run out of memory when compiling if you do much in the way of CTFE
or 
 template stuff. Granted, fixing some of the worst memory-related bugs in dmd
will 
 go a _long_ way towards fixing that, but even if they are, you're
theoretically 
 eventually supposed to be able to do pretty much anything at compile time
which 
 you can do at runtime in SafeD. And using enough memory that you require the
64-
 bit address space would be one of the things that you can do in SafeD when 
 compiling for 64-bit. As long as the compiler is only 32-bit, you can't do
that 
 at compile time even though you can do it at runtime (though the current 
 limitations of CTFE do reduce the problem in that you can't do a lot of stuff
at 
 compile time period).
 
 In any case, the fact that dmd runs out of memory fairly easily makes having a 
 64-bit version which could use all of my machine's memory really attractive.
And 
 honestly, having an actual, 64-bit binary to run on a 64-bit system is
something 
 that people generally want, and it _is_ definitely a problem to get a 32-bit 
 binary into the 64-bit release of a Liunx distro.
 
 Truth be told, I would have thought that it would be a given that there would
be 
 a 64-bit version of dmd when going to support 64-bit compilation and was quite 
 surprised when that was not your intention.

I think porting DMD to 64 bits would be a pragmatic solution to this. Computers
are getting more memory faster than Walter is able to fix possible leaks in
DMD. There's awful lots of template and CTFE code using more than 2 or 3 GB of
RAM. I can't even imagine how one could develop some modern application if this
was a hard limit. Luckily there are GDC and LDC, which allow enterprise users
to take full advantage of the 24-64 GB available.

Some simple use case would be Facebook's infrastructure. Assume Andrei wanted
to rewrite it all in D. Probably more than 100M LOC. Would need hundreds of
gigabytes of RAM to compile. It would also take days to compile, and maybe 50%
less on a 64 bit system.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, March 11, 2011 13:11:53 lurker wrote:
 Jonathan M Davis Wrote:
 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that
 the gain is even vaguely worth the risk at this point.

 
 What is the gain? The only thing I can think of is some 64 bit OS
 distributions are hostile to 32 bit binaries.

 
 Well, the fact that you then have a binary native to your system is
 obviously a gain (and is likely the one which people will cite most
 often), and that _does_ count for quite a lot. However, regardless of
 that, it's actually pretty easy to get dmd to run out of memory when
 compiling if you do much in the way of CTFE or template stuff. Granted,
 fixing some of the worst memory-related bugs in dmd will go a _long_ way
 towards fixing that, but even if they are, you're theoretically
 eventually supposed to be able to do pretty much anything at compile
 time which you can do at runtime in SafeD. And using enough memory that
 you require the 64- bit address space would be one of the things that
 you can do in SafeD when compiling for 64-bit. As long as the compiler
 is only 32-bit, you can't do that at compile time even though you can do
 it at runtime (though the current limitations of CTFE do reduce the
 problem in that you can't do a lot of stuff at compile time period).
 
 In any case, the fact that dmd runs out of memory fairly easily makes
 having a 64-bit version which could use all of my machine's memory
 really attractive. And honestly, having an actual, 64-bit binary to run
 on a 64-bit system is something that people generally want, and it _is_
 definitely a problem to get a 32-bit binary into the 64-bit release of a
 Liunx distro.
 
 Truth be told, I would have thought that it would be a given that there
 would be a 64-bit version of dmd when going to support 64-bit
 compilation and was quite surprised when that was not your intention.

 
 I think porting DMD to 64 bits would be a pragmatic solution to this.
 Computers are getting more memory faster than Walter is able to fix
 possible leaks in DMD. There's awful lots of template and CTFE code using
 more than 2 or 3 GB of RAM. I can't even imagine how one could develop
 some modern application if this was a hard limit. Luckily there are GDC
 and LDC, which allow enterprise users to take full advantage of the 24-64
 GB available.
 
 Some simple use case would be Facebook's infrastructure. Assume Andrei
 wanted to rewrite it all in D. Probably more than 100M LOC. Would need
 hundreds of gigabytes of RAM to compile. It would also take days to
 compile, and maybe 50% less on a 64 bit system.

It's not that bad. dmd has some serious memory leaks with regards to CTFE and 
templates in that it generally doesn't release memory for a lot of it until
it's 
done. So, it uses _way_ more memory that it needs to. I don't know why it does 
things the way it does, but theoretically, it should be able to reduce that to 
sane levels on 32-bit. I expect that it just requires taking the time to do it.

Also, in most cases, if using too much memory due to CTFE or templates is a 
problem, then all you have to do is do incremental builds and build each module 
separately. Then you're usually fine.

So, while having a 64-bit dmd would definitely help alleviate dmd's memory 
issues, those memory issues _do_ need to be fixed regardless. And fixing them 
would almost certainly make it dmd's memory consumption acceptable with 32-bit 
in most cases.

- Jonathan M Davis

Don <nospam nospam.com> writes:

lurker wrote:
 Jonathan M Davis Wrote:
 
 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

 What is the gain? The only thing I can think of is some 64 bit OS
 distributions are hostile to 32 bit binaries.

 Well, the fact that you then have a binary native to your system is obviously
a 
 gain (and is likely the one which people will cite most often), and that
_does_ 
 count for quite a lot. However, regardless of that, it's actually pretty easy
to 
 get dmd to run out of memory when compiling if you do much in the way of CTFE
or 
 template stuff. Granted, fixing some of the worst memory-related bugs in dmd
will 
 go a _long_ way towards fixing that, but even if they are, you're
theoretically 
 eventually supposed to be able to do pretty much anything at compile time
which 
 you can do at runtime in SafeD. And using enough memory that you require the
64-
 bit address space would be one of the things that you can do in SafeD when 
 compiling for 64-bit. As long as the compiler is only 32-bit, you can't do
that 
 at compile time even though you can do it at runtime (though the current 
 limitations of CTFE do reduce the problem in that you can't do a lot of stuff
at 
 compile time period).

 In any case, the fact that dmd runs out of memory fairly easily makes having a 
 64-bit version which could use all of my machine's memory really attractive.
And 
 honestly, having an actual, 64-bit binary to run on a 64-bit system is
something 
 that people generally want, and it _is_ definitely a problem to get a 32-bit 
 binary into the 64-bit release of a Liunx distro.

 Truth be told, I would have thought that it would be a given that there would
be 
 a 64-bit version of dmd when going to support 64-bit compilation and was quite 
 surprised when that was not your intention.

 
 I think porting DMD to 64 bits would be a pragmatic solution to this. 

 Computers are getting more memory faster than Walter is able to fix possible
leaks in DMD.

No. This has nothing to do with memory leaks. The slowdown and excessive 
memory consumption is caused by a few lines of code. Fixing that 'bug' 
(really, the existing CTFE memory management (ie, non-existent!) was a 
quick hack to get things running) won't just make it consume 2 or 3 
times less memory. We're talking 100x, 1000x, etc.

teo <teo.ubuntu yahoo.com> writes:

On Tue, 08 Mar 2011 22:23:19 +0100, Trass3r wrote:

 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?

 
 IIRC you have to edit linux.mak to use -m64 instead of -m32.

Ok, I wrote a simple bash script:
===BEGIN===


echo "building dmd..."
cd ./dmd
make -f linux.mak MODEL=-m64
cd ..

if [ ! -f ./dmd/dmd ]
then
  echo "failed."
  exit 1
fi

echo "building druntime..."
cd ./druntime
make -f posix.mak MODEL=64 DMD=../dmd/dmd
cd ..

echo "building phobos..."
cd ./phobos
make -f posix.mak MODEL=64 DMD=../dmd/dmd
cd ..
===END===
You have to put it in dmd2/src.

I got a clean build on Ubuntu 10.04 x86_64 with GCC 4.4.3 and GNU Make 
3.81.

"Nick Sabalausky" <a a.a> writes:

"teo" <teo.ubuntu yahoo.com> wrote in message 
news:il65ip$1cl8$1 digitalmars.com...
 On Tue, 08 Mar 2011 21:45:28 +0100, Trass3r wrote:

 Is my understanding correct that dmd 2.052 itself is a 32-bit
 executable? It can cross compile for 64-bit platforms, but is not a
 native 64-bit compiler.

 Yes, but you can compile an x64 dmd yourself on Linux.

 Is there any "how to"?
 If not I will figure it myself out, but need to know where to get the
 source code from.

It's in the "src" subdirectory.

lurker <a a.a> writes:

Jonathan M Davis Wrote:

 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).

The efficiency claim is true. 64-bit architures have much more registers. This
can effectively double the code's performance in most cases. Loads and stores
can also use full 64 bits of bandwidth instead of 32. Thus again twice as much
speed. In general if you worry about larger binary size, use UPX. Other than
that, 64 bit code outperforms the 32 bit. We want to keep the fastest compiler
title, right?

"Nick Sabalausky" <a a.a> writes:

"lurker" <a a.a> wrote in message news:ile2kg$2klo$1 digitalmars.com...
 Jonathan M Davis Wrote:

 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).

 The efficiency claim is true. 64-bit architures have much more registers. 
 This can effectively double the code's performance in most cases. Loads 
 and stores can also use full 64 bits of bandwidth instead of 32. Thus 
 again twice as much speed. In general if you worry about larger binary 
 size, use UPX. Other than that, 64 bit code outperforms the 32 bit. We 
 want to keep the fastest compiler title, right?

OTOH, 32-bit code on 64-bit already vastly outperforms 32-bit code on a 
32-bit machine anyway.

Russel Winder <russel russel.org.uk> writes:

On Fri, 2011-03-11 at 16:02 -0500, lurker wrote:
[ . . . ]
 The efficiency claim is true. 64-bit architures have much more
 registers. This can effectively double the code's performance in most
 cases. Loads and stores can also use full 64 bits of bandwidth instead
 of 32. Thus again twice as much speed. In general if you worry about
 larger binary size, use UPX. Other than that, 64 bit code outperforms
 the 32 bit. We want to keep the fastest compiler title, right?

There are a large number of assumptions in the claim of "twice as much
speed".  All the AMD64 registers and ALUs are 64-bit wide but are all
the caches?  Are all the buses to memory?  Are all the memory
structures?  Is the clock speed the same?  Are all the components
clocked in the same way?

Has anyone got actual experimental data?  Is there a benchmark suite?

My preference for a 64-bit DMD relate to simplicity of use on Debian and
Ubuntu where the packaging is far simpler if 64-bit executables are used
throughout -- if those executables are dynamically linked.  If they are
statically linked there is not the same issues, but then physical size
of executable becomes an issue.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder