14:28 <r0ni> my night of testing the rpi5 left me amazed with it. It runs much better than my last one (rpi3) and is light years better than my pbp. I can't wait to try crux when I've got some compilation time to do so on it!

15:00 <jaeger> Good to hear

17:19 <pitillo> jaeger: what about building a rootfs for the rpi5 on the M1 on the meanwhile? :D

17:23 <pitillo> s/on/in

17:34 <jaeger> I can certainly take a look, sure

17:52 <pitillo> great

19:07 <crux-arm-bot> [ crux-ports-xorg-arm ]: mesa: update to 23.3.0

19:32 <crux-arm-bot> [ crux-ports-opt-arm ]: nss: update to 3.96.1

20:11 <jaeger> I wonder if -ftree-vectorize and -fomit-frame-pointer are as useful on the pi5, should I keep those in CFLAGS?

20:17 <jaeger> Also I've seen some docs for arm/arm64 recommending avoidance of -march= entirely, though I haven't really looked into that much

20:19 <jaeger> Thinking about it I guess the idea is portability which isn't needed in this case, so using -march= might be preferable

20:39 <ukky> jaeger: Removing -march= only matters when you need to reuse your binaries on other CPU flavors. You can keep -march= if you build package for specific system

20:47 <ukky> Adding -fomit-frame-pointer saves some CPU cycles, but I don't think it boosts performance substantially. On the other hand, you will lose stack backtrace

21:23 <jaeger> https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu is an interesting read for me

21:24 <jaeger> They recommend avoiding -mtune or -march but since I'm only building for a single board (rpi5) I think it matters less

23:23 <jaeger> Based on that and comments here, etc., I think going with "-mcpu=cortex-a76+crc+crypto -mtune=cortex-a76 -O2 -pipe" makes sense

23:23 <jaeger> And -mtune may only be needed for specific libs that break like libvpx