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

301–310 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#301

Post by jeffbee »

vlovich123 wrote: post #300
jeffbee wrote: post #283

Earlier quoted context omitted.

Oddly enough I've written about those results before: https://www.dropbox.com/scl/fi/evnn6yoornh9p6l7nq1t9/Irrepro...

but we all can agree that glibc is trash right? :) I’d be careful extrapolating from just one benchmark but generally if I had to choose I’d pick the new tcmalloc if I could. It seems to be a higher quality codebase.

The problem with the current tcmalloc, which I agree is very good, is the difficulty of integrating it with random builds. It works well for large systems and especially those that are already bazelized, but I couldn't whip up a quick way to link it to `jq` in this gist.

Re: Make Ubuntu packages 90% faster by rebuilding them

#302

Post by jeffbee »

scottlamb wrote: post #278
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…

> I experimented with different allocators devoloping a video editor testing 4K videos that caches frames. 32Mb per frame, at 60fps, thats almost 2Gb per second per track. You quickly hit allocator limitations, and realise that at least vanilla glibc allocator offers the best long term stability. But for short running benchmarks its the slowest. I also work with large (8K) video frames [1]. If you're talking about th…

Buffers of that size are also in tcmalloc's "whatever" class, right? It just does a smarter[1] job of not unmapping them.

1: for a certain point of view

Re: Make Ubuntu packages 90% faster by rebuilding them

#303

Post by throw16180339 »

loeg wrote: post #113
kstrauser wrote: post #5

(Well, rebuilding them with a different allocator that benchmarks well on their specific workflow.)

Everything outperforms glibc malloc. It's essentially malpractice that distros continue to use it instead of mimalloc or jemalloc.

It's been awhile since I looked into this, but it's not necessarily an easy change. glibc malloc has debugging APIs; a distro can't easily replace it without either emulating the API or patching programs that use it.

Re: Make Ubuntu packages 90% faster by rebuilding them

#304

Post by [deleted] »

kllrnohj wrote: post #275
vlovich123 wrote: post #231

Earlier quoted context omitted.

If you are not properly overriding the allocator consistently for everything within an executable, that’s entirely possible (eg linking against 1 allocator and then linking with a dynamic library that’s using a different one). Without a specific repro it’s hard to distinguish PEBCAK from legit bug. Also it certainly can’t be the Nvidia driver since that’s not running anything in your process.

> Also it certainly can’t be the Nvidia driver since that’s not running anything in your process. A huge chunk of a modern GPU driver is part of the calling process, loaded like a regular library. Just spot checking Chrome's GPU thread, there's dozens of threads created by a single 80+mb nvidia DLL. And this isn't unusual, every GPU driver has massive libraries loaded into the app using the GPU - often including enti…

[deleted]

Re: Make Ubuntu packages 90% faster by rebuilding them

#305

Post by vlovich123 »

akoboldfrying wrote: post #259
akoboldfrying wrote: post #252

Earlier quoted context omitted.

> If there’s insufficient space it’ll get more virtual memory from the OS. Swap space is finite too. > Also, nothing you’ve said actually says that the other allocator will be the worse one. I'm not claiming that either is worse. I'm showing mathematically that for any two allocators that behave differently at all (with the one tiny exception of a pair of allocators that are perfect mirror images of each other), it's…

I should have been more explicit about the assumptions I make about an allocator: 1. If malloc() is called when there exists a contiguous block of free memory with size >= the argument to malloc(), the call will succeed. I think you'll agree that this is reasonable. 2. Bookkeeping (needed at least for tracking the free list, plus any indexes on top) uses the same amount of malloc()able memory in each allocator. I.e.,…

Swapping out allocators won't cause some programs to crash and others to not crash unless your program is already using up all available RAM or your program has a bug and the allocation pattern happens to be more likely to trigger invalid memory access in a way that crashes.

This allocation pattern idea is unlikely to show up in any real application except at the absolute limit where your exhausting RAM and the OOM killer gets involved. Even then I think you're going to not see the allocator be much of a differentiating factor.

Re: Make Ubuntu packages 90% faster by rebuilding them

#307

Post by MyOutfitIsVague »

vlovich123 wrote: post #141
MyOutfitIsVague wrote: post #125

Earlier quoted context omitted.

No, but it can often expose undefined behavior that doesn't stop a program from "working" on lower optimization levels. Which is why I'm in support of always building your own software with -O3.

Are you sure about that? I’m not aware of any additional UB exploitation enabled by O3 vs O2 or Os.

Nope, I'm not sure about it. I remember when I was using Gentoo about 10 years ago, this was the common reason given for using -O2 instead of -O3 in your build flags, and I'm just speaking from that memory.

Re: Make Ubuntu packages 90% faster by rebuilding them

#309

Post by rajaravivarma_r »

It is funny, how being a corporate-Rails programmer taught me this early in my career. Because building Ruby from source was the only way you could install latest Ruby versions (using ruby-build) and installing Ruby from source means its dependencies like openssl, zlib had to be installed from source too, to match the required versions.

And for a long time using Jemalloc was the only was to keep the memory usage constant with multi-threaded ruby programs like Puma and Sidekiq. This was either achieved through compiling Ruby with jemalloc or modifying the LD_LIBRARY_PATH.

Some developers also reported 5% or so reduction in response times with jemalloc, iirc.

The problem with this approach is though, when a package has a lot of dependencies like ImageMagick which relies on jpeg, png, ghost and a lot of other libraries, you have to take a trial and error approach until it succeeds. Fortunately fixing the dependency errors are the easiest, sometimes building Python from source would throw errors from headers which are impossible to understand. If you find a Stackoverflow solution then you are good, or you have to go down the rabbit hole coming either successful or empty handed based on your level of expertise.

Re: Make Ubuntu packages 90% faster by rebuilding them

#310

Post by scottlamb »

hedora wrote: post #297
scottlamb wrote: post #278

Earlier quoted context omitted.

> I experimented with different allocators devoloping a video editor testing 4K videos that caches frames. 32Mb per frame, at 60fps, thats almost 2Gb per second per track. You quickly hit allocator limitations, and realise that at least vanilla glibc allocator offers the best long term stability. But for short running benchmarks its the slowest. I also work with large (8K) video frames [1]. If you're talking about th…

I’d be shocked if jemalloc or tcmalloc had issues with that workload. Do you have a minimal reproducing example?

Sure, in plain C because why not. https://gist.github.com/scottlamb/459a3ce6230be67bf4ceb1f1a8...>

There's one other element I didn't mention in my previous comment, which is a thread handoff. It may be significant because it trashes any thread-specific arena and/or because it introduces a little bit of variability over a single malloc at a time.

For whatever reason the absolute rate on my test machine is much higher than in my actual program (my actual program does other things with a more complex threading setup, has multiple video streams, etc.) but you can see the same effect of hitting the mmap, munmap, and page fault paths that really need not ever be exercised after program start.

In my actual (Rust-based) program, adding like 20 lines of code for the pooling was a totally satisfactory solution and took me less time than switching general-purpose allocator, so I didn't try others. (Also, my program supports aarch64 and iirc the vendored jemalloc in the tikv-jemallocator crate doesn't compile cleanly there.)

Post reply on HN