www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Forums suffering Priority Inversion with Livelock

reply Daniel <murpsoft hotmail.com> writes:
I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.

1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

2) Compiling a program with extern (C) main(){ return 1; } still doesn't let
you cut the excess 80kb of fat.  I don't care what's in there, it needs to be
included "on use".

I can't use D at work, and don't use it at home, until these issues are
resolved.
Apr 03 2008
next sibling parent BCS <BCS pathlink.com> writes:
Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock
 priority inversion in the forums.  Everyone's spending months arguing
 about constness, when there are clear, simple, and higher priority
 issues to resolve.

I've noticed the same thing, I long ago (back about the time 2.000 came out) stopped reading const threads because I realized, I don't care. I'll let other's trash it out and then use it when it's done.
 1) The x86-32 platform is obsolete, and D still can't run x86-64, 

x86-32 may be obsolete, but it's still fairly viable. OTOH, your point is a good one, there are things that could use some TLC.
Apr 03 2008
prev sibling next sibling parent "Neil Vice" <sardonicpresence gmail.com> writes:
"Daniel" <murpsoft hotmail.com> wrote in message 
news:ft3rca$2se3$1 digitalmars.com...
 I don't mean to rain on anyone's parade, but I'm noticing a livelock 
 priority inversion in the forums.  Everyone's spending months arguing 
 about constness, when there are clear, simple, and higher priority issues 
 to resolve.

 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only 
 supports SSE if you hand code it in assembler.  One step away from being 
 targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

 2) Compiling a program with extern (C) main(){ return 1; } still doesn't 
 let you cut the excess 80kb of fat.  I don't care what's in there, it 
 needs to be included "on use".

 I can't use D at work, and don't use it at home, until these issues are 
 resolved.

The thing is that these are features of the compiler and linker not the language. My impression is that the DMD back-end is legacy and fairly static, though I could well be wrong. GDC is an obvious solution to this, but requires regular maintenance of the "glue" code. I'm honestly not sure what the status of GDC is though the sourceforge page hasn't had a news since 22/08/07 and the last front-end version refered to is 1.00. This is a project I wouldn't mind working on myself, though I'm not used to open-source collaborative development and feel that the original GDC developer should certainly be involved in some way. On another note, the usability of const is quite important to me and I don't think that discussion of ideas for future language features should be considered a bad thing. If Walter's direction is to further develop the language spec then perhaps it is up to others to take his open-source front-end and attach it to an existing back-end to fix these long-standard (and probably not trivial) issues.
Apr 03 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.
 
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.
 
 2) Compiling a program with extern (C) main(){ return 1; } still doesn't let
you cut the excess 80kb of fat.  I don't care what's in there, it needs to be
included "on use".
 
 I can't use D at work, and don't use it at home, until these issues are
resolved.

People are used to Java and .NET, with megabytes of overhead. Anyone considering D for x86 processors probably doesn't care about 80kb extra cruft. Or probably shouldn't. If you're trying to use D on embedded devices, though, it's an issue. But these days, even embedded systems have 32MB of RAM.
Apr 03 2008
prev sibling next sibling parent reply downs <default_357-line yahoo.de> writes:
Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.

Agreed.
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

I've managed to make autovectorization (automatic SSE generation from loops) work in a highly experimental version of GDC 4.2.3, with lots of help from IRC. I'll post a patch in a while, with HUGE "experimental" stickers (want to get the stress test results first), but it works in principle. Also, all of tools should in theory work on 64-bit (even the assembler stuff) - I'll test it in a few days on a new box I'm putting together. GDC also generates faster code than DMD in many cases :) --feep
Apr 04 2008
next sibling parent Daniel <murpsoft hotmail.com> writes:
downs Wrote:

 Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.

Agreed.
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

I've managed to make autovectorization (automatic SSE generation from loops) work in a highly experimental version of GDC 4.2.3, with lots of help from IRC. I'll post a patch in a while, with HUGE "experimental" stickers (want to get the stress test results first), but it works in principle. Also, all of tools should in theory work on 64-bit (even the assembler stuff) - I'll test it in a few days on a new box I'm putting together. GDC also generates faster code than DMD in many cases :) --feep

Cool stuff, downs. Looks like it'll be the GDC then for all my future language-based programming. Now I just need to throw together another x86-64 Linux again somewhere.
Apr 04 2008
prev sibling next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-04-04 10:24:30 +0200, downs <default_357-line yahoo.de> said:

 Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock 
 priority inversion in the forums.  Everyone's spending months arguing 
 about constness, when there are clear, simple, and higher priority 
 issues to resolve.

Agreed.

ok, that was my impression too, but I fear that in the end I also contribued to it :)
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and 
 only supports SSE if you hand code it in assembler.  One step away from 
 being targetted to 16-bit x286.  x86-64 has been out for a 5 years now.


I use x86-64 with gdc and both phobos and tango. I had some issues setting up everything, but using svn version everything (but SSE) should work
 I've managed to make autovectorization (automatic SSE generation from 
 loops) work in a highly experimental version of GDC 4.2.3, with lots of 
 help from IRC.

great news! Fawzi
 I'll post a patch in a while, with HUGE "experimental" stickers (want 
 to get the stress test results first), but it works in principle.
 
 Also, all of tools should in theory work on 64-bit (even the assembler 
 stuff) - I'll test it in a few days on a new box I'm putting together.
 
 GDC also generates faster code than DMD in many cases :)
 
  --feep

Apr 04 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
downs wrote:
 GDC also generates faster code than DMD in many cases :)

There are a fair few cases where the opposite is true, too.
Apr 04 2008
parent BCS <BCS pathlink.com> writes:
Robert Fraser wrote:
 downs wrote:
 
 GDC also generates faster code than DMD in many cases :)

There are a fair few cases where the opposite is true, too.

are the calling conventions compatible? Could the app be compiled twice and then pick and choose what object file to pull each function from? (Yes I know this is "a bad idea" but it would be kinda "fun")
Apr 04 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Daniel" wrote
 I don't mean to rain on anyone's parade, but I'm noticing a livelock 
 priority inversion in the forums.  Everyone's spending months arguing 
 about constness, when there are clear, simple, and higher priority issues 
 to resolve.

It all depends on your priorities :) Mine is to make sure D2 will be adopted by Tango, and for that, const needs to be reasonable.
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only 
 supports SSE if you hand code it in assembler.  One step away from being 
 targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

I'd hazard to guess that 90% of software developers couldn't care less. If I have an x86-64 platform, I have no idea, I just know the compiler makes code and it runs :) And my computer is only a year old, so it probably is an x86-64. IMO, this should be a low priority item, as it has nothing to do with the language, it's a compiler issue.
 2) Compiling a program with extern (C) main(){ return 1; } still doesn't 
 let you cut the excess 80kb of fat.  I don't care what's in there, it 
 needs to be included "on use".

Again, compiler not language. But I think this one is really important, as nobody likes bloat, and really, OS's have been using dynamic loading code for over a decade... -Steve
Apr 04 2008
parent reply e-t172 <e-t172 akegroup.org> writes:
Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less.  If 
 I have an x86-64 platform, I have no idea, I just know the compiler makes 
 code and it runs :)  And my computer is only a year old, so it probably is 

Imagine you want to compile a program for a Debian x86_64 (or any other 64bit distribution). Problem is, you can't link a 32bit program to 64bit libraries. So if you want to link your D program to third party C libraries, you're basically screwed. Therefore, I think they care, actually.
Apr 04 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"e-t172" wrote
 Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less. 
 If I have an x86-64 platform, I have no idea, I just know the compiler 
 makes code and it runs :)  And my computer is only a year old, so it 
 probably is

Imagine you want to compile a program for a Debian x86_64 (or any other 64bit distribution). Problem is, you can't link a 32bit program to 64bit libraries. So if you want to link your D program to third party C libraries, you're basically screwed. Therefore, I think they care, actually.

I didn't realize this was the case, so it's not as much a non-issue as I thought. But I think you might be in the minority, there are still plenty of actively developed 32-bit OSes for Intel processors, so the suggestion that D is focusing on a platform as dead as 286s is grossly false. Besides that point, there is no reason that we can't have discussions on the NG about language features AND have other people port the D compiler to x86_64. AFAIK, gdc is open source and you are welcome to try and port it. -Steve
Apr 04 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Steven Schveighoffer wrote:

 "e-t172" wrote
 Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less.
 If I have an x86-64 platform, I have no idea, I just know the compiler
 makes code and it runs :)  And my computer is only a year old, so it
 probably is

Imagine you want to compile a program for a Debian x86_64 (or any other 64bit distribution). Problem is, you can't link a 32bit program to 64bit libraries. So if you want to link your D program to third party C libraries, you're basically screwed. Therefore, I think they care, actually.

I didn't realize this was the case, so it's not as much a non-issue as I thought. But I think you might be in the minority, there are still plenty of actively developed 32-bit OSes for Intel processors, so the suggestion that D is focusing on a platform as dead as 286s is grossly false. Besides that point, there is no reason that we can't have discussions on the NG about language features AND have other people port the D compiler to x86_64. AFAIK, gdc is open source and you are welcome to try and port it.

And as far as I know, GDC is pretty stable on x86_64, although not 100% conforming with the D spec. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Apr 05 2008
prev sibling parent lutger <lutger.blijdestijn gmail.com> writes:
e-t172 wrote:

 Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less. 
 If I have an x86-64 platform, I have no idea, I just know the compiler
 makes
 code and it runs :)  And my computer is only a year old, so it probably
 is

Imagine you want to compile a program for a Debian x86_64 (or any other 64bit distribution). Problem is, you can't link a 32bit program to 64bit libraries. So if you want to link your D program to third party C libraries, you're basically screwed. Therefore, I think they care, actually.

You can link a 32-bit program to 32-bit libraries and run them on a 64-bit operating system. I develop on a 64-bit OS with dmd and while it's sometimes a bit funny to locate and install 32-bit development libraries, it is quite doable. For making true 64-bit binaries, GDC is there. The only bummer I think is that the inline assembler is still stuck on 32-bit even with GDC? Well this is with linux, I suppose it is possible for windows too? Though I think everybody would like to see a 64-bit dmd and a rewrite of optlink especially, I don't see how this could take priority above the development of the D language. And const currently is the main thing, saying it is not a high-priority is like saying 'stop Walter, you're done'. You can disagree with the const design, but that's a different argument altogether.
Apr 05 2008