02:24:08 <br-m> <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.
02:25:12 <br-m> <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...
02:25:52 <br-m> <kayabanerve:matrix.org> But don't enable fat LTO
02:26:34 <br-m> <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.
02:27:23 <br-m> <kayabanerve:matrix.org> Stripping symbols is likely aggressive without value but codegen-units=1 for release builds makes sense to me
02:37:42 <br-m> <jpk68:matrix.org> Alright, thanks. I guess I'll try to submit a patch with those, then
02:37:56 <br-m> <jpk68:matrix.org> I also can't really see people running nodes on ARMv7 :P
02:54:39 <br-m> <jpk68:matrix.org> Here it is: https://paste.debian.net/hidden/9eff175d
02:55:09 <br-m> <jpk68:matrix.org> I can't really submit it on GH right now because my account is cooked; sorry for the inconvenience
12:12:08 <br-m> <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
12:14:06 <br-m> <kayabanerve:matrix.org> I disagree with strip but those changes shouldn't be a problem if CI passes
12:15:15 <br-m> <jpk68:matrix.org> Fair point, I just saw that it reduced it by yet another 5 MiB
13:11:45 <br-m> <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
13:37:36 <br-m> <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?
13:38:07 <br-m> <jpk68:matrix.org> I can check in a moment
14:24:37 <br-m> <tobtoht> monerod release binary on master is 29MB, beta stressnet v1.1 is 46.6MB
14:25:27 <br-m> <jpk68:matrix.org> On my machine, the FCMP++ daemon binary is 37.1 MiB without the optimizations, and 33.6 MiB with
14:26:25 <br-m> <kayabanerve:matrix.org> ... k, then I don't agree with stripping but I agree there's basis to it
14:26:55 <br-m> <kayabanerve:matrix.org> build-std is nightly but almost stabilized, and honestly everyone should use it for the release profile once stable
14:27:25 <br-m> <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 
14:27:37 <br-m> <kayabanerve:matrix.org> So that should also help
14:27:58 <br-m> <tobtoht> We use build-std for fcmp++ release builds.
14:28:01 <br-m> <kayabanerve:matrix.org> A no-std build in order to prefer std-shims is invalid. It's a slower set of alternatives.
14:28:22 <br-m> <kayabanerve:matrix.org> ... with a nightly compiler or with RUSTC_BOOTSTRAP @tobtoht:monero.social: ?
14:28:47 <br-m> <tobtoht> RUSTC_BOOSTRAP
14:29:10 <br-m> <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)
14:29:18 <br-m> <kayabanerve:matrix.org> Oh, great
14:31:16 <br-m> <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
14:32:00 <br-m> <jpk68:matrix.org> If both stripping and fat LTO are out of reach... slim pickings
14:33:32 <br-m> <tobtoht> I can run a release build with LTO and see what happens.
15:18:07 <br-m> <tobtoht> 46.3MB (without LTO)
15:18:07 <br-m> <tobtoht> 45.2MB (thin LTO)
15:18:07 <br-m> <tobtoht> 44.6MB (thin LTO + codegen-units 1)
15:18:07 <br-m> <tobtoht> 44.6MB (thin LTO + codegen-units 1 + strip = true)
15:19:23 <br-m> <jpk68:matrix.org> Interesting, my build settings must be weird or something
15:20:02 <br-m> <jpk68:matrix.org> Fat LTO seems to be substantially more effective, but it looks like that's a no-go
15:26:16 <br-m> <tobtoht> Fat LTO brings it down to 44.4MB
16:15:22 <br-m> <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.
16:15:27 <br-m> <jpk68:matrix.org> https://codeberg.org/jpk68/monero/pulls/18
16:15:27 <br-m> <jpk68:matrix.org> https://codeberg.org/jpk68/monero/pulls/19
19:01:54 <br-m> <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.
19:02:41 <br-m> <kayabanerve:matrix.org> According to tobtoht's numbers, thin LTO and cgu=1 makes sense.
19:39:48 <br-m> <jpk68:matrix.org> Sounds good. I updated my patch to remove stripping.
19:40:10 <br-m> <jpk68:matrix.org> Do I need to find someone to mirror it to the Seraphis repo, or can I just leave it here?
20:49:31 <br-m> <jberman> added to the TODO list: https://github.com/seraphis-migration/monero/issues/377
20:49:40 <br-m> <jberman> ty
20:50:00 <br-m> <jpk68:matrix.org> Thanks :)
22:08:24 <br-m> <koe000:matrix.org> [ RUN      ] multisig.sal_single
22:08:24 <br-m> <koe000:matrix.org> [       OK ] multisig.sal_single (28 ms)
22:08:24 <br-m> <koe000:matrix.org> [... more lines follow, see https://mrelay.p2pool.observer/e/h_HsvYILVURwdXJK ]