"Choose your compiler"

[CyberShadow]

http://forum.dlang.org/post/kxdubhecvzwpvogvtrbx@forum.dlang.org

[ibuclaw]

Seems rather unfair that gdc gets the infinitely resizeable svg, and poor dmd and ldc are such with pngs. But then again I'm not complaining. :)

[CyberShadow]

I don't think we have a SVG of D-Man, and Illustrator's SVG export of the LDC dragon introduces some visual artefacts.

[ibuclaw]

How can I view the changes? I'm getting:

500(Internal Server Error)
An unexpected error has occured within the server software.
Error details:
object.Exception@ae/sys/git.d(153): Malformed header during cat-file: 

In the documentation PR check.

[CyberShadow]

Yeah, I'm trying to fix the autotester right now.

Here's a screenshot for the meanwhile:

[ibuclaw]

You seem to have an uneven bias between Good code optimization and Great code optimization.

[CyberShadow]

My understanding was that LDC often outperforms GDC on typical D code due to better inlining of lambdas.

[CyberShadow]

@klickverbot ?

[John-Colvin]

@CyberShadow GDC and LDC produce similar quality code in my experience, especially when using a gcc5.x backend for GDC. While it is completely clear that both GDC and LDC outperform DMD, I don't think any generally applicable, meaningful distinction can be drawn between GDC and LDC codegen quality.

I did used to see some important differences in favour of LDC for high-level optimisations and GDC for low-level about 2 years ago, but well, that was 2 years ago...

[CyberShadow]

LDC beats GDC in two thirds of the benchmarks from @klickverbot's 2013 DConf talk:
http://dconf.org/2013/talks/nadlinger.pdf

I don't mind changing it, though any other useful distinctions to add? When would one want to use one instead of the other? E.g. interoperability with some popular tools?

[dnadlinger]

Just make it say the same. On my collection of microbenchmarks, LDC still beats GDC in most of them, but apart from some D-specific optimizations we added to the optimization pipeline, it really comes down to GCC vs. LLVM.

Some characteristics might be that LDC works fine out of the box on recent OS X versions [1] and is routinely released for Win32/Win64 (the latter still being experimental), whereas GDC currently seems to be further along when it comes to 32 bit ARM Linux support.

[1] I can't even compile GDC because it tries to find something in /usr/include which seems to be hardcoded, even though ./configure runs fine.

Edit: Oh, and LDC often produces >10x smaller binaries on Linux. ;)

[ibuclaw]

LDC beats GDC in two thirds in the benchmarks from @klickverbot's 2013 DConf talk

Doesn't say much, optimisations in normal everyday user applications speaks more volumes than any benchmark I've ever come across... I could easily do a talk and show similar sort of graphs that show the same thing in reverse. Just need to exploit pathological cases where GCC beats LLVM. ;-)

I don't mind changing it, though any other useful distinctions to add?

Maybe the toolchain? Such as GDC/GDB are more in lock-step than LDC (though this is no coincidence). LDC might work better with LLDB, but I don't know.

[ibuclaw]

whereas GDC currently seems to be further along when it comes to 32 bit ARM Linux support.

Pick any of the supported Debian targets, and we are further along.

https://packages.debian.org/sid/gdc-5

[dnadlinger]

@ibuclaw: Do you support shared libraries (including druntime/Phobos) on Linux yet? If not, that would be another distinction.

[dnadlinger]

Pick any of the supported Debian targets, and we are further along.

https://packages.debian.org/sid/gdc-5

You fully pass the test suite on Alpha? Color me (slightly) impressed.

[ibuclaw]

Do you support shared libraries (including druntime/Phobos) on Linux yet?

As I understand it, it's only possible with emulated TLS, though even then, it's not something turned on in-tree.

You fully pass the test suite on Alpha? Color me (slightly) impressed.

I know that we have fully passed on ARM's flavours, probably with some mixed results (eg: still need a solution for dlang/dmd#4895), other official ports I'd expect to still have warts (haven't checked my emails from debian's build bots in a while). Unofficial ports such as Alpha are built without-library. So you could probably uncolour yourself just a little. ;-)

[ibuclaw]

Unofficial ports such as Alpha are built without-library.

However, it does mean that with the compiler there, people can get the binaries and start porting the runtime now, if they have the hardware. :)

[JackStouffer]

@CyberShadow: I would also add a bullet point of what platforms each compiler supports.

[CyberShadow]

@ibuclaw @klickverbot Could you please update http://wiki.dlang.org/Compilers ? I'm seeing some discrepancies between that page's contents and the discussion here. (E.g. the page claims platform and architecture support is the same across the board, except for LDC also supporting PPC). Perhaps also add other platform/compiler-specific features such as shared libraries, fibers, etc.

[ibuclaw]

Could you please update http://wiki.dlang.org/Compilers ?

There are too many of these kinds of lists. All incorrect. :)

[CyberShadow]

Let's please fix this one then, as it is what the "(more information)" link points to, and we should have such a link/page.

[John-Colvin]

@ibuclaw Is there any other even semi-official list that is in conflict with http://wiki.dlang.org/Compilers? I can't find any.

[jpf91]

Perhaps also add other platform/compiler-specific features such as shared libraries, fibers, etc.

I've added some information about shared libraries. DMD/LDC information should probably be reviewed / extended.
I don't think we need to document anything about Fibers. These are architecture specific but not necessarily compiler specific. Also a compiler without Fiber support can't claim full platform support as we have unittests which test Fibers. The only meaningful difference is native support vs ucontext. But as soon as one compiler supports an architecture directly the code is shared with the other compilers anyway (threadAsm.S). You could even say DMD has working ARM Fibers support, although there's no ARM backend ;-)

[CyberShadow]

Thanks Johannes.

Maybe the toolchain? Such as GDC/GDB are more in lock-step than LDC (though this is no coincidence).

So is GDC's GDB compatibility also better than DMD?

[ibuclaw]

So is GDC's GDB compatibility also better than DMD?

Of course! A lot of the stuff I talked about last year only works with gdc because no other compiler emits required debug code to enable such features.

[CyberShadow]

OK, I updated http://wiki.dlang.org/Compilers using information from http://wiki.dlang.org/LDC and updated the PR respectively.

@klickverbot @redstar When you find a minute, please have a look.

[MartinNowak]

Here's a screenshot for the meanwhile:

We desperately need some people that can do better artwork ;-).

[MartinNowak]

Please rebase, then we should be good to go.

[CyberShadow]

Rebased