www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 64-bit

reply Just Visiting <nospam aol.com> writes:
Last things I remember:

- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux x86_64

The ideas behind DmD looked promising to me. But most of my programs showed at
least a 2-fold performance increase once they were re-written for 64-bit.
Therefore 32-bit compilers are just wasting my time, and this is why I've lost
track of DmD.

After a certain waiting period I'd now like to know from the well informed
amongst you if there are any indications that DmD will eventually evolve to
support current CPU architectures?

Thanks.
Oct 17 2009
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Currently:

LDC is a mature compiler that does linux 64 bit well, but is not available 
for D2, the 'alpha' branch of the language and also doesn't work on windows.

The outdated compiler you speak of would probably be GDC, this project has 
recently been revived. The is no 64-bit dmd yet.

At the moment all efforts I believe are on finishing the D2 language and 
current dmd bugs, as well as a book called 'The D programming language'. 
IIRC the deadline is somewhere end of this year.

What happens after that I don't know, I haven't seen any statement that work 
on 64-bit is planned. I would rather bet on GDC and / or LDC getting full 
64-but support for D2 before dmd.
Oct 17 2009
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Lutger wrote:
 Currently:
 
 LDC is a mature compiler that does linux 64 bit well, but is not available 
 for D2, the 'alpha' branch of the language and also doesn't work on windows.

LDC works on Windows, except for exception handling. Which is probably a deal breaker for most people.
Oct 17 2009
parent BCS <none anon.com> writes:
Hello Christopher,

 Lutger wrote:
 
 Currently:
 
 LDC is a mature compiler that does linux 64 bit well, but is not
 available for D2, the 'alpha' branch of the language and also doesn't
 work on windows.
 

a deal breaker for most people.

IIRC that's an LLVM issue, not a LDC one. Is anyone pussing on the LLVM end to get it fixed?
Oct 17 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Lutger (lutger.blijdestijn gmail.com)'s article
 Currently:
 LDC is a mature compiler that does linux 64 bit well, but is not available
 for D2, the 'alpha' branch of the language and also doesn't work on windows.
 The outdated compiler you speak of would probably be GDC, this project has
 recently been revived. The is no 64-bit dmd yet.
 At the moment all efforts I believe are on finishing the D2 language and
 current dmd bugs, as well as a book called 'The D programming language'.
 IIRC the deadline is somewhere end of this year.
 What happens after that I don't know, I haven't seen any statement that work
 on 64-bit is planned. I would rather bet on GDC and / or LDC getting full
 64-but support for D2 before dmd.

Where has GDC been revived? It doesn't look like there have been any checkins on the sourceforge site since Feb.
Oct 17 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
dsimcha wrote:

 == Quote from Lutger (lutger.blijdestijn gmail.com)'s article
 Currently:
 LDC is a mature compiler that does linux 64 bit well, but is not
 available for D2, the 'alpha' branch of the language and also doesn't
 work on windows. The outdated compiler you speak of would probably be
 GDC, this project has recently been revived. The is no 64-bit dmd yet.
 At the moment all efforts I believe are on finishing the D2 language and
 current dmd bugs, as well as a book called 'The D programming language'.
 IIRC the deadline is somewhere end of this year.
 What happens after that I don't know, I haven't seen any statement that
 work on 64-bit is planned. I would rather bet on GDC and / or LDC getting
 full 64-but support for D2 before dmd.

Where has GDC been revived? It doesn't look like there have been any checkins on the sourceforge site since Feb.

It has forked to http://bitbucket.org/goshawk/gdc/wiki/Home See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=D.gnu&article_id=3516
Oct 17 2009
prev sibling next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Just Visiting wrote:
 Last things I remember:
 
 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux x86_64
 
 The ideas behind DmD looked promising to me. But most of my programs showed at
least a 2-fold performance increase once they were re-written for 64-bit.
Therefore 32-bit compilers are just wasting my time, and this is why I've lost
track of DmD.
 
 After a certain waiting period I'd now like to know from the well informed
amongst you if there are any indications that DmD will eventually evolve to
support current CPU architectures?
 
 Thanks.
 

I believe 64bit support is on Walter's todo list after the spec for D2 is finished.
Oct 17 2009
parent reply Nick B <nickB gmail.com> writes:
Jeremie Pelletier wrote:
 Just Visiting wrote:
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux 
 x86_64

 The ideas behind DmD looked promising to me. But most of my programs 
 showed at least a 2-fold performance increase once they were 
 re-written for 64-bit. Therefore 32-bit compilers are just wasting my 
 time, and this is why I've lost track of DmD.

 After a certain waiting period I'd now like to know from the well 
 informed amongst you if there are any indications that DmD will 
 eventually evolve to support current CPU architectures?

 Thanks.

I believe 64bit support is on Walter's todo list after the spec for D2 is finished.

I too remember this statement by Walter, but I can't find his post to prove it. So it (64-bit) can't be too far away. Nick B
Oct 17 2009
parent reply Nick B <nickB gmail.com> writes:
Nick B wrote:
 Jeremie Pelletier wrote:
 Just Visiting wrote:
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux 
 x86_64

 The ideas behind DmD looked promising to me. But most of my programs 
 showed at least a 2-fold performance increase once they were 
 re-written for 64-bit. Therefore 32-bit compilers are just wasting my 
 time, and this is why I've lost track of DmD.

 After a certain waiting period I'd now like to know from the well 
 informed amongst you if there are any indications that DmD will 
 eventually evolve to support current CPU architectures?

 Thanks.

I believe 64bit support is on Walter's todo list after the spec for D2 is finished.

I too remember this statement by Walter, but I can't find his post to prove it. So it (64-bit) can't be too far away.

Correction. I have found the post. Date 11/08/2008 Subject : Re: Some questions about dmd development Question from Alexey:
 3. Are there any plans to support 64-bits system? And if it is, when?

Walters reply: Yes, after D2 is done. cheers Nick B
Oct 17 2009
parent reply Just Visiting <nospam aol.com> writes:
Nick B Wrote:

 Nick B wrote:
 Jeremie Pelletier wrote:
 Just Visiting wrote:
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux 
 x86_64

 The ideas behind DmD looked promising to me. But most of my programs 
 showed at least a 2-fold performance increase once they were 
 re-written for 64-bit. Therefore 32-bit compilers are just wasting my 
 time, and this is why I've lost track of DmD.

 After a certain waiting period I'd now like to know from the well 
 informed amongst you if there are any indications that DmD will 
 eventually evolve to support current CPU architectures?

 Thanks.

I believe 64bit support is on Walter's todo list after the spec for D2 is finished.

I too remember this statement by Walter, but I can't find his post to prove it. So it (64-bit) can't be too far away.

Correction. I have found the post. Date 11/08/2008 Subject : Re: Some questions about dmd development Question from Alexey: > 3. Are there any plans to support 64-bits system? And if it is, when? Walters reply: Yes, after D2 is done. cheers Nick B

That is all I needed to know. Thank you.
Oct 17 2009
parent reply Nick B <nickB gmail.com> writes:
Just Visiting wrote:
 Nick B Wrote:
 
 Nick B wrote:
 Jeremie Pelletier wrote:
 Just Visiting wrote:
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux 
 x86_64

 The ideas behind DmD looked promising to me. But most of my programs 
 showed at least a 2-fold performance increase once they were 
 re-written for 64-bit. Therefore 32-bit compilers are just wasting my 
 time, and this is why I've lost track of DmD.

 After a certain waiting period I'd now like to know from the well 
 informed amongst you if there are any indications that DmD will 
 eventually evolve to support current CPU architectures?

 Thanks.

is finished.

prove it. So it (64-bit) can't be too far away.

Date 11/08/2008 Subject : Re: Some questions about dmd development Question from Alexey: > 3. Are there any plans to support 64-bits system? And if it is, when? Walters reply: Yes, after D2 is done. cheers Nick B

That is all I needed to know. Thank you.

One more correction. The date I mention for Walter post is incorrect. It is in fact 11/08/2009 8:49 a.m. To "Just Visting", no problem. Nick B
Oct 17 2009
parent BCS <none anon.com> writes:
Hello Nick,

 One more correction.  The date I mention for Walter post is incorrect.
 It is in fact 11/08/2009 8:49 a.m.

For us yanks that would be 08/11/2009
 
 To "Just Visting", no problem.
 
 Nick B
 

Oct 18 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
dsimcha, el 17 de octubre a las 14:19 me escribiste:
 == Quote from Lutger (lutger.blijdestijn gmail.com)'s article
 Currently:
 LDC is a mature compiler that does linux 64 bit well, but is not available
 for D2, the 'alpha' branch of the language and also doesn't work on windows.
 The outdated compiler you speak of would probably be GDC, this project has
 recently been revived. The is no 64-bit dmd yet.
 At the moment all efforts I believe are on finishing the D2 language and
 current dmd bugs, as well as a book called 'The D programming language'.
 IIRC the deadline is somewhere end of this year.
 What happens after that I don't know, I haven't seen any statement that work
 on 64-bit is planned. I would rather bet on GDC and / or LDC getting full
 64-but support for D2 before dmd.

Where has GDC been revived? It doesn't look like there have been any checkins on the sourceforge site since Feb.

http://bitbucket.org/goshawk/gdc/ -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- You look so tired-unhappy, bring down the government, they don't, they don't speak for us.
Oct 17 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Just Visiting" <nospam aol.com> wrote in message 
news:hbcbvs$1ees$1 digitalmars.com...
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux x86_64

 The ideas behind DmD looked promising to me. But most of my programs 
 showed at least a 2-fold performance increase once they were re-written 
 for 64-bit.

Only on 64-bit systems. Which are already ridiculously fast anyway. So what if they get some more performance? They already have gobs of performance to spare. On a 32-bit system it changes the programs performance down to "It don't f** work at all", which is the mark of an incredibly arrogant developer who likes to shoot themself in the foot by arbitrarily shrinking their own potential user base.
 Therefore 32-bit compilers are just wasting my time, and this is why I've 
 lost track of DmD.

They should make roads that are only usable by Italian sports cars, and take full advantage of their special characteristics. Any other roads are just wasting my time.
Oct 17 2009
next sibling parent BCS <none anon.com> writes:
Hello Nick,

 "Just Visiting" <nospam aol.com> wrote in message
 news:hbcbvs$1ees$1 digitalmars.com...
 
 Last things I remember:
 
 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux
 x86_64
 The ideas behind DmD looked promising to me. But most of my programs
 showed at least a 2-fold performance increase once they were
 re-written for 64-bit.
 

what if they get some more performance? They already have gobs of performance to spare. On a 32-bit system it changes the programs performance down to "It don't f** work at all", which is the mark of an incredibly arrogant developer who likes to shoot themself in the foot by arbitrarily shrinking their own potential user base.

best option, build the language (and the apps) so that they compile on either and ship both.
Oct 17 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 17/10/2009 22:11, Nick Sabalausky wrote:
 "Just Visiting"<nospam aol.com>  wrote in message
 news:hbcbvs$1ees$1 digitalmars.com...
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux x86_64

 The ideas behind DmD looked promising to me. But most of my programs
 showed at least a 2-fold performance increase once they were re-written
 for 64-bit.

Only on 64-bit systems. Which are already ridiculously fast anyway. So what if they get some more performance? They already have gobs of performance to spare. On a 32-bit system it changes the programs performance down to "It don't f** work at all", which is the mark of an incredibly arrogant developer who likes to shoot themself in the foot by arbitrarily shrinking their own potential user base.
 Therefore 32-bit compilers are just wasting my time, and this is why I've
 lost track of DmD.

They should make roads that are only usable by Italian sports cars, and take full advantage of their special characteristics. Any other roads are just wasting my time.

those are *fine* cars, aren't they? but seriously, your argument is ridiculously wrong since velocity is dependent on the observer. the OP said and I quote: "32-bit compilers are just wasting *my* time" (emphasis added).
Oct 17 2009
parent "Nick Sabalausky" <a a.a> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:hbd9d5$245o$1 digitalmars.com...
 On 17/10/2009 22:11, Nick Sabalausky wrote:
 They should make roads that are only usable by Italian sports cars, and 
 take
 full advantage of their special characteristics. Any other roads are just
 wasting my time.

those are *fine* cars, aren't they?

I only wish I could answer from first-hand experience ;) (I *want* Thomas Magnum's car...erm...or rather Robin Masters's car...not to mention "Robin's Nest"...)
 but seriously, your argument is ridiculously wrong since velocity is 
 dependent on the observer.
 the OP said and I quote: "32-bit compilers are just wasting *my* time" 
 (emphasis added).

Curses! Einstein strikes again!
Oct 17 2009
prev sibling next sibling parent reply Just Visiting <nospam aol.com> writes:
Before I answer the previous message I'd like to thank
everyone for their feedback which was pretty helpful.

Now to Nick:

I really do not intend to offend anybody but you should
actually think before you question the necessity for
fast/responsive programs. People like you have used
similar arguments since the IT stone age. They usually
judge from the standpoint of their own momentary CPU
performance requirements.

If I'd use your comments during my next business meeting
we'd all have a good laugh. But I won't because I'll give
you the chance to think this over:

My girl friend is driving a Porsche (no Italian sports car, sorry).
Who do you think had to pay for it? Yeah, you guessed right,
it was the guy who is tweaking software, so a bunch of
computers can survive their replacement by a year or two.
I just wonder what car make she'd be driving if I told my clients
to use patience - instead of paying myself to get their analysis
software to finish the job in a fraction of time.

Cheers.


Nick Sabalausky Wrote:

 "Just Visiting" <nospam aol.com> wrote in message 
 news:hbcbvs$1ees$1 digitalmars.com...
 Last things I remember:

 - DmD is strictly 32-bit
 - Someone ported a chronically outdated D-compiler variant to Linux x86_64

 The ideas behind DmD looked promising to me. But most of my programs 
 showed at least a 2-fold performance increase once they were re-written 
 for 64-bit.

Only on 64-bit systems. Which are already ridiculously fast anyway. So what if they get some more performance? They already have gobs of performance to spare. On a 32-bit system it changes the programs performance down to "It don't f** work at all", which is the mark of an incredibly arrogant developer who likes to shoot themself in the foot by arbitrarily shrinking their own potential user base.
 Therefore 32-bit compilers are just wasting my time, and this is why I've 
 lost track of DmD.

They should make roads that are only usable by Italian sports cars, and take full advantage of their special characteristics. Any other roads are just wasting my time.

Oct 17 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Just Visiting" <nospam aol.com> wrote in message 
news:hbdk23$2qoi$1 digitalmars.com...
 They usually
 judge from the standpoint of their own momentary CPU
 performance requirements.

I can say exactly the same about people who defend setting their minimum system specs higher than they need to be. As soon as most developers get their hands on a new piece of hardware, all of a sudden they think no one else should be using anything less, no matter how useful or widespread the lower-end stuff may still be. And that's been going on for ages as well.
 If I'd use your comments during my next business meeting
 we'd all have a good laugh. But I won't because I'll give
 you the chance to think this over:

I couldn't care less what a bunch of suits think about my comments. If they even exist...this sudden grab for professionalism seems quite contrived considering the arrogance of your original post: "Therefore 32-bit compilers are just wasting my time," Take a minute to think first the next time you want to jump in and tell a group of people that their compiler is wasting your time.
 it was the guy who is tweaking software, so a bunch of
 computers can survive their replacement by a year or two.

That's exactly my point. There are plenty of 32-bit systems out there that are perfectly useful, but then people like you go around waving a "32-bit is antique, support for it is useless" flag. And now you suddenly turn around and try to defend your disregard for an older piece of hardware...for the sake of hardware longevity? What?
Oct 17 2009
parent reply Just Visiting <nospam aol.com> writes:
Nick Sabalausky Wrote:

 "Just Visiting" <nospam aol.com> wrote in message 
 news:hbdk23$2qoi$1 digitalmars.com...
 They usually
 judge from the standpoint of their own momentary CPU
 performance requirements.

I can say exactly the same about people who defend setting their minimum system specs higher than they need to be. As soon as most developers get their hands on a new piece of hardware, all of a sudden they think no one else should be using anything less, no matter how useful or widespread the lower-end stuff may still be. And that's been going on for ages as well.

Not sure what you are talking about. I get paid for improving responsiveness of programs - sometimes by using assembly language if deemed necessary. I do not consult anybody what hardware they should be using, as long as it remains compatible with my software.
 If I'd use your comments during my next business meeting
 we'd all have a good laugh. But I won't because I'll give
 you the chance to think this over:

I couldn't care less what a bunch of suits think about my comments. If they even exist...this sudden grab for professionalism seems quite contrived considering the arrogance of your original post: "Therefore 32-bit compilers are just wasting my time,"

Arrogance? Does it irk you that much if someone dumps a 32-bit compiler in order to enjoy an impressive speed increase without substantial changes to the software?
 Take a minute to think first the next time you want to jump in and tell a 
 group of people that their compiler is wasting your time.

Sounds almost like I have offended D's lead developer. Sorry 'bout that. But you are absolutely right. 32-bit compilers - not just DmD - are wasting my time. For approximately equal results I'd have to add either assembly language to time critical sections of my 32-bit code, or just use a 64-bit compiler with moderate adaptations.
 it was the guy who is tweaking software, so a bunch of
 computers can survive their replacement by a year or two.

That's exactly my point. There are plenty of 32-bit systems out there that are perfectly useful, but then people like you go around waving a "32-bit is antique, support for it is useless" flag. And now you suddenly turn around and try to defend your disregard for an older piece of hardware...for the sake of hardware longevity? What?

I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients do not share this view for a series of good reasons. Even their older systems tend to be 64-bit nowadays. Migration towards 64-bit OSes is under way. There is still 32-bit compatibility if needed. At the same time certain programs will perform drastically better when compiled to 64-bit. Replacement thus can be postponed which is usually the best way to keep CFOs happy.
Oct 17 2009
next sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-18 11:32:07 +0200, language_fan <foo bar.com.invalid> said:

 Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote:
 
 I won't deny that for certain people 32-bit systems are still perfectly
 useful. Just my clients do not share this view for a series of good
 reasons. Even their older systems tend to be 64-bit nowadays. Migration
 towards 64-bit OSes is under way. There is still 32-bit compatibility if
 needed. At the same time certain programs will perform drastically
 better when compiled to 64-bit. Replacement thus can be postponed which
 is usually the best way to keep CFOs happy.

64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task.

on x86 the 64 bit extension added registers, that makes it faster, even if as you correctly point out a priori just using 64 bit pointers is just a drawback unless you have lot of memory. Anyway I also need 64 bit (computational chemistry, speed and memory hungry), and to that the only thing that I can say is D1 works very well with 64 bit. Fawzi
Oct 18 2009
next sibling parent Stanley Steel <news-steel kryas.com> writes:
 Why I mentioned desktop applications is that currently the trend has been
 to replace old 32-bit intel/amd processors in desktop use. And most
 desktop apps are written in systems programming languages. You can hardly
 buy any non-64-bit capable processor from any pc store these days. The
 people are getting crap that they don't need.

 The same thing happens with digital cameras. In cameras the pixel count
 of sensors is growing even though the image quality stays the same. A
 good quality 4 MPix camera is much better than a cheap 15 MPix pocket
 camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored in
 jpg format might look better than the original 15 MPix one in raw format.
 They just keep pushing the limits to sell larger and larger storage media.

You'd probably be pissed to hear about microsoft creating a 128-bit OS and intel designing 128-bit processors.
Oct 18 2009
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-18 20:01:26 +0200, language_fan <foo bar.com.invalid> said:

 Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
 
 On 2009-10-18 11:32:07 +0200, language_fan <foo bar.com.invalid> said:
 
 Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote:
 
 I won't deny that for certain people 32-bit systems are still
 perfectly useful. Just my clients do not share this view for a series
 of good reasons. Even their older systems tend to be 64-bit nowadays.
 Migration towards 64-bit OSes is under way. There is still 32-bit
 compatibility if needed. At the same time certain programs will
 perform drastically better when compiled to 64-bit. Replacement thus
 can be postponed which is usually the best way to keep CFOs happy.

64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task.

on x86 the 64 bit extension added registers, that makes it faster, even if as you correctly point out a priori just using 64 bit pointers is just a drawback unless you have lot of memory.

That is very silly claim. First, you need to have use for all those extra registers to obtain any performance benefits. This is nearly not always the case.

for modern standards, also with the 64 bit new instruction were added, on x86 the 64 bit change was not "add 64-bit pointers" but it was let's try to fix some major shortcomings of x86. These enhancements are available only in 64 bit mode (to keep backward compatibility). I know for a fact that my code runs faster in 64 bit mode (or you can say my compiler optimizes it better), and I am not the only one: for sure apple converted basically all its applications to 64 bit on snow leopard (that is focusing on speed), so that they are slower :P.
  Also note that cache size is heavily constrained and larger
 binaries will fill it with less code. This alone can make the code a lot
 slower on first generation and budget 2..4-core x86 machines with smaller
 cache sizes.

cache usage is a real issue, but on the whole code is faster in 64 bit mode, at least in my experience
 Main memory is expensive and you rarely can install more than 64 GB on a
 PC style hardware. Many times you can even split a task into separate
 2..3 GB processes quite easily. So the immediate advantages of 64-bit
 code are not that clear when you only need it to grow the processes
 larger. On Linux, for instance, ordinary 64-bit desktop requires a lot
 more memory than its 32-bit alternative. Why would you want to buy more
 hardware to fix something that can be fixed with existing software?
 
 Anyway I also need 64 bit (computational chemistry, speed and memory
 hungry), and to that the only thing that I can say is D1 works very well
 with 64 bit.

That's one domain where 64 bits may give you an advantage. In normal desktop applications there is often nothing in 64-bit code that can improve anything. I am talking about firefox / winamp / mediaplayer / photoshop / outlook / casual gaming use here.

not sure, see snow leopard...
 Why I mentioned desktop applications is that currently the trend has been
 to replace old 32-bit intel/amd processors in desktop use. And most
 desktop apps are written in systems programming languages. You can hardly
 buy any non-64-bit capable processor from any pc store these days. The
 people are getting crap that they don't need.

intel tried hard to avoid giving 64 bit in consumer processors (as it wanted to push IA-64), but failed and had to give what people wanted, in this case I think it was a good thing. Fawzi
Oct 19 2009
next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-19 15:04:23 +0200, language_fan <foo bar.com.invalid> said:

 Mon, 19 Oct 2009 13:22:34 +0200, Fawzi Mohamed thusly wrote:
 On 2009-10-18 20:01:26 +0200, language_fan <foo bar.com.invalid> said:
 Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
 
 Also note that cache size is heavily constrained and larger
 binaries will fill it with less code. This alone can make the code a
 lot slower on first generation and budget 2..4-core x86 machines with
 smaller cache sizes.

cache usage is a real issue, but on the whole code is faster in 64 bit mode, at least in my experience

I believe in real world benchmarks more than in hollow words.
 Main memory is expensive and you rarely can install more than 64 GB on
 a PC style hardware. Many times you can even split a task into separate
 2..3 GB processes quite easily. So the immediate advantages of 64-bit
 code are not that clear when you only need it to grow the processes
 larger. On Linux, for instance, ordinary 64-bit desktop requires a lot
 more memory than its 32-bit alternative. Why would you want to buy more
 hardware to fix something that can be fixed with existing software?
 


You did not comment on this.. in desktop use cpu power rarely matters. But running out of memory is pretty common (think about laptops with limited amount of memory slots and expensive memory units).

I fully agree that for desktop 32 bit is enough, but selling it as better is just misinformation (at least for x86). Just look at the installs for ubuntu 64 bit vs 32 and you will see that the difference is just a few %. What uses lot of place is installing things twice (32 and 64 bit version of the libs for example), if you have a pure 64 bit install (like I do) then you do loose the possibility to run 32 bit binaries or plugins that need 32 bit libs (like dmd :(), but the whole system is not much larger. In any case often what occupies most space isn't the compiled code but other resources. With this I will stop answering you, because I don't find it so productive. Fawzi
Oct 19 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Fawzi Mohamed" <fmohamed mac.com> wrote in message 
news:hbhi5q$1gqm$1 digitalmars.com...
 On 2009-10-18 20:01:26 +0200, language_fan <foo bar.com.invalid> said:

 Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
 on x86 the 64 bit extension added registers, that makes it faster, even
 if as you correctly point out a priori just using 64 bit pointers is
 just a drawback unless you have lot of memory.

That is very silly claim. First, you need to have use for all those extra registers to obtain any performance benefits. This is nearly not always the case.

modern standards, also with the 64 bit new instruction were added, on x86 the 64 bit change was not "add 64-bit pointers" but it was let's try to fix some major shortcomings of x86. These enhancements are available only in 64 bit mode (to keep backward compatibility). I know for a fact that my code runs faster in 64 bit mode (or you can say my compiler optimizes it better), and I am not the only one: for sure apple converted basically all its applications to 64 bit on snow leopard (that is focusing on speed), so that they are slower :P.

I'll certainly agree with you on 64-bit x86 likely being faster than 32-bit, but Apple is bad example. Apple, at it's cor...erm..."heart", is a hardware company. That's where they make their money. If software runs efficiently, then their newer hardware becomes a tougher sell (And Jobs himself has never been anything more than a salesman, only with far more control over his company than salesmen usually have). It's not surprising that for years, every version of iTunes has kept growing noticably more bloated than the last, despite having very little extra.
Oct 19 2009
prev sibling parent BCS <none anon.com> writes:
Hello Just,

 I won't deny that for certain people 32-bit systems are still
 perfectly useful.
 Just my clients do not share this view for a series of good reasons.
 Even
 their older systems tend to be 64-bit nowadays. Migration towards
 64-bit
 OSes is under way. There is still 32-bit compatibility if needed. At
 the same
 time certain programs will perform drastically better when compiled to
 64-bit.
 Replacement thus can be postponed which is usually the best way to
 keep
 CFOs happy.

If you know in advance that ALL of your market is 64bit today, or If you expect the client to buy whatever you tell them to (I understand that graphical designers buy whatever the photoshop box says to buy) that's one thing, but If you are selling to people who will only upgrade if forced to, then only shipping in 64bit is just spending someone else money (never a good idea). It sounds like you might be in the first cases so you might be fine, but enough users of D are in the second case that 32 is not a waist of time for a lot of people.
Oct 18 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Just Visiting wrote:
 My girl friend is driving a Porsche (no Italian sports car, sorry).
 Who do you think had to pay for it? Yeah, you guessed right,
 it was the guy who is tweaking software, so a bunch of
 computers can survive their replacement by a year or two.
 I just wonder what car make she'd be driving if I told my clients
 to use patience - instead of paying myself to get their analysis
 software to finish the job in a fraction of time.

And it's "Porsche-uh". Andrei
Oct 17 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote:

 I won't deny that for certain people 32-bit systems are still perfectly
 useful. Just my clients do not share this view for a series of good
 reasons. Even their older systems tend to be 64-bit nowadays. Migration
 towards 64-bit OSes is under way. There is still 32-bit compatibility if
 needed. At the same time certain programs will perform drastically
 better when compiled to 64-bit. Replacement thus can be postponed which
 is usually the best way to keep CFOs happy.

64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task.
Oct 18 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:

 On 2009-10-18 11:32:07 +0200, language_fan <foo bar.com.invalid> said:
 
 Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote:
 
 I won't deny that for certain people 32-bit systems are still
 perfectly useful. Just my clients do not share this view for a series
 of good reasons. Even their older systems tend to be 64-bit nowadays.
 Migration towards 64-bit OSes is under way. There is still 32-bit
 compatibility if needed. At the same time certain programs will
 perform drastically better when compiled to 64-bit. Replacement thus
 can be postponed which is usually the best way to keep CFOs happy.

64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task.

on x86 the 64 bit extension added registers, that makes it faster, even if as you correctly point out a priori just using 64 bit pointers is just a drawback unless you have lot of memory.

That is very silly claim. First, you need to have use for all those extra registers to obtain any performance benefits. This is nearly not always the case. Also note that cache size is heavily constrained and larger binaries will fill it with less code. This alone can make the code a lot slower on first generation and budget 2..4-core x86 machines with smaller cache sizes. Main memory is expensive and you rarely can install more than 64 GB on a PC style hardware. Many times you can even split a task into separate 2..3 GB processes quite easily. So the immediate advantages of 64-bit code are not that clear when you only need it to grow the processes larger. On Linux, for instance, ordinary 64-bit desktop requires a lot more memory than its 32-bit alternative. Why would you want to buy more hardware to fix something that can be fixed with existing software?
 Anyway I also need 64 bit (computational chemistry, speed and memory
 hungry), and to that the only thing that I can say is D1 works very well
 with 64 bit.

That's one domain where 64 bits may give you an advantage. In normal desktop applications there is often nothing in 64-bit code that can improve anything. I am talking about firefox / winamp / mediaplayer / photoshop / outlook / casual gaming use here. Why I mentioned desktop applications is that currently the trend has been to replace old 32-bit intel/amd processors in desktop use. And most desktop apps are written in systems programming languages. You can hardly buy any non-64-bit capable processor from any pc store these days. The people are getting crap that they don't need. The same thing happens with digital cameras. In cameras the pixel count of sensors is growing even though the image quality stays the same. A good quality 4 MPix camera is much better than a cheap 15 MPix pocket camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored in jpg format might look better than the original 15 MPix one in raw format. They just keep pushing the limits to sell larger and larger storage media.
Oct 18 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Sun, 18 Oct 2009 14:45:39 -0600, Stanley Steel thusly wrote:

 Why I mentioned desktop applications is that currently the trend has
 been to replace old 32-bit intel/amd processors in desktop use. And
 most desktop apps are written in systems programming languages. You can
 hardly buy any non-64-bit capable processor from any pc store these
 days. The people are getting crap that they don't need.

 The same thing happens with digital cameras. In cameras the pixel count
 of sensors is growing even though the image quality stays the same. A
 good quality 4 MPix camera is much better than a cheap 15 MPix pocket
 camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored
 in jpg format might look better than the original 15 MPix one in raw
 format. They just keep pushing the limits to sell larger and larger
 storage media.

You'd probably be pissed to hear about microsoft creating a 128-bit OS and intel designing 128-bit processors.

Nah, I don't really care. I have nothing against wider vector registers, but huge general purpose registers usually don't make sense.
Oct 18 2009
prev sibling next sibling parent Daniel de Kok <me nowhere.nospam> writes:
On 2009-10-17 22:11:56 +0200, "Nick Sabalausky" <a a.a> said:
 Only on 64-bit systems. Which are already ridiculously fast anyway. So what
 if they get some more performance? They already have gobs of performance to
 spare. On a 32-bit system it changes the programs performance down to "It
 don't f** work at all", which is the mark of an incredibly arrogant
 developer who likes to shoot themself in the foot by arbitrarily shrinking
 their own potential user base.

Well, for some it is a necessity. In our field (NLP), a theoretical maximum of 4GB of memory is just too little for anything but some scripting. Just to give some numbers: with the current size of corpora we need ~20GB of memory for error mining in parsing results, and at least ~10GB of memory for serious natural language generation. Until there is a good D2 compiler that can compile x86_64 on Linux, I'll have to continue using C++. After writing some small programs, I have come to the conclusion that the use of D would be far more comfortable, although some of the C++0x extensions that are already implemented in g++ help. Not that I am complaining, I understand that the first priority is getting the D2 specification finished, but I think it would be far more productive (and easier to support x86_64) if LLVM became the default backend. LLVM will be the future of non-managed compiled languages anyway... Take care, Daniel
Oct 19 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Mon, 19 Oct 2009 13:22:34 +0200, Fawzi Mohamed thusly wrote:
 On 2009-10-18 20:01:26 +0200, language_fan <foo bar.com.invalid> said:
 Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
 
  Also note that cache size is heavily constrained and larger
 binaries will fill it with less code. This alone can make the code a
 lot slower on first generation and budget 2..4-core x86 machines with
 smaller cache sizes.

cache usage is a real issue, but on the whole code is faster in 64 bit mode, at least in my experience

I believe in real world benchmarks more than in hollow words.
 Main memory is expensive and you rarely can install more than 64 GB on
 a PC style hardware. Many times you can even split a task into separate
 2..3 GB processes quite easily. So the immediate advantages of 64-bit
 code are not that clear when you only need it to grow the processes
 larger. On Linux, for instance, ordinary 64-bit desktop requires a lot
 more memory than its 32-bit alternative. Why would you want to buy more
 hardware to fix something that can be fixed with existing software?
 


You did not comment on this.. in desktop use cpu power rarely matters. But running out of memory is pretty common (think about laptops with limited amount of memory slots and expensive memory units).
 Anyway I also need 64 bit (computational chemistry, speed and memory
 hungry), and to that the only thing that I can say is D1 works very
 well with 64 bit.

That's one domain where 64 bits may give you an advantage. In normal desktop applications there is often nothing in 64-bit code that can improve anything. I am talking about firefox / winamp / mediaplayer / photoshop / outlook / casual gaming use here.

not sure, see snow leopard...

That's a business decisions ffs. Not necessarily a technical one. Maybe they wanted to future proof their software by keeping the amount of binary formats at minimum.
Oct 19 2009
prev sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Mon, Oct 19, 2009 at 10:26 PM, Nick Sabalausky <a a.a> wrote:
 "Fawzi Mohamed" <fmohamed mac.com> wrote in message
 news:hbhi5q$1gqm$1 digitalmars.com...
 On 2009-10-18 20:01:26 +0200, language_fan <foo bar.com.invalid> said:

 Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
 on x86 the 64 bit extension added registers, that makes it faster, even
 if as you correctly point out a priori just using 64 bit pointers is
 just a drawback unless you have lot of memory.

That is very silly claim. First, you need to have use for all those extra registers to obtain any performance benefits. This is nearly not always the case.

modern standards, also with the 64 bit new instruction were added, on x86 the 64 bit change was not "add 64-bit pointers" but it was let's try to fix some major shortcomings of x86. These enhancements are available only in 64 bit mode (to keep backward compatibility). I know for a fact that my code runs faster in 64 bit mode (or you can say my compiler optimizes it better), and I am not the only one: for sure apple converted basically all its applications to 64 bit on snow leopard (that is focusing on speed), so that they are slower :P.

I'll certainly agree with you on 64-bit x86 likely being faster than 32-bit, but Apple is bad example. Apple, at it's cor...erm..."heart", is a hardware company. That's where they make their money. If software runs efficiently, then their newer hardware becomes a tougher sell (And Jobs himself has never been anything more than a salesman, only with far more control over his company than salesmen usually have). It's not surprising that for years, every version of iTunes has kept growing noticably more bloated than the last, despite having very little extra.

It's interesting how Apple is doing a lot to better performance then. With things like OpenCL and LLVM.
Oct 20 2009