Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make Ubuntu packages 90% faster by rebuilding them

gist.github.com

Post reply on HN
Print view View original

211–220 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#211

Post by chasil »

Aachen wrote: post #207

Reading that such a simple change can get such a big speedup, my first thought is to let the authors of jq know. Maybe there's a caveat to be aware of, maybe they'll test it and end up making it faster for everyone. Useful to drop a quick note pretty much no matter the result, I think? The article doesn't seem to even consider that option and I don't see any comment here mentioning this either. Am I missing something…

I would be curious if Intel Clear Linux had similar gains, by using newer opcodes in the instruction set.

I wonder if the glibc allocator is standard there.

https://en.m.wikipedia.org/wiki/Clear_Linux_OS

Re: Make Ubuntu packages 90% faster by rebuilding them

#212

Post by scns »

Y_Y wrote: post #202
vlovich123 wrote: post #144

Earlier quoted context omitted.

Looked at your updated post and it looks like you’re operating under wildly incorrect assumptions. 1. Fragmentation: MIMalloc and the newest TCMalloc definitely handle this better than glibc. This is well established in many many many benchmarks. 2. In terms of process lifetime, MIMalloc (Microsoft Cloud) and TCMalloc (Google Cloud) are designed to be run for massive long-lived services that continually allocate/deal…

Challenge yourself to produce some numbers first. If there are many many many benchmarks it shouldn't be too difficult to link one. Just saying something is "well established" doesn't really help without some other context.

https://github.com/microsoft/mimalloc?tab=readme-ov-file#per...

Re: Make Ubuntu packages 90% faster by rebuilding them

#213

Post by 1dom »

smallstepforman wrote: post #127

Engineering is a compromise. The article shows most gains come from specialising the memory allocater. The thing to remember is that some projects are multithreaded, and allocate in one thread, use data in another and maybe deallocate in a 3rd. The allocator needs to handle this. So a speedup for one project may be a crash in another. Also, what about reallocation strategy? Some programs preallocate and never touch m…

Sorry, I'm struggling to make sense of this comment. I don't know C or C compilers very well at all, but I read the full gist and felt I learned a bunch of stuff and got a lot of value from it.

But then when I read this top comment, it makes me concerned I've completely misunderstood the article. From the tone of this comment, I assume that I shouldn't ever do what's talked about in this gist and it's a terrible suggestion that overlooks all these complexities that you understand and have referenced with rhetorical-looking questions.

Any chance you could help me understand if the original gist is good, makes any legitimate points, or has any value at all? Because I thought it did until I saw this was the top comment, and it made me realise I'm not smart enough to be able to tell. You sound like you're smart enough to tell, and you're telling me only bad things.

Re: Make Ubuntu packages 90% faster by rebuilding them

#214

Post by citrin_ru »

cyounkins wrote: post #165

Why is glibc malloc() not more performant? Are tcmalloc/mimalloc making tradeoffs that maintainers are unwilling to make in glibc?

AFAIK ptmalloc (on which glibc is based) was created decades ago and both multi-threaded application and multi CPU systems where rare back then (at least in the Linux world) so multi-threaded performance didn't matter. Some improvement in glibc were made since then but I don't think it's possible to significantly improve glibc malloc without rewriting it more or less fully. At that point it would make more sense to import some existing malloc implementation.

And we are speaking about trafeoff the default number of arenas in glibc malloc is 8 times CPU which is a terrible tradeoff - on many workloads it cause heap fragmentation and memory usage (RSS) many times higher than allocated memory size, that's why it is common to find advice to set MALLOC_ARENA_MAX to 1 or 2. But probably such high number of areans allows glib to look less bad on synthetic benchmakrs.

Jemalloc, tcmalloc, mimalloc all were created with focus on multi-threaded applications from the beginning and while they don't work better than glibc malloc for single threaded application they don't work worse for this use case either. Probably the main disadvantage of using je/tc/mi mallocs for a single threaded app is large code size.

Re: Make Ubuntu packages 90% faster by rebuilding them

#215

Post by roeles »

rurban wrote: post #190

He is still missing profile guided optimizations (with his testcase), and bolt. And in some/most cases -Os is faster than -O3 Boehm GC is usually slower than glibc with lots of allocs. MPS would be better, but needs lots of rewriting. https://github.com/Ravenbrook/mps

> And in some/most cases -Os is faster than -O3 This surprises me. Can you please elaborate?

Re: Make Ubuntu packages 90% faster by rebuilding them

#216

Post by chasil »

pests wrote: post #112
dan-robertson wrote: post #34

Earlier quoted context omitted.

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…

The -Os flag optimizes for size.

What impact does that have?

Re: Make Ubuntu packages 90% faster by rebuilding them

#217

Post by wengo314 »

"Make one Ubuntu package 90% faster by rebuilding it and switching the memory allocator"

i wish i could slap people in the face over standard tcp/ip for clickbait. it was ONE package and some gains were not realized by recompilation.

i have to give it to him, i have preloaded jemalloc to one program to swap malloc implementation and results have been very pleasant. not in terms of performance (did not measure) but in stabilizing said application's memory usage. it actually fixed a problem that appeared to be a memory leak, but probably wasn't fault of the app itself (likely memory fragmentation with standard malloc)

Re: Make Ubuntu packages 90% faster by rebuilding them

#219

Post by Vilkku »

toyg wrote: post #198
vasco wrote: post #166

Earlier quoted context omitted.

Never seen the HN version of the 'install gentoo' meme before, more sophisticated definitely. > The goal of Gentoo is to have an operating system that builds all programs from source, instead of having pre-built binary packages. While this does allow for advanced speed and customizability, it means that even the most basic components such as the kernel must be compiled from source. It is known through out the Linux c…

Where does that blurb come from, chatgpt? I don't think it's true anymore, last time I checked I think Gentoo had a "normal" liveCD installation for the base system, which you could then recompile on your own if wanted.

Seems to be from https://knowyourmeme.com/memes/install-gentoo

Re: Make Ubuntu packages 90% faster by rebuilding them

#220

Post by narmiouh »

Daneel_ wrote: post #96
tom_ wrote: post #83

Earlier quoted context omitted.

Related: https://randomascii.wordpress.com/2018/02/04/what-we-talk-ab...

Great read. I hadn't even considered that people might interpret "90% faster" as "10 times as fast", i.e., it will take 100-90=10% of the original time. It seems like a completely incorrect interpretation to me, but obviously there are people who read it with this understanding. Huh.

It is unfortunate (because how do you interpret 100% faster) but a common interpretation of X% faster implies it takes x% less time than before. One easy way is to have chatgpt give a numeric example for a statement like this, and in all cases I tried it gives an example of sorts if the job took 100 seconds before it takes 10 seconds now (a 10x increase), and I'm assuming it is a representation of common usage based on how much data is used to train it.
Post reply on HN