Jump to page: 1 2
Thread overview
Forums suffering Priority Inversion with Livelock
Apr 04, 2008
Daniel
Apr 04, 2008
BCS
Apr 04, 2008
Neil Vice
Apr 04, 2008
Christopher Wright
Apr 04, 2008
downs
Apr 04, 2008
Daniel
Apr 04, 2008
Fawzi Mohamed
Apr 04, 2008
Robert Fraser
Apr 04, 2008
BCS
Apr 04, 2008
e-t172
Apr 05, 2008
Lars Ivar Igesund
Apr 05, 2008
lutger
April 04, 2008
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.
April 04, 2008
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.
April 04, 2008
"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.


April 04, 2008
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.
April 04, 2008
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
April 04, 2008
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.
April 04, 2008
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


April 04, 2008
"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


April 04, 2008
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.
April 04, 2008
"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


« First   ‹ Prev
1 2