<div class="gmail_quote">On Mon, Aug 1, 2011 at 8:38 PM, Adam D. Ruppe <span dir="ltr"><<a href="mailto:destructionator@gmail.com">destructionator@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">bearophile wrote:<br>
> In such situations it's never enough to compare the D code compiled<br>
> with DMD to the D code compiled with LDC. You also need a reference<br>
> point, like a C version compiled with GCC (here using GMP bignums).<br>
> Such reference points are necessary to anchor performance<br>
> discussions to something.<br>
<br>
</div>Actually, I don't think that would be relevant here.<br>
<br>
The thread started with someone saying the DMD backend is garbage<br>
and should be abandoned.<br>
<br>
I'm sick and tired of hearing people say that. The Digital Mars<br>
code has many, many advantages over the others*.<br>
<br>
But, it was challenged specifically on the optimizer, so to<br>
check that out, I wanted all other things to be equal.<br>
<br>
Same code, same front end, same computer, as close to same runtime<br>
and library is possible with different compilers. The only<br>
difference should be the backend so we can draw conclusions about<br>
it without other factors skewing the results.<br>
<br>
<br>
So for this, I just wanted to compare dmd backend to ldc and<br>
gdc backend so I didn't worry too much about absolute numbers<br>
or other languages. (Actually, one of the reasons I picked the<br>
pi one was after the embarrassing defeat in floating point, I was<br>
hoping dmd could score a second victory and I could follow up<br>
on that "prove it" post with satisfaction. Alas, the facts didn't<br>
work out that way. Though, I still do find dmd to beat g++<br>
on a lot of real world code - things like slices actually make<br>
a sizable difference.)<br>
<br>
But regardless, it was just about comparing backends, not<br>
doing language comparisons.<br>
<br>
===<br>
<br>
* To name a huge one. Today was the first time I ever got ldc<br>
or gdc to actually work on my computer, and it took a long, long<br>
time to do it. I've tried in the past, and failed, so this was<br>
a triumph. Big success.<br>
<br>
I was waiting over an hour just for gcc+gdc to compile! In the<br>
time it takes for gcc's configure script to run, you can make<br>
clean, build dmd, druntime and phobos.<br>
<br>
It's a huge hassle to get the code together too. I had to go<br>
to *four* different sites to get gdc's stuff together (like 80<br>
MB of crap, compressed!), and two different ones to get even the<br>
ldc binary to work. Pain in my ASS.<br>
<br>
<br>
And this is on Linux too. I pity the fool who tries to do this<br>
on Windows, knowing how so much linux software treats their<br>
Windows "ports".<br>
<br>
<br>
I'd like to contrast to dmd: unzip and play with wild abandon.<br></blockquote><div><br></div><div>Yes, GDC takes forever and a half to build. That's true of anything in GCC, and it's just because they don't trust the native C compiler at all. LDC builds in under a half hour, even on my underpowered ARM SoC, so I don't see how you could be having trouble there. </div>

</div>As for Windows, Daniel Green (hopefully I'm remembering right) has been posting GDC binaries.<div><br></div><div>I do respect that DMD generates reasonably fast executables recklessly fast, but it also doesn't exist outside x86 and x86_64 and the debug symbols (at least on Linux) are just hilariously bad.</div>

<div><br></div><div>Now if I could just get GDC to pad structs correctly on ARM...</div>