www.digitalmars.com         C & C++   DMDScript  

D - D's fate (Re: 2nd Chance - D_Error.GIF)

reply "Luna Kid" <lunakid neuropolis.org> writes:
"Maybe_D" <Maybe_D_member pathlink.com> wrote in message
news:bfkds3$2mm6$1 digitaldaemon.com...
 Hi,

 after trying D several months ago I was enthusiastic about the idea behind it
 but reality caught up quickly: Compile/Link crashed after using an array of
 approx. 10MB in size. So I went mad with D and tried to forget it.

 But after recently noticing some D-release-activity, I am wondering if I should
 give it another try and I would be grateful for any advice related to the
 following questions/comments:

 1) Is the issue mentioned above fixed?

 2) Can I expect to get some more 'surprises' at this stage on trivial things
 like arrays being too large?

 3) Is there something like a roadmap to a D V1.0 or is it too early to tell if
 this will ever happen?

In defence of DMD: It's a bit foolish to "go mad" and decide against D just because it has or may have bugs in certain cases. Bugs are both expected in 0.something versions, and also being fixed by Walter (if reported). (Besides, I wouldn't necessarily call a 10MB static array a "trivial thing", I've spent 12 years in the industry without encountering one. Sure, this does not define non-triviality, but you get the point. ;) ) As to the roadmap thing: As I sense (as a longer-term spectator, not as an active D tester/developer), the one-man Digital Mars brigade is on the verge of getting a little overloaded. As D affects only a tiny little corner of the developer community, this is both OK yet (as Walter can apparently take amazing amounts of workload to handle all the "incoming" user activity) and also a risk for D's future, as it may mean a bottleneck for getting enough momentum soon enough for D to take off. (I may be wrong, but the current D project vaguely reminds me of a uniprocessor system running at near-peak CPU load with most of the peripherals idling.) Cheers, Sz.
Jul 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bfll2i$ps1$1 digitaldaemon.com...
 It's a bit foolish to "go mad" and decide against D just
 because it has or may have bugs in certain cases. Bugs are
 both expected in 0.something versions, and also being fixed
 by Walter (if reported). (Besides, I wouldn't necessarily
 call a 10MB static array a "trivial thing", I've spent 12
 years in the industry without encountering one. Sure, this
 does not define non-triviality, but you get the point. ;) )

The array thing is a linker issue, and has nothing to do with the DMD compiler. It's been reported for C++, too, by one person. The workaround is easy - just malloc the array instead.
 As to the roadmap thing:

 As I sense (as a longer-term spectator, not as an active
 D tester/developer), the one-man Digital Mars brigade is
 on the verge of getting a little overloaded. As D affects
 only a tiny little corner of the developer community, this
 is both OK yet (as Walter can apparently take amazing
 amounts of workload to handle all the "incoming" user
 activity) and also a risk for D's future, as it may mean
 a bottleneck for getting enough momentum soon enough
 for D to take off.

It's not impossible as long as I'm careful not to get distracted doing other things not on the critical path to moving D forward. I've often wondered how other companies find things to do for the 100+ people they assign to a single compiler <g>.
Jul 23 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 The array thing is a linker issue, and has nothing to do with the DMD
 compiler. It's been reported for C++, too, by one person. The workaround is
 easy - just malloc the array instead.

(Sure, but I meant D as "the full DMD package", optlink included. I bet few people do/can use other linkers with D currently, partly due to OMF not being adored much by mainstream linkers. Cheers, Sz.)
Jul 23 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Seriously:   How hard would it be to have an option to generate more common
(read: widely supported) .obj and debug info formats?  Are the formats all
so proprietary nobody else can produce them?

Sean

"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bfmoge$20u0$1 digitaldaemon.com...
 The array thing is a linker issue, and has nothing to do with the DMD
 compiler. It's been reported for C++, too, by one person. The workaround


 easy - just malloc the array instead.

(Sure, but I meant D as "the full DMD package", optlink included. I bet few people do/can use other linkers with D currently, partly due to OMF not being adored much by mainstream linkers. Cheers, Sz.)

Jul 24 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bfo06m$5rs$1 digitaldaemon.com...
 Seriously:   How hard would it be to have an option to generate more

 (read: widely supported) .obj and debug info formats?  Are the formats all
 so proprietary nobody else can produce them?

The problem is the linker is written entirely in assembly language. And before Microsoft decided to invent a new coff format, the Intel OMF *was* the most widely used & supported format. The debug format also works fine with Microsoft debuggers.
Jul 24 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
This just goes to show you that coding anything worthwhile in asm is a dead
end.  It's a write-only format.  You gain 3% speed, but spend 600% more on
programmer time and effort, versus C with the bottlenecks/inner loop in asm.
That is how software used to be written though.  If you have no C compiler,
you write a C compiler in asm.  Bootstrapping  ;)

I keep forgetting that the debug info does indeed work, because I was a
dumbass for a while and had it turned off.  ;)

Now I have it in my head that the debug info is broken, even though it
isn't, really.  Would be nice if the debugger knew how to unmangle D idents
though. (wishful thinking)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bfpfga$1hi2$2 digitaldaemon.com...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bfo06m$5rs$1 digitaldaemon.com...
 Seriously:   How hard would it be to have an option to generate more

 (read: widely supported) .obj and debug info formats?  Are the formats


 so proprietary nobody else can produce them?

The problem is the linker is written entirely in assembly language. And before Microsoft decided to invent a new coff format, the Intel OMF *was* the most widely used & supported format. The debug format also works fine with Microsoft debuggers.

Jul 25 2003
next sibling parent "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 This just goes to show you that coding anything worthwhile in asm is
 a dead end.  It's a write-only format.  You gain 3% speed, but spend
 600% more on programmer time and effort, versus C with the
 bottlenecks/inner loop in asm. That is how software used to be
 written though.  If you have no C compiler, you write a C compiler in
 asm.  Bootstrapping  ;)

 I keep forgetting that the debug info does indeed work, because I was
 a dumbass for a while and had it turned off.  ;)

 Now I have it in my head that the debug info is broken, even though it
 isn't, really.  Would be nice if the debugger knew how to unmangle D
 idents though. (wishful thinking)

IIRC the linker was started in the mid-80s. And the C compilers back then used to be a lot worse than they are today. -fg
Jul 25 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bfqmgr$2mdg$1 digitaldaemon.com...
 This just goes to show you that coding anything worthwhile in asm is a

 end.  It's a write-only format.  You gain 3% speed, but spend 600% more on
 programmer time and effort, versus C with the bottlenecks/inner loop in

 That is how software used to be written though.  If you have no C

 you write a C compiler in asm.  Bootstrapping  ;)

It wasn't a bad idea for the author of optlink, who did very well on the proceeds <g>. Optlink wasn't 3% faster. It was ten times faster. It still is. It's an incredible piece of code. Optlink is the reason other companies came up with "incremental linkers", a wretched attempt to improve the speed of their links. Optlink still beat the pants off those incremental linkers even doing a full link.
Jul 26 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bfuamn$4cq$1 digitaldaemon.com...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bfqmgr$2mdg$1 digitaldaemon.com...
 This just goes to show you that coding anything worthwhile in asm is a

 end.  It's a write-only format.  You gain 3% speed, but spend 600% more


 programmer time and effort, versus C with the bottlenecks/inner loop in

 That is how software used to be written though.  If you have no C

 you write a C compiler in asm.  Bootstrapping  ;)

It wasn't a bad idea for the author of optlink, who did very well on the proceeds <g>. Optlink wasn't 3% faster. It was ten times faster. It still is. It's an incredible piece of code. Optlink is the reason other

 came up with "incremental linkers", a wretched attempt to improve the

 of their links. Optlink still beat the pants off those incremental linkers
 even doing a full link.

Then surely you understand and sympathize with my desire for a language which is scalable, portable, readable, debuggable, and yet generates object code that is similar in efficiency to hand-tuned asm (or at least C). I recently disassembled some VC++ .NET code for virtual inheritance which was doing crap like this in release builds: lea ecx, [eax-2ch] sub ecx, 4 mov [esp-10h], ecx Why the hell can't it fold constants in internally generated code in an optimized build? This kind of crap is just unacceptable. That stuff is why people resort to C or assembler, or avoiding good language constructs, just to make their stuff run fast. Any language impediment that impairs the ability of the optimizer to make good code is bad. For instance, that crap about returning int instead of bool because bool would involve a premature conversion to int which necessitates another test in the caller. But how much of Optlink was necessary to be written in asm to achieve that 10x speed increase? I consider it a Law of Optimizing that 90% of execution time is spent in under 10% of the code. Why waste programmer time making the other 90% in asm? You know that id Software's DOOM had only 2 assembly functions, one for drawing a slice of a vertical wall, and one for drawing a slice of a horizontal floor, yet blew the socks off everybody at the time. I just want to ask: What does asm allow you to do in Optlink that C++ or D won't allow you to express? What makes it so much faster written in asm? Then ask yourself why can't it be done in D. There will be a thousand reasons. All I wish is for those to be knocked out one at a time. ;) Sean
Jul 26 2003
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bfunbh$fvt$1 digitaldaemon.com...
 But how much of Optlink was necessary to be written in asm to achieve that
 10x speed increase?

I don't know.
 I consider it a Law of Optimizing that 90% of execution
 time is spent in under 10% of the code.  Why waste programmer time making
 the other 90% in asm?  You know that id Software's DOOM had only 2

 functions, one for drawing a slice of a vertical wall, and one for drawing

 slice of a horizontal floor, yet blew the socks off everybody at the time.

Doom is a marvel, and is the exception, not the rule. Optlink is also an exceptional case.
 I just want to ask:  What does asm allow you to do in Optlink that C++ or

 won't allow you to express?  What makes it so much faster written in asm?

Register allocation across functions is a big reason.
 Then ask yourself why can't it be done in D.  There will be a thousand
 reasons.  All I wish is for those to be knocked out one at a time.  ;)

Compilers are still a long way from doing as good a job as an expert asm programmer.
Jul 28 2003