Just look: https://i.imgur.com/5JheSIA.png

5mb for DMD

200kb for LDC

Both release build

It is very sad, what is walter doing?

On Saturday, 3 September 2022 at 00:51:09 UTC, ryuukk_ wrote:

Working. Building us great stuff that he gives to all of us free.

If the dmd executables are too large for you, use ldc for release builds. Or you can get smaller release builds with dmd by linking the object files yourself. I don't understand why you are still complaining.

On Saturday, 3 September 2022 at 00:49:36 UTC, ryuukk_ wrote:

struct Big
{
    int[1024 * 1024] big = 0;
}

Big big;

If this is what stops them from using D they're using it as a toy - it's a completely nonsensical pattern 99% of the time. Huge structs usually imply a lack of understanding, for example you could easily blow up the stack.

I will at very least try and fix this in dmd, it's just the object emission code being overly conservative (ldc will emit the initializer if you do something that actually needs it), but if this is what stops them using D I would be very skeptical. C doesn't even have struct default-initializers.

In reality, the stars have to align the other way - we have lots of people writing D code every day, some of which might not be entirely sure what an object file even is, 99% of the time this kind of stuff just doesn't matter.

In line with the above statement, the actual answer here is to try and compress the big initializers rather than faff around with whether they are used or not - should the compiler focus on dead code elimination rather than optimizing the stuff that actually runs?

Most of these initializers will be zero, god forbid someone does statically allocate their tensor in a structure potentially we can give them a speed/size tradeoff.

Everyone making a living out of D's workflow that I'm aware of is prototype with dmd, ship with ldc or gdc. This should be enshrined in the toolchain, it is not currently but maybe it will be sooner rather than later.

I do like small binaries but I can count on 1 hand the number of times it's seemed important and on zero hands the number of time it's actually mattered in practice.

If it, in your estimation, does make it a difference it may be of note that PGO can make the inlining much more intelligent and thus save you potentially even double digit percentages of the non-PGO build's size.

On Saturday, 3 September 2022 at 01:59:56 UTC, max haughton wrote:

struct Big
{
    int[1024 * 1024] big = 0;
}

Big big;

It contributes, and give them arguments

If LDC did it, DMD can do it, specially if it can already do it in linux

Assumptions, we have to stop with assuming what people like, and do things the right way

We have to stop putting the burden on the users

This is a DMD problem, i am a user, my expectation is it should produce a non bloated executable, that's it, as a user i think that's fair to expect that from a compiler that produce native executables

And i show you the release build, on debug it is worse, building 10+mbs files constantly, it'll worn the disk, and it makes file transfer painfully slow over the net

Again, i am a user, not a compiler person

Thanks to @Herringway on IRC, he made me check dmd/ldc linker invocation and check the difference

LDC seem to add:

    /OPT:REF
    /OPT:ICF

Adding both and now DMD produce small file! (1mb vs 10mb before)

Can we have them enabled by default?

I went ahead and sent a PR: https://github.com/dlang/dmd/pull/14418

Never give up