digitalmars.D.learn - Building DMD with DMD or LDC
- =?UTF-8?B?Tm9yZGzDtnc=?= (2/2) Oct 13 2016 Is there a large speed difference in compilation time depending
- Daniel Kozak via Digitalmars-d-learn (3/5) Oct 13 2016 You can easy try it. Just build dmd with dmd, than with ldc. And then
- =?UTF-8?B?Tm9yZGzDtnc=?= (55/61) Oct 13 2016 When I replace dmd with ldmd2 in the last call of the build it
- Daniel Kozak via Digitalmars-d-learn (3/17) Oct 13 2016 This seems like a bug to me, you should fill an issue on ldc github
- =?UTF-8?B?Tm9yZGzDtnc=?= (2/4) Oct 14 2016 Done: https://github.com/ldc-developers/ldc/issues/1829
- Jonathan M Davis via Digitalmars-d-learn (22/24) Oct 14 2016 I would be shocked if there weren't. The dmd backend does a much worse j...
- ketmar (11/16) Oct 15 2016 i did that out of curiosity some time ago, but with gdc, and then
- ketmar (3/3) Oct 15 2016 On Saturday, 15 October 2016 at 07:39:31 UTC, ketmar wrote:
- Johan Engelen (17/28) Oct 16 2016 This topic came up at the start of the year, and Iain pointed out
Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?
Oct 13 2016
You can easy try it. Just build dmd with dmd, than with ldc. And then try to compile DMD frontend with both dmd versions :) Dne 13.10.2016 v 21:07 Nordlöw via Digitalmars-d-learn napsal(a):Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?
Oct 13 2016
On Thursday, 13 October 2016 at 19:28:11 UTC, Daniel Kozak wrote:You can easy try it. Just build dmd with dmd, than with ldc. And then try to compile DMD frontend with both dmd versions :) Dne 13.10.2016 v 21:07 Nordlöw via Digitalmars-d-learn napsal(a):When I replace dmd with ldmd2 in the last call of the build it crashes as CC=c++ ldmd2 -ofdmd -m64 -vtls -J. -J../res -L-lstdc++ -version=MARS -wi -O -release -inline access.d aggregate.d aliasthis.d apply.d argtypes.d arrayop.d arraytypes.d attrib.d builtin.d canthrow.d clone.d complex.d cond.d constfold.d cppmangle.d ctfeexpr.d dcast.d dclass.d declaration.d delegatize.d denum.d dimport.d dinifile.d dinterpret.d dmacro.d dmangle.d dmodule.d doc.d dscope.d dstruct.d dsymbol.d dtemplate.d dversion.d entity.d errors.d escape.d expression.d func.d globals.d hdrgen.d id.d identifier.d impcnvtab.d imphint.d init.d inline.d intrange.d json.d lexer.d lib.d link.d mars.d mtype.d nogc.d nspace.d opover.d optimize.d parse.d sapply.d sideeffect.d statement.d staticassert.d target.d tokens.d traits.d utf.d visitor.d typinf.d utils.d statementsem.d safe.d objc_stubs.d libelf.d scanelf.d irstate.d toelfdebug.d toctype.d glue.d gluelayer.d todt.d tocsym.d toir.d dmsc.d tocvdebug.d backend/bcomplex.d backend/cc.d backend/cdef.d backend/cgcv.d backend/code.d backend/cv4.d backend/dt.d backend/el.d backend/global.d backend/obj.d backend/oper.d backend/outbuf.d backend/rtlsym.d backend/ty.d backend/type.d tk/dlist.d root/aav.d root/array.d root/ctfloat.d root/file.d root/filename.d root/man.d root/outbuffer.d root/port.d root/response.d root/rmem.d root/rootobject.d root/speller.d root/stringtable.d newdelete.o glue.a backend.a tk/dlist.d(51): list_inited is thread local backend/cgcv.d(26): ftdbname is thread local 0 ldc2 0x00000000013af6a5 1 ldc2 0x00000000013ae05e 2 ldc2 0x00000000013ae19a 3 libpthread.so.0 0x00007f3ce59443d0 4 ldc2 0x00000000012fcd94 5 ldc2 0x0000000001350a42 6 ldc2 0x00000000013532fd 7 ldc2 0x0000000001315d2a 8 ldc2 0x0000000001315e0e 9 ldc2 0x0000000001315f24 10 ldc2 0x00000000006cb40b 11 ldc2 0x00000000006e1c77 12 ldc2 0x00000000006daf86 13 ldc2 0x0000000000686488 14 ldc2 0x000000000058a1c9 15 ldc2 0x000000000068847b 16 ldc2 0x00000000013e2fff _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 15 17 ldc2 0x00000000013e2fc4 18 ldc2 0x00000000013e2eed 19 libc.so.6 0x00007f3ce506a830 __libc_start_main + 240 20 ldc2 0x000000000049c751 Error: Error executing /home/per/.local/ldc2-1.1.0-beta3-linux-x86_64/bin/ldc2: Segmentation fault (core dumped) I'm using LDC 1.1.0-beta3 on Ubuntu 16.04.Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?
Oct 13 2016
Dne 14.10.2016 v 00:06 Nordlöw via Digitalmars-d-learn napsal(a):On Thursday, 13 October 2016 at 19:28:11 UTC, Daniel Kozak wrote:This seems like a bug to me, you should fill an issue on ldc github tracker. Can you try it with latest stable ldc (1.0)?You can easy try it. Just build dmd with dmd, than with ldc. And then try to compile DMD frontend with both dmd versions :) Dne 13.10.2016 v 21:07 Nordlöw via Digitalmars-d-learn napsal(a):When I replace dmd with ldmd2 in the last call of the build it crashes as ... Error: Error executing /home/per/.local/ldc2-1.1.0-beta3-linux-x86_64/bin/ldc2: Segmentation fault (core dumped) I'm using LDC 1.1.0-beta3 on Ubuntu 16.04.Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?
Oct 13 2016
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> On Friday, 14 October 2016 at 06:05:21 UTC, Daniel Kozak wrote:This seems like a bug to me, you should fill an issue on ldc github tracker. Can you try it with latest stable ldc (1.0)?Done: https://github.com/ldc-developers/ldc/issues/1829
Oct 14 2016
On Thursday, October 13, 2016 19:07:44 Nordlöw via Digitalmars-d-learn wrote:Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?I would be shocked if there weren't. The dmd backend does a much worse job at optimization (especially with range-based code). I think that at one point, it was thought that the difference in compilation speed after switching dmd to D was about 20% thanks to the backend change (since previously, it would have been compiled with gcc), and at least initially, they didn't want to release a version of dmd that used the front-end in D until it could be built with gdc or ldc, because they didn't want to release a compiler that was that much slower. I don't know what they actually ended up doing, but I'd guess that the official dmd releases are currently built with LDC. Before the front-end was switched to D, my main machine could build all of the Phobos unit tests and run them in under 5 minutes, whereas after the switch to D, it couldn't. So, I definitely noticed the difference on my machine, but I've never gotten around to setting LDC up on my machine to use it to compile dmd. Aside from compiling Phobos, I don't have any projects large enough for it to matter (but it clearly matters on larger projects). Now, the folks using Windows wouldn't have seen the same performance hit as those using one of the POSIX OSes (since dmc uses the same backend as dmd), but presumably, building dmd with LDC on Windows would result in a faster dmd just like it does on *nix. - Jonathan M Davis
Oct 14 2016
On Friday, 14 October 2016 at 15:13:58 UTC, Jonathan M Davis wrote:On Thursday, October 13, 2016 19:07:44 Nordlöw via Digitalmars-d-learn wrote:i did that out of curiosity some time ago, but with gdc, and then tested my projects, and phobos rebuilding. speed difference was so small that it can be a usual random deviation. yet i didn't tried ldc, maybe ldc does better. but dmd itself doesn't use ranges extensively, so i don't think that it really matters. that is, maybe in some corner cases the difference will be noticable, but most of the time building dmd with ldc/gdc means only "let's wait significantly longer for nothing".Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?I would be shocked if there weren't.
Oct 15 2016
On Saturday, 15 October 2016 at 07:39:31 UTC, ketmar wrote: p.s. this is all about GNU/Linux on x86 arch. for other OS/arch it may be completely different.
Oct 15 2016
On Saturday, 15 October 2016 at 07:39:31 UTC, ketmar wrote:On Friday, 14 October 2016 at 15:13:58 UTC, Jonathan M Davis wrote:This topic came up at the start of the year, and Iain pointed out that the compiler code overrides the default memory management, which increases performance enormously. But, that malloc override was _only enabled when built with DMD_. https://forum.dlang.org/post/vqjzqadpxwfzvlptpypz forum.dlang.org This was fixed for LDC here: https://github.com/dlang/dmd/pull/5631/files It resulted in a massive speed gain when the front-end is built with LDC. I no longer have the numbers, but DMD built with LDC is definitely faster. About 10% according to the old thread. Same for LDC built with LDC. (self promotion: when you compile the same code over and over, you gain another ~7% when using PGO: https://johanengelen.github.io/ldc/2016/04/13/PGO-in-LDC-virtual-calls.html) -JohanOn Thursday, October 13, 2016 19:07:44 Nordlöw via Digitalmars-d-learn wrote:i did that out of curiosity some time ago, but with gdc, and then tested my projects, and phobos rebuilding. speed difference was so small that it can be a usual random deviation.Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?I would be shocked if there weren't.
Oct 16 2016