Hacker News Reader

Comment by taeric | Hacker News Reader

Sorry, I didn't mean symbols, I meant optimization level. Hilarious that they have symbols stripped, but still outclassed.

Love to see why they wouldn't have more optimizations.

I'm assuming this isn't the case for more packages? Feels too good.

View on HN

Ubuntu is still building for CPUs with the x86-64-v1 feature set. On experimental images built for x86-64-v3 (roughly the feature set of 10 year old CPUs, a bit newer on low-power CPUs) they have observed 60% improvement on some benchmarks (and much less in some others). Some distros have switched to -v3, Ubuntu is still holding out to support older hardware. The author is compiling to the actual feature set of their specific CPU, which is nearly guaranteed to be even more than -v3.

Another thing the article adds is LTO, which in my experience also makes a huge difference: it makes your software a lot faster in certain cases, but also makes build times a lot worse. Spending a bit more time in the build process should be an easy call, but might be harder at the scale of a distro.

I was under the, evidently naive, understanding that there were some shenanigans done in the libc to pick optimal code paths based on the architecture. This would obviously have a startup cost on the first run, but presumably the dynamic linking would work to this advantage by having it in a fast state for most calls?

Not sure where I got that idea, though. :(. Will have to look into that later.

Even if libc does it, other packages wouldn’t. The compiler is what generates code and they generally don’t try to automatically generate for different instruction sets because they don’t know what code is what hotpath and worth optimizing for. You could probably try to build for multiple different CPU features at the top level and do a universal executable like Apple did for their CPU transitions but that’s a lot of expense to pay both in terms of compilation time AND in terms of size.

Debug symbols do not need to be paged in so shouldn’t make much/any difference. Compiling with -O3 can increase code size a lot due to inlining, which can be a little bad.

Mario 64 gets flak for some files not being compiled with optimizations on. There is a YouTuber, whose name I forget at the moment, who has been doing optimization and improvements on it and constantly talks about how this is for the better due to the low instruction cache size and slow speed on the console. Compiling with optimizations explodes code size (unrolling links, inlining, etc) to the point it’s a net loss after factoring in the increased load on the IC.

The -Os flag optimizes for size.

What impact does that have?

The IC is the instruction cache. Bloated code needs more slow loads from the IC, and even if the performance is faster per cache line, the 50x overhead of added cache loads diminishes all -O3 advantages.

Kaze Emanuar[0] is the YouTuber you're thinking of.

[0] https://www.youtube.com/@KazeN64

Yes thank you!

Right, my humor there was that I'm assuming people specifically did non-debug flags for the build as an optimization. Only for them to still fall short.

And understood a little on -O3 possibly increasing code size. I had thought that was more of a concern for tight environments than for most systems? Of course, I'd have assumed that -march=native would be more impactful, but the post indicates otherwise.

I said in a top level, but it seems the allocator makes the biggest impact for this application? Would be interesting to see which applications should use different allocators. Would be amazing to see a system where the more likely optimal allocator was default for different applications, based on their typical allocation patterns.

> Right, my humor there was that I'm assuming people specifically did non-debug flags for the build as an optimization.

It used to be the case that the presence of debug symbols would affect GCC code generation. Nowadays that should be fixed. I think it still affects the speed of compilation so if you're building the whole system from source you might want to avoid it.

> And understood a little on -O3 possibly increasing code size. I had thought that was more of a concern for tight environments than for most systems?

Increasing code size too much can result in hot functions not fitting in the icache, and that ultimately can make your program slower.

> Hilarious that they have symbols stripped, but still outclassed.

Debug symbols have 0 runtime penalty, just storage. They're just another section of the binary, referenced by debuggers, and which the loader skips.

In any case, all distros break out the symbols into separate files so that they can have their (storage) cake and (debug) eat it too.

Right, I meant the humor to be that folks to not use debug flags, with my naive presumption that they did this as an optimization, only for that not to really help.

Reply on news.ycombinator.com