January 09, 2012
On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:
>   "Zo-mah-gawd, look at the size of those D executables! D sux!"
>
> Which happens now.

My problem with this is a shared lib actually *increases*
the size. At best, it fools you by separating it out into
two or three files instead of one.

A better solution to the executable size problem is to
actually make them smaller, like Andrei was doing a couple
weeks ago. He made a huge difference just by changing a
handful of lines to reduce unnecessary coupling in Phobos.

> Note that the default with gcc is to link with the shared C runtime, and it will be expected for dmd.

The big difference there is people usually already have the
C runtime and use it for many programs. They don't actually
have to think about installing it.

Imagine how many people, especially on Linux, will now
start asking "I built a D program, but when I run it, it
complains that it can't find libphobos2.so", or the already
somewhat common version mismatches that happen when you update
one but not the other.


Would you rather have someone complaining about a 200 kb
executable, on an executable that doesn't work right without
end user action?
January 09, 2012
Am 09.01.2012, 04:59 Uhr, schrieb Adam D. Ruppe <destructionator@gmail.com>:

> On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:
>>   "Zo-mah-gawd, look at the size of those D executables! D sux!"
>>
>> Which happens now.
>
> My problem with this is a shared lib actually *increases*
> the size. At best, it fools you by separating it out into
> two or three files instead of one.
>
> A better solution to the executable size problem is to
> actually make them smaller, like Andrei was doing a couple
> weeks ago. He made a huge difference just by changing a
> handful of lines to reduce unnecessary coupling in Phobos.
>
>> Note that the default with gcc is to link with the shared C runtime, and it will be expected for dmd.
>
> The big difference there is people usually already have the
> C runtime and use it for many programs. They don't actually
> have to think about installing it.
>
> Imagine how many people, especially on Linux, will now
> start asking "I built a D program, but when I run it, it
> complains that it can't find libphobos2.so", or the already
> somewhat common version mismatches that happen when you update
> one but not the other.
>
>
> Would you rather have someone complaining about a 200 kb
> executable, on an executable that doesn't work right without
> end user action?

We will have to install the libraries into a sensible place by default.
Also multiple processes using the same shared library will benefit from
memory savings.
January 09, 2012
On Monday, 9 January 2012 at 04:54:45 UTC, Martin Nowak wrote:
> We will have to install the libraries into a sensible place by default.

Right now, you can just unzip it and go. Are we going
to break that too?


> Also multiple processes using the same shared library will benefit from memory savings.

We're talking maybe, MAYBE, one megabyte here.
January 09, 2012
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:oftpypayqrnhjqkmwthk@dfeed.kimsufi.thecybershadow.net...
> On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:
>>   "Zo-mah-gawd, look at the size of those D executables! D sux!"
>>
>> Which happens now.
>
> My problem with this is a shared lib actually *increases* the size. At best, it fools you by separating it out into two or three files instead of one.
>
> A better solution to the executable size problem is to actually make them smaller, like Andrei was doing a couple weeks ago. He made a huge difference just by changing a handful of lines to reduce unnecessary coupling in Phobos.
>
>> Note that the default with gcc is to link with the shared C runtime, and it will be expected for dmd.
>
> The big difference there is people usually already have the C runtime and use it for many programs. They don't actually have to think about installing it.
>
> Imagine how many people, especially on Linux, will now
> start asking "I built a D program, but when I run it, it
> complains that it can't find libphobos2.so", or the already
> somewhat common version mismatches that happen when you update
> one but not the other.
>
>
> Would you rather have someone complaining about a 200 kb executable, on an executable that doesn't work right without end user action?

Absolutely agree 100%.

Besides, "1MB Hello Word?!?" is just moronic whining. Christ, I'm on a 32-bit single-core with 2GB ram, I bitch about software bloat constantly, and yet even **I** don't give half a shit about it, and even I'm not *remotely* inconvenienced by trivial apps being a few hundred k, or even a few M, too large. WTF does it matter? Those people are just trying to find bullshit to moan about. Fix that and they'll find some reason to whine about underscores in numeric literals.

Additionally, Phobos is different with every release. Are we seriously going to expect D users, and worse - the end-users of D-made software, to have their system cluttered with libphobos2-065.so, libphobos2-066.so, libphobos2-067.so, etc. Or are we going to pretend that issue doesn't exist and create our own little DDLL hell? (And on top of that: "Why do I have hundreds of megs worth of this damn libphobos?") Even if dynamic phobos does become default at some point, *at the very least*, it shouldn't be until Phobos stabalizes. Realistically, it shouldn't be until libphobos is stable *and* about as common as libc.


January 09, 2012
> Realistically, it shouldn't be until libphobos is stable *and* about as common as libc.

Exactly. It doesn't make any sense as long as there's a new version every month.
We should do something about dead code elimination though.
-ffunction-sections -fdata-sections -L--gc-sections greatly reduces the size with gdc, but you can't expect users to always pass that.
January 09, 2012
On 9 January 2012 15:14, Trass3r <un@known.com> wrote:

> Realistically, it shouldn't be until libphobos is stable *and* about as
>> common as libc.
>>
>
> Exactly. It doesn't make any sense as long as there's a new version every
> month.
> We should do something about dead code elimination though.
> -ffunction-sections -fdata-sections -L--gc-sections greatly reduces the
> size with gdc, but you can't expect users to always pass that.
>

static this() seems to be a problem. Unless there's powerful
whole-program-optimisation, how can it strip out any data that might be
initialised/touched in static this()?

Why wouldn't dead code be eliminated effectively already?


January 09, 2012
> static this() seems to be a problem. Unless there's powerful
> whole-program-optimisation, how can it strip out any data that might be
> initialised/touched in static this()?
It probably can't.

> Why wouldn't dead code be eliminated effectively already?
Cause 1 section is created for each module. So if you use just 1 function the whole module is pulled in.
January 09, 2012
On 9 January 2012 15:27, Trass3r <un@known.com> wrote:

> static this() seems to be a problem. Unless there's powerful
>> whole-program-optimisation, how can it strip out any data that might be initialised/touched in static this()?
>>
> It probably can't.


I'm sure it's possible, but it would need some pretty powerful global
expression analysis.
Ie, if data initialised in static this() is only touched in one function
lets say, and that function is never referenced, then it should surely be
able to safely eliminate that function and associated data?

Why wouldn't dead code be eliminated effectively already?
>>
> Cause 1 section is created for each module. So if you use just 1 function the whole module is pulled in.
>

Why would it pull the whole module if only one function is used? And why can't a post-link strip process clean it up?


January 09, 2012
> I'm sure it's possible, but it would need some pretty powerful global expression analysis.
> Ie, if data initialised in static this() is only touched in one function
> lets say, and that function is never referenced, then it should surely be
> able to safely eliminate that function and associated data?

You need LTO for that.

> Why would it pull the whole module if only one function is used?
http://elinux.org/Function_sections

> And why can't a post-link strip process clean it up?

Everything's already merged by then.
1 2 3 4 5 6 7 8
Next ›   Last »