www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.14.0 alpha1 released! Please help test!

reply "Kai Nacke" <kai redstar.de> writes:
Hi everyone!

The first alpha release of LDC release 0.14.0 is here! It is 
based on the 2.065.0 front-end and
LLVM 3.1-3.4.2 (OS X: LLVM 3.2/3.4.2 only).

This release contains some exciting new features like shared 
libraries on Linux!
Be sure to read the preliminary change log at the GitHub release 
page which also has the package download links:
https://github.com/ldc-developers/ldc/releases/tag/v0.14.0-alpha1

MD5 checksums for the release packages:

16cec8be4c694082f6dc80c72e447e2b ldc-0.14.0-alpha1-src.tar.gz
cbdd5446c15db0ebd563e06e6e7f57ed 
ldc2-0.14.0-alpha1-linux-x86.tar.gz
8c16b0746765295446acbc7775ac4162 
ldc2-0.14.0-alpha1-linux-x86.tar.xz
a70e9f3e6aab43de958185553c1ee0ad 
ldc2-0.14.0-alpha1-linux-x86_64.tar.gz
3c2a231e75531e6e36f42d1eea4fed48 
ldc2-0.14.0-alpha1-linux-x86_64.tar.xz
5e379188d9d366423caa69d948c11772 ldc2-0.14.0-alpha1-mingw-x86.7z
c2bbbd9595208ee3afe05253c40a84d0 ldc2-0.14.0-alpha1-mingw-x86.zip
b017833757a9871d2ac798988de58cb6 
ldc2-0.14.0-alpha1-osx-x86_64.tar.gz
c2d8b1bd501bfa59a84f8409194bb6c0 
ldc2-0.14.0-alpha1-osx-x86_64.tar.xz

As always, the Win32/MinGW packages require a recent version of 
the
mingw-w64 toolchain, see the (new) README file for details.

There is no Win64/MSVC package yet. Nevertheless the 
implementation had made a
huge step forward thanks to the help from Trass3r.

Please be sure to report any bugs at
https://github.com/ldc-developers/ldc/issues, and feel free to 
drop by
at the digitalmars.D.ldc forums
(http://forum.dlang.org/group/digitalmars.D.ldc) for any 
questions or
comments.

Thanks to everybody involved in making this happen!

Regards,
Kai
Aug 02 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 5e379188d9d366423caa69d948c11772 ldc2-0.14.0-alpha1-mingw-x86.7z


It seems to work.
I presume there is no "unsafe FP optimizations" yet.
I think ldmd2 doesn't show the -nogc switch.
I have not seen a significant reduction of the produced binary 
sizes.

Bye,
bearophile
Aug 02 2014
parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 2 Aug 2014, at 17:41, bearophile via digitalmars-d-ldc wrote:

 I have not seen a significant reduction of the produced binary sizes.


The MinGW linker unfortunately does not support --gc-sections. As of 
now, the feature unfortunately is Linux-only.

Cheers,
David
Aug 02 2014
prev sibling next sibling parent "Trass3r" <un known.com> writes:
 There is no Win64/MSVC package yet. Nevertheless the 
 implementation had made a
 huge step forward thanks to the help from Trass3r.


The biggest remaining issue is exception handling.
That patch from Twobit has not seen any progress afaik.
It sort of works but doesn't put things into comdats and thus may 
be related to the large executable size.
Aug 02 2014
prev sibling next sibling parent reply "John" <john.joyus gmail.com> writes:
On Saturday, 2 August 2014 at 15:11:52 UTC, Kai Nacke wrote:

 Hi everyone!

 The first alpha release of LDC release 0.14.0 is here! It is 
 based on the 2.065.0 front-end and
 LLVM 3.1-3.4.2 (OS X: LLVM 3.2/3.4.2 only).



I have tried it on Ubuntu 64-bit machine.

It's generating small and fast executables!!
My interest for D is getting rekindled again! Thank you guys! :D
Aug 02 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
John:


 It's generating small and fast executables!!


What kind of executable sizes are you seeing? Like, what's the 
size for a hello world with writeln on a 64 bit Ubuntu?

Bye,
bearophile
Aug 02 2014
parent "John" <john.joyus gmail.com> writes:
On Saturday, 2 August 2014 at 23:22:35 UTC, bearophile wrote:

 What kind of executable sizes are you seeing? Like, what's the 
 size for a hello world with writeln on a 64 bit Ubuntu?


helloworld.d with writeln
dmd 472 KB
ldc 286 KB

stopwatch example from 

dmd  1.1 MB
ldc  322 KB

The ldc version of stopwatch runs more than 10x faster.

And the Average times displayed by the stopwatch is crazy:
(dmd) Average time: 4000.00 hnsecs (approx)
(ldc) Average time:    1.00 hnsecs (approx)
Aug 02 2014
prev sibling parent reply Russel Winder via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On Sat, 2014-08-02 at 22:50 +0000, John via digitalmars-d-ldc wrote:
[=E2=80=A6]

 It's generating small and fast executables!!
 My interest for D is getting rekindled again! Thank you guys! :D


I did a quick test of one tiny calculation, maximum optimization
switched on:

Compiler: size: elapse time
DMD v2.065: 1134444: 8.782991
GDC 4.9.1: 10073177: 8.837684
LDC master 22b74dc41a69ea49b4bb9dba588ed13611a9609f: 363973: 8.619940

So I can't say anything about fast, but I can clearly see small. This is
on Debian Sid.

I think for compilation times: DMD < LDC < GDC

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Aug 03 2014
parent reply "Dicebot" <public dicebot.lv> writes:
For this simple program:

```
import std.stdio, std.algorithm;

void main()
{
     auto arr = [ 1, 2, 3, 4 ];
     writeln(arr.map!(a => 2*a));
}
```

-rwxr-xr-x  1 dicebot users 581K Aug  3 16:52 dmd
-rwxr-xr-x  1 dicebot users 3.6M Aug  3 17:24 gdc
-rwxr-xr-x  1 dicebot users 2.2M Aug  3 16:54 ldc-old
-rwxr-xr-x  1 dicebot users 410K Aug  3 17:21 ldc-new

It is quite interesting that dmd binary size is so smaller than 
gdc and old ldc output - probably something related to frontend 
symbol emitting difference. I have also checked `nm -a` output 
and can confirmed that `ldc-new` is the only one that does not 
have inlined map symbols (including lambda) in the resulting 
binary.

output for stripped binaries:

-rwxr-xr-x  1 dicebot users 387K Aug  3 17:27 dmd
-rwxr-xr-x  1 dicebot users 2.6M Aug  3 17:27 gdc
-rwxr-xr-x  1 dicebot users 1.1M Aug  3 17:27 ldc-old
-rwxr-xr-x  1 dicebot users 274K Aug  3 17:27 ldc-new

compiling small vibe.d application that uses Diet templates:

-rwxr-xr-x 1 dicebot users  16M Aug  3 17:30 diet-dmd
-rwxr-xr-x 1 dicebot users 8.2M Aug  3 17:31 diet-ldc-new
Aug 03 2014
next sibling parent reply "FrankLike" <1150015857 qq.com> writes:
On Sunday, 3 August 2014 at 15:30:52 UTC, Dicebot wrote:

 For this simple program:

 ```
 import std.stdio, std.algorithm;

 void main()
 {
     auto arr = [ 1, 2, 3, 4 ];
     writeln(arr.map!(a => 2*a));
 }
 ```

 -rwxr-xr-x  1 dicebot users 581K Aug  3 16:52 dmd
 -rwxr-xr-x  1 dicebot users 3.6M Aug  3 17:24 gdc
 -rwxr-xr-x  1 dicebot users 2.2M Aug  3 16:54 ldc-old
 -rwxr-xr-x  1 dicebot users 410K Aug  3 17:21 ldc-new

 It is quite interesting that dmd binary size is so smaller than 
 gdc and old ldc output - probably something related to frontend 
 symbol emitting difference. I have also checked `nm -a` output 
 and can confirmed that `ldc-new` is the only one that does not 
 have inlined map symbols (including lambda) in the resulting 
 binary.

 output for stripped binaries:

 -rwxr-xr-x  1 dicebot users 387K Aug  3 17:27 dmd
 -rwxr-xr-x  1 dicebot users 2.6M Aug  3 17:27 gdc
 -rwxr-xr-x  1 dicebot users 1.1M Aug  3 17:27 ldc-old
 -rwxr-xr-x  1 dicebot users 274K Aug  3 17:27 ldc-new

 compiling small vibe.d application that uses Diet templates:

 -rwxr-xr-x 1 dicebot users  16M Aug  3 17:30 diet-dmd
 -rwxr-xr-x 1 dicebot users 8.2M Aug  3 17:31 diet-ldc-new


It's on Linux x64?
I'm on Windows x64,not use any Options ,the size is 3112kb,the 
old's exe size was 3394kb,it's smaller,but why so big on windows 
x64?
Thank you.
Frank
Aug 03 2014
next sibling parent "FrankLike" <1150015857 qq.com> writes:
On Sunday, 3 August 2014 at 23:07:22 UTC, FrankLike wrote:

 On Sunday, 3 August 2014 at 15:30:52 UTC, Dicebot wrote:

 For this simple program:

 ```
 import std.stdio, std.algorithm;

 void main()
 {
    auto arr = [ 1, 2, 3, 4 ];
    writeln(arr.map!(a => 2*a));
 }
 ```

 -rwxr-xr-x  1 dicebot users 581K Aug  3 16:52 dmd
 -rwxr-xr-x  1 dicebot users 3.6M Aug  3 17:24 gdc
 -rwxr-xr-x  1 dicebot users 2.2M Aug  3 16:54 ldc-old
 -rwxr-xr-x  1 dicebot users 410K Aug  3 17:21 ldc-new

 It is quite interesting that dmd binary size is so smaller 
 than gdc and old ldc output - probably something related to 
 frontend symbol emitting difference. I have also checked `nm 
 -a` output and can confirmed that `ldc-new` is the only one 
 that does not have inlined map symbols (including lambda) in 
 the resulting binary.

 output for stripped binaries:

 -rwxr-xr-x  1 dicebot users 387K Aug  3 17:27 dmd
 -rwxr-xr-x  1 dicebot users 2.6M Aug  3 17:27 gdc
 -rwxr-xr-x  1 dicebot users 1.1M Aug  3 17:27 ldc-old
 -rwxr-xr-x  1 dicebot users 274K Aug  3 17:27 ldc-new




  What Optins you know on Windows x64 ? I want let the exe file to 
small.
   Thank you.
   Frank
Aug 03 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 3 August 2014 at 23:07:22 UTC, FrankLike wrote:

 It's on Linux x64?
 I'm on Windows x64,not use any Options ,the size is 3112kb,the 
 old's exe size was 3394kb,it's smaller,but why so big on 
 windows x64?
 Thank you.
 Frank


It is Arch Linux x86_64, I don't use Windows.
Aug 03 2014
prev sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 3 Aug 2014, at 17:30, Dicebot via digitalmars-d-ldc wrote:

 It is quite interesting that dmd binary size is so smaller than gdc 
 and old ldc output - probably something related to frontend symbol 
 emitting difference.


This might be part of the reason. The much bigger cause is probably the 
fact that DMD emits each function (?) into a separate object file when 
building with -lib, whereas LDC emits one object file per module. This 
trick in DMD allows the linker to skip more of the unused symbols even 
without --gc-sections.

Cheers,
David
Aug 03 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
P.S. I have noticed that now libdruntime.a is not included into 
libphobos2.a and needs to be package too, is it intended or just 
unforeseen side effect of shared library support?
Aug 03 2014
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 3 Aug 2014, at 17:36, Dicebot via digitalmars-d-ldc wrote:

 P.S. I have noticed that now libdruntime.a is not included into 
 libphobos2.a and needs to be package too, is it intended or just 
 unforeseen side effect of shared library support?


This is an intended change. Let me elaborate a bit:

The linking behavior was indeed changed while introducing shared library 
support, as it is more or less the natural thing to do for shared 
libraries (some programs might only depend on druntime, and there should 
be only one copy of it. I could have left the way static libraries are 
built unchanged, but that would have required more logic for setting up 
the config files appropriately and so on. Additionally, we were actually 
building the object files twice before, so the build system internals 
for the static case needed a revision anyway.

In short, it probably doesn't make a lot of difference either way, but 
the split version seems a bit nicer conceptually and simplifies the 
build system a bit. If there is a good reason to revert to the previous 
version, this could definitely be done (although I probably won't have 
the time to do the changes until end of August).

This should definitely be mentioned in the release notes, though (the 
library name also changed to phobos2-ldc instead of phobos-ldc so as to 
avoid any transitioning problems).

Cheers,
David
Aug 03 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 3 August 2014 at 23:37:55 UTC, David Nadlinger via 
digitalmars-d-ldc wrote:

 On 3 Aug 2014, at 17:36, Dicebot via digitalmars-d-ldc wrote:

 P.S. I have noticed that now libdruntime.a is not included 
 into libphobos2.a and needs to be package too, is it intended 
 or just unforeseen side effect of shared library support?


 This is an intended change. Let me elaborate a bit:

 The linking behavior was indeed changed while introducing 
 shared library support, as it is more or less the natural thing 
 to do for shared libraries (some programs might only depend on 
 druntime, and there should be only one copy of it. I could have 
 left the way static libraries are built unchanged, but that 
 would have required more logic for setting up the config files 
 appropriately and so on. Additionally, we were actually 
 building the object files twice before, so the build system 
 internals for the static case needed a revision anyway.

 In short, it probably doesn't make a lot of difference either 
 way, but the split version seems a bit nicer conceptually and 
 simplifies the build system a bit. If there is a good reason to 
 revert to the previous version, this could definitely be done 
 (although I probably won't have the time to do the changes 
 until end of August).

 This should definitely be mentioned in the release notes, 
 though (the library name also changed to phobos2-ldc instead of 
 phobos-ldc so as to avoid any transitioning problems).

 Cheers,
 David


No problem, it took me only few minutes to figure out the changes 
and update the  packaging script. Just wanted to make sure it is 
known and intended change.
Aug 03 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 3 August 2014 at 23:47:29 UTC, Dicebot wrote:

 On Sunday, 3 August 2014 at 23:37:55 UTC, David Nadlinger via 
 digitalmars-d-ldc wrote:

 On 3 Aug 2014, at 17:36, Dicebot via digitalmars-d-ldc wrote:

 P.S. I have noticed that now libdruntime.a is not included 
 into libphobos2.a and needs to be package too, is it intended 
 or just unforeseen side effect of shared library support?


 This is an intended change. Let me elaborate a bit:

 The linking behavior was indeed changed while introducing 
 shared library support, as it is more or less the natural 
 thing to do for shared libraries (some programs might only 
 depend on druntime, and there should be only one copy of it. I 
 could have left the way static libraries are built unchanged, 
 but that would have required more logic for setting up the 
 config files appropriately and so on. Additionally, we were 
 actually building the object files twice before, so the build 
 system internals for the static case needed a revision anyway.

 In short, it probably doesn't make a lot of difference either 
 way, but the split version seems a bit nicer conceptually and 
 simplifies the build system a bit. If there is a good reason 
 to revert to the previous version, this could definitely be 
 done (although I probably won't have the time to do the 
 changes until end of August).

 This should definitely be mentioned in the release notes, 
 though (the library name also changed to phobos2-ldc instead 
 of phobos-ldc so as to avoid any transitioning problems).

 Cheers,
 David


 No problem, it took me only few minutes to figure out the 
 changes and update the  packaging script. Just wanted to make 
 sure it is known and intended change.


Have you considered creating dlang-*-prerelease/latest packages? 
It would be nice to be able to grab these alphas/betas/rcs 
through the arch repos or the AUR.
If they defaulted to the latest release when there isn't any 
pre-release available that would be even better.
Aug 05 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 5 August 2014 at 13:36:48 UTC, John Colvin wrote:

 Have you considered creating dlang-*-prerelease/latest 
 packages? It would be nice to be able to grab these 
 alphas/betas/rcs through the arch repos or the AUR.
 If they defaulted to the latest release when there isn't any 
 pre-release available that would be even better.


Well there is https://aur.archlinux.org/packages/ldc-git/ , I 
usually don't expect alpha/beta to last long enough for this to 
actually matter :) But that does not cost me anything, will add 
soon.
Aug 05 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 5 August 2014 at 17:04:42 UTC, Dicebot wrote:

 On Tuesday, 5 August 2014 at 13:36:48 UTC, John Colvin wrote:

 Have you considered creating dlang-*-prerelease/latest 
 packages? It would be nice to be able to grab these 
 alphas/betas/rcs through the arch repos or the AUR.
 If they defaulted to the latest release when there isn't any 
 pre-release available that would be even better.


 Well there is https://aur.archlinux.org/packages/ldc-git/ , I 
 usually don't expect alpha/beta to last long enough for this to 
 actually matter :) But that does not cost me anything, will add 
 soon.


Almost forgot to do it, this should do the trick: 
https://aur.archlinux.org/pkgbase/ldc-alpha/ (this is build with 
shared libraries)

btw, is there any way to generate both static and shared versions 
of libraries, same as it is done for dmd? I'd like to provide 
packages for both.
Aug 10 2014
parent "Dicebot" <public dicebot.lv> writes:
Btw with shared libraries enabled and --gc-sections "Hello, 
World!" binary is only 15K ;)
Aug 11 2014
prev sibling parent reply "FrankLike" <1150015857 qq.com> writes:
  Kai Nacke

 5e379188d9d366423caa69d948c11772 ldc2-0.14.0-alpha1-mingw-x86.7z
 c2bbbd9595208ee3afe05253c40a84d0 
 ldc2-0.14.0-alpha1-mingw-x86.zip


On Windows x64,a helloworld.exe's size is 3113kb. very big .

Maybe Win64/MSVC package is ok?

Thank you.
Frank
Aug 03 2014
parent reply "Trass3r" <un known.com> writes:
 On Windows x64,a helloworld.exe's size is 3113kb. very big .

 Maybe Win64/MSVC package is ok?


1.2MB, I suspect the unfinished uwtables implementation.

Here's a test version:
https://github.com/Trass3r/ldc/releases/download/v0.14.0-alpha1/ldc.7z
Aug 05 2014
parent reply "FrankLike" <1150015857 qq.com> writes:
On Tuesday, 5 August 2014 at 13:02:49 UTC, Trass3r wrote:

 On Windows x64,a helloworld.exe's size is 3113kb. very big .

 Maybe Win64/MSVC package is ok?


 1.2MB, I suspect the unfinished uwtables implementation.

 Here's a test version:
 https://github.com/Trass3r/ldc/releases/download/v0.14.0-alpha1/ldc.7z


Yes,Now it's 1248kb.but on ldc0.12.1, it's only 319kb.

Thank you .

Frank.
Aug 05 2014
parent reply "Trass3r" <un known.com> writes:
 Yes,Now it's 1248kb.but on ldc0.12.1, it's only 319kb.


An MSVC version of 0.12? With the EH patch?

Well, this is Hello World:
http://thecybershadow.net/d/mapview/view.php?id=53e10e9fd2704
Aug 06 2014
parent "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 6 August 2014 at 09:27:29 UTC, Trass3r wrote:

 An MSVC version of 0.12? With the EH patch?


A binary distribution was created by tae hoo based on an early 
version of the SEH patches, see
http://forum.dlang.org/thread/wrzsaoppngemvqikusac forum.dlang.org

I also distributed an early version but I think it was based on 
0.11.

Regards,
Kai
Aug 08 2014