Laurent Bercot wrote on Wed, Feb 01, 2023 at 06:59:04PM +0000:
> > Look, here's a trivial, suboptimal wrapper, far from pretty:
> > (...)
> > (look, I said it wasn't pretty -- there are at least a dozen of problems
> > with this, but nothing a day of work I offered to do can't fix; I wrote
> > this because it was faster than talking without a concrete example to
> > have some figures, and that took me less time than the rest of this mail)
>
> Damn you to the nine circles of Hell, one by one, slowly, then all of
> them at the same time.
> You piqued my curiosity, so I did it, and I spent the day making it work.
I'm sorry -- I also know the feeling of doing myself something someone
suggested :-D
If that's any consolation, I'm also here testing it at 5AM...
> That said, you were right: that's some pretty hefty saving of disk
> space. The execline binary is 169kB, statically linked against musl on
> x86_64. That's neat. I expected it to be at least twice bigger. And
> the data/bss isn't too bad either: only 2 pages. But that's because
> execline programs use very little global memory in the first place -
> the only places where globals are used is when state needs to be
> accessed by signal handlers, and there's nothing I can do about that in
> short-lived programs. (Long-lived programs use a selfpipe, so only
> one int of global data is ever needed for them.)
Yes, this is only possible because you did a very good job in the first
place. Good work! This cannot be said enough.
> So, all in all, much better results than I expected, it was a pleasant
> surprise. Still, concatenating all the code feels really clunky, and
> a real multicall program needs to be designed for this from the start,
> which won't happen for execline in the foreseeable future, so this is
> as much as you get for now.
>
> If you're interested in hacking the thing, the magic happens in
> tools/gen-multicall.sh.
Will have a further look tomorrow.
I was also curious about starting time and should have done that in my
previous mail, it's a bit slower as expected.
Running 'execline-cd /' 50 times followed by 'true', I get:
$ hyperfine --warmup 5 -N 'cd / cd / ... true'
(multi)
Time (mean ± σ): 21.9 ms ± 2.1 ms [User: 5.0 ms, System: 16.7 ms]
Range (min … max): 17.2 ms … 26.7 ms 148 runs
(original)
Time (mean ± σ): 21.7 ms ± 1.9 ms [User: 5.0 ms, System: 16.5 ms]
Range (min … max): 16.8 ms … 24.9 ms 120 runs
so the original binary is slightly faster to load in a benchmark; but
I'm curious at the benefits one would get from not having to look for
and read multiple binaries in more real cases...
Either way it probably will be hard to notice.
> > libexecline is statically linked, so these pages aren't shared afaik?
>
> That's right, I forgot it was always statically linked. If it helps,
> changing ${LIBEXECLINE} to -lexecline in the src/execline/deps-exe
> files, then running ./tools/gen-deps.sh > package/deps.mak, should
> allow you to link against a dynamic libexecline. Can you do it, see
> how much space you gain? That's a configuration I would definitely
> support, even if it's slower - people usually love shared libraries.
I think the main reason to like shared libraries as a distribution is
that if you upgrade it, you get the upgrade for all programs that depend
on it -- which isn't reall a problem for this.
Regardless curiosity triumphs, the gains aren't as big as I thought: text
going from 231914 to 186776, which is still twice over the multi binary
(75066 in this configuration).
The rest will be C runtime...
(data is slighly lower (~400 bytes), bss slightly bigger (~50 bytes), but
not different enough to matter)
> Sigh. I shouldn't feel that way, and any potential improvement should
> be a source of joy, not dread - but really I wish the results weren't
> so good. Now Pandora's box has been opened and everyone will want to
> use the multicall exclusively, so at some point I'll have to support it,
> i.e. ensure it's actually correct and enhance its maintainability.
> And that means a lot more work. :(
At the risk of repeating myself, I'll be happy to help with anything
related to this -- that's the least I can do given I brought it up.
I understand you probably consider it's faster to do it yourself and
it's your baby, but this is probably orthogonal enough to be worth
delegating a bit. Well, ultimately it's up to you :)
Cheers,
--
Dominique
Received on Wed Feb 01 2023 - 21:25:33 CET