How to stop DMD from exploding the executable file size?

[ryuukk_]

On Saturday, 3 September 2022 at 01:59:56 UTC, max haughton wrote:
> On Saturday, 3 September 2022 at 00:49:36 UTC, ryuukk_ wrote:
>> On Friday, 2 September 2022 at 17:53:51 UTC, max haughton 
>> wrote:
>>> On Tuesday, 30 August 2022 at 22:51:46 UTC, ryuukk_ wrote:
>>>> Having this simple code makes the executable gigantic!
>>>>
>>>> ```D
>>>> struct Big
>>>> {
>>>>     int[1024 * 1024] big = 0;
>>>> }
>>>>
>>>> Big big;
>>>> ```
>>>>
>>>> Only with DMD, LDC produces a tiny executable
>>>>
>>>> Is there a flag available to fix this behavior? it's not 
>>>> sustainable
>>>
>>> You really shouldn't have structs this big unless absolutely 
>>> necessary.
>>>
>>> The thing being elided is the initializer and pointer bitmap 
>>> for the runtime to use.
>>
>> My use case should not makes us blind about the issue DMD is 
>> having
>>
>> I tested with both C and Zig, and they both produce small 
>> executable
>>
>> If DMD can do it on linux, there is no reason it can't do it 
>> on windows, if LDC can do it for both
>>
>> I want to promote D, i can't promote D if i tell people "yeah 
>> but X, Y, Z, then you should go with X, when Z, and when stars 
>> are aligned, maybe"
>>
>> It just feels bad; and the list of things that feels bad 
>> starts to stack up to a point it becomes sad
>
> 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.

It contributes, and give them arguments

> 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.

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

> 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.

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


> 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.


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