<kayabanerve:matrix.org> @jpk68:matrix.org: Monero as a whole won't work in an environment where `std` isn't available, except some possible negligible platforms. For size benefits, build-std + LTO is your best bet.

<kayabanerve:matrix.org> Fun, I set that years ago to try and fix (cross-?)compiling. If you can enable thin LTO and everything still works, congrats. I would've disabled it re: a CI failing, so if those pass...

<kayabanerve:matrix.org> But don't enable fat LTO

<kayabanerve:matrix.org> Also, std-shims enables no-std platforms to use some std-esque features, but the implementations are generally slower. It shouldn't be preferred when std is available for the size difference.

<kayabanerve:matrix.org> Stripping symbols is likely aggressive without value but codegen-units=1 for release builds makes sense to me

<jpk68:matrix.org> Alright, thanks. I guess I'll try to submit a patch with those, then

<jpk68:matrix.org> I also can't really see people running nodes on ARMv7 :P

<jpk68:matrix.org> Here it is: paste.debian.net/hidden/9eff175d

<jpk68:matrix.org> I can't really submit it on GH right now because my account is cooked; sorry for the inconvenience

<kayabanerve:matrix.org> It was in CI and had a CI failure if that's why I disabled it /shrug > <@jpk68:matrix.org> I also can't really see people running nodes on ARMv7 :P

<kayabanerve:matrix.org> I disagree with strip but those changes shouldn't be a problem if CI passes

<jpk68:matrix.org> Fair point, I just saw that it reduced it by yet another 5 MiB

<kayabanerve:matrix.org> How big is the entire Monero node? Because I'm unsure stripping symbols, which may benefit any back traces if we ever have those, is worth 5 MB unless the entire node is 50 MB or so

<jpk68:matrix.org> I don't know how much the FCMP++ daemon is in total, but at the moment I think it's around 30?

<jpk68:matrix.org> I can check in a moment

<tobtoht> monerod release binary on master is 29MB, beta stressnet v1.1 is 46.6MB

<jpk68:matrix.org> On my machine, the FCMP++ daemon binary is 37.1 MiB without the optimizations, and 33.6 MiB with

<kayabanerve:matrix.org> ... k, then I don't agree with stripping but I agree there's basis to it

<kayabanerve:matrix.org> build-std is nightly but almost stabilized, and honestly everyone should use it for the release profile once stable

<kayabanerve:matrix.org> It will ensure only the necessary parts of std will be compiled, with the profile declared, whereas right now, pre-built blobs are shipped in the toolchain

<kayabanerve:matrix.org> So that should also help

<tobtoht> We use build-std for fcmp++ release builds.

<kayabanerve:matrix.org> A no-std build in order to prefer std-shims is invalid. It's a slower set of alternatives.

<kayabanerve:matrix.org> ... with a nightly compiler or with RUSTC_BOOTSTRAP @tobtoht:monero.social: ?

<tobtoht> RUSTC_BOOSTRAP

<kayabanerve:matrix.org> Like, std-shims doesn't attempt to be correct as std is. It attempts to make moving from std to no-std as simple as possible. It uses spin locks, and HashMaps with predictable RNG (technically, a DoS vector)

<kayabanerve:matrix.org> Oh, great

<jpk68:matrix.org> Considering the fact that this one library increases the binary size by nearly 60%, I think that max optimization is a no-brainer. But that's just me

<jpk68:matrix.org> If both stripping and fat LTO are out of reach... slim pickings

<tobtoht> I can run a release build with LTO and see what happens.

<tobtoht> 46.3MB (without LTO)

<tobtoht> 45.2MB (thin LTO)

<tobtoht> 44.6MB (thin LTO + codegen-units 1)

<tobtoht> 44.6MB (thin LTO + codegen-units 1 + strip = true)

<jpk68:matrix.org> Interesting, my build settings must be weird or something

<jpk68:matrix.org> Fat LTO seems to be substantially more effective, but it looks like that's a no-go

<tobtoht> Fat LTO brings it down to 44.4MB

<jpk68:matrix.org> jberman: I made PRs for the two build system fixes, linked below. Apologies again for not being able to submit on GH.

<jpk68:matrix.org> codeberg.org/jpk68/monero/pulls/18

<jpk68:matrix.org> codeberg.org/jpk68/monero/pulls/19

<kayabanerve:matrix.org> In general, application-wide LTO requires you have a consistent LLVM toolchain which is tricky to enforce and Rust doesn't properly guard about in my experience. That's why I said thin LTO, for most of the benefit with none of the headache.

<kayabanerve:matrix.org> According to tobtoht's numbers, thin LTO and cgu=1 makes sense.

<jpk68:matrix.org> Sounds good. I updated my patch to remove stripping.

<jpk68:matrix.org> Do I need to find someone to mirror it to the Seraphis repo, or can I just leave it here?

<jberman> added to the TODO list: seraphis-migration/monero #377

<jberman> ty

<jpk68:matrix.org> Thanks :)

<koe000:matrix.org> [ RUN ] multisig.sal_single

<koe000:matrix.org> [ OK ] multisig.sal_single (28 ms)

<koe000:matrix.org> [... more lines follow, see mrelay.p2pool.observer/e/h_HsvYILVURwdXJK ]