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