Hello, folks! Newbie to D, have some questions!

timmyjose via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Feb 21 09:31:21 PST 2017


On Monday, 20 February 2017 at 17:36:32 UTC, H. S. Teoh wrote:
> On Mon, Feb 20, 2017 at 03:00:05PM +0000, timmyjose via 
> Digitalmars-d-learn wrote: [...]
>> Just one question about the compilers though - I read on the 
>> Wiki that there are three main compiler distros - dmd, ldc, 
>> and gdc. I code primarily on a mac, and I have installed both 
>> dmd and ldc. A lot of the flags appears to be similar, and for 
>> my small programs, compilation and execution speed appeared to 
>> be almost identical. However, the book suggested using dmd for 
>> dev and probably ldc/gdc for releases. Is this really followed 
>> that much in practice, or should I prefer dmd?
>
> Personally, I use dmd git HEAD for 90% of my D projects, 
> because (1) I'm such a sucker for the latest and greatest 
> features, bugfixes, language changes, etc., and (2) I 
> occasionally contribute to the compiler toolchain (mainly 
> Phobos, sometimes druntime or dmd itself) and it's much easier 
> to debug something I use on a regular basis and not have to 
> switch to a different version or waste time chasing down a 
> compiler bug that's already been fixed in git HEAD.

Thank you, that's great to hear! I have installed both dmd and 
ldc on my mac box and am experimenting with both as well :-)

> However, when I need performant code, I pull up my trusty, 
> rusty old gdc (which, unfortunately, tends to be about a 
> version or two behind the main dmd release -- I believe Iain is 
> working on improving this, though). In spite of Walter being a 
> renowned compiler genius, he simply has too many things on his 
> plate and working on the optimizer hasn't been a high priority, 
> so gdc's optimizer easily beats dmd (sometimes by a long 
> stretch).  Don't get me wrong; for your average desktop 
> application, dmd output is more than good enough. It only 
> really matters when you're dealing with CPU-intensive 
> performance-critical things like maintaining framerate in a 
> complex game engine, or real-time software where somebody dies 
> if the program fails to respond within a 10ms margin, or when 
> you're trying to solve a PSPACE-complete exponential problem 
> where a 20ms difference in inner loop performance could mean 
> the difference between getting a result next week vs. next year 
> (or next millenium).

That makes a whole lot of sense.

> But if you're a stickler for high-performance code, gdc's 
> optimizer far outstrips dmd's in just about every way that I 
> can think of -- more aggressive inlining, better loop 
> optimization, better codegen in general.  And reputedly ldc has 
> comparable performance gains over dmd as well, so that's 
> another option.  The only downside is that gdc releases are 
> tied to the gcc release cycle, so it tends to be about a 
> version or two behind mainline dmd, and ldc is about a version 
> behind AFAIK.  But as far as the basics of D are concerned, 
> that shouldn't make a big difference, unless you're unlucky 
> enough to be bitten by a compiler bug that has no workaround 
> and that's only fixed in the latest dmd release. Thankfully, 
> though, compiler bugs of that sort have been quite rare (and 
> getting rarer with recent releases).
>
>
>> One more thing I noticed when I looked into the executable 
>> file (using "nm -gU" on my mac) is that I found two 
>> interesting symbols - _main and _Dmain.  On Rust, for 
>> instance, the main function got turned into _main, so I 
>> couldn't use a main in the C code that I was trying to interop 
>> with from my Rust code. In this case, does the same 
>> restriction apply (I am still way too far from dabbling in 
>> interop in D as yet! :-)). I mean, suppose I write some sample 
>> code in C, and I have a local main function to test the code 
>> out locally, will I have to comment that out when invoking 
>> that library from D, or can I keep that as is?

> _Dmain is the entry point of your D program, and is only 
> emitted if you have a main() function in your D code.  In that 
> case, you'll want the druntime version of _main (which does a 
> bunch of setup necessary before _Dmain is called).

Ah, I see. Now I understand why those two symbols are there!

>But if you're calling D from C code, i.e., the C code defines 
>main(),
> then you wouldn't also write a main() in D code (obviously -- I 
> hope), though you *would* need to call a druntime hook to 
> initialize some D runtime things needed before you call any D 
> code. (Sorry, can't remember the exact calls off the top of my 
> head, but it's a simple matter of calling an init routine or 
> two at startup, before invoking any D code, then calling the 
> cleanup routine at the end before the program exits. Pretty 
> standard stuff.)
>
>
> T

Got it! So you're saying that in case I want to call D code from 
C, then I do need to take care of some initialisation for the D 
runtime so that I can call the D library's code. That makes sense 
indeed.



More information about the Digitalmars-d-learn mailing list