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

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

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

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

"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
common
> (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.

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
> common
> > (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.

> 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

"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
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  ;)

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.

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

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

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

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