D - D's fate (Re: 2nd Chance - D_Error.GIF)
- Luna Kid (24/36) Jul 23 2003 In defence of DMD:
- Walter (9/26) Jul 23 2003 The array thing is a linker issue, and has nothing to do with the DMD
- Luna Kid (4/7) Jul 23 2003 (Sure, but I meant D as "the full DMD package", optlink
- Sean L. Palmer (7/14) Jul 24 2003 Seriously: How hard would it be to have an option to generate more com...
- Walter (7/10) Jul 24 2003 common
- Sean L. Palmer (14/24) Jul 25 2003 This just goes to show you that coding anything worthwhile in asm is a d...
- Fabian Giesen (3/14) Jul 25 2003 IIRC the linker was started in the mid-80s. And the C compilers back the...
- Walter (11/16) Jul 26 2003 dead
- Sean L. Palmer (32/48) Jul 26 2003 on
- Walter (11/22) Jul 28 2003 I don't know.
"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
"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
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
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...isThe 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 workaroundeasy - 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
"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 morecommon(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
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...allSeriously: How hard would it be to have an option to generate morecommon(read: widely supported) .obj and debug info formats? Are the formatsso 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
"Fabian Giesen" <rygNO SPAMgmx.net> 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
"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 adeadend. 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 inasm.That is how software used to be written though. If you have no Ccompiler,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
"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...onThis just goes to show you that coding anything worthwhile in asm is adeadend. It's a write-only format. You gain 3% speed, but spend 600% morecompaniesprogrammer time and effort, versus C with the bottlenecks/inner loop inasm.That is how software used to be written though. If you have no Ccompiler,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 othercame up with "incremental linkers", a wretched attempt to improve thespeedof 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
"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 2assemblyfunctions, one for drawing a slice of a vertical wall, and one for drawingaslice 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++ orDwon'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