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

121–130 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#121

Post by taeric »

gz09 wrote: post #20
taeric wrote: post #12

Looks like the main gem here is mimalloc? Love to know more about that. Good places to look?

https://github.com/microsoft/mimalloc we're using it in feldera and it's been giving us (slightly) better performance than jemalloc which is what we've used before mimalloc

Apologies, I did my first post on my phone, so was rather quick. I had found the repository and it is a good read. What I'd love to see is a comprehensive dive on the different options and a good general discussion on when each is superior.

I realize, of course, that this could just be overall optimal. Feels more likely that the allocation patterns of the application using it will impact which is the better allocator?

Re: Make Ubuntu packages 90% faster by rebuilding them

#122

Post by greiskul »

bigstrat2003 wrote: post #102
msm_ wrote: post #69

Earlier quoted context omitted.

ASLR is not security through obscurity though. It forces attacker to get a pointer leak before doing almost anything (even arbitrary read and arbitrary write primitives are useless without a leak with ASLR). As someone with a bit of experience in exploit dev, it makes a world of a difference and is one of the most influential hardenings, next to maybe stack cookies and W^X.

ASLR is by definition security through obscurity. That doesn't make it useless, as there's nothing wrong with using obscurity as one layer of defenses. But that doesn't change what it fundamentally is: obscuring information so that an attacker has to work harder.

Is having a secret password security by obscurity? What about a private key?

Security by obscurity is about the bad practice of thinking that obscuring your mechanisms and implementations of security increases your security. It's about people that think that by using their nephew's own super secret unpublished encryption they will be more secure than by using hardened standard encryption libraries.

Re: Make Ubuntu packages 90% faster by rebuilding them

#123

Post by taeric »

rgmerk wrote: post #111

It's a while since I had to deal with this kind of thing, but my memory was that as soon as you go beyond the flags that the upstream developers use (just to be clear, I mean the upstream developers, not the distro packagers) you're buying yourself weird bugs and a whole lot of indifference if they occur. I haven't used a non-libc malloc before but I suspect the same applies.

I've been building my own emacs for a long time, and have yet to hit any weird bugs. I thought that as long as you avoid any unsafe optimizations, you should be fine? Granted, I also thought that -march=native was the main boost that I was seeing. This post indicates that is not necessarily the case.

I also suspect that any application using floats is more likely to have rough edges?

Re: Make Ubuntu packages 90% faster by rebuilding them

#124

Post by taeric »

rlpb wrote: post #38

Note that if you do this then you will opt out of any security updates not just for jq but also for its regular expression parsing dependency onigurama. For example, there was a security update for onigurama previously; if this sort of thing happens again, you'd be vulnerable, and jq is often used to parse untrusted JSON. > * SECURITY UPDATE: Fix multiple invalid pointer dereference, out-of-bounds write memory corrup…

I'm curious how applicable these are, in general? Feels like pointing out that using interior doors in your house misses out on the security afforded from a vault door. Not wrong, but there is also a reason every door in a bank is not a vault door.

That is, I don't want to devalue the CVE system; but it is also undeniable that there are major differences in impact between findings?

Re: Make Ubuntu packages 90% faster by rebuilding them

#125

Post by MyOutfitIsVague »

loeg wrote: post #114
ac130kz wrote: post #42

-march=native + mimalloc (or jemalloc) should be sufficient without causing significant undefined behavior like -O3 or most extra optimization related compiler arguments.

-O3 doesn't cause undefined behavior.

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.

Re: Make Ubuntu packages 90% faster by rebuilding them

#126

Post by Brian_K_White »

rgmerk wrote: post #111

It's a while since I had to deal with this kind of thing, but my memory was that as soon as you go beyond the flags that the upstream developers use (just to be clear, I mean the upstream developers, not the distro packagers) you're buying yourself weird bugs and a whole lot of indifference if they occur. I haven't used a non-libc malloc before but I suspect the same applies.

Two opposing things are both true at the same time.

If you as an individual avoid being at all different, then you are in the most company and will likely have the most success in the short term.

But it's also true that if we all do that then that leads to monoculture and monoculture is fragile and bad.

It's only because of people building code in different contexts (different platforms, compilers, options, libraries, etc...) that code ever becomes at all robust.

A bug that you mostly don't trigger because your platform or build flags just happens to walk just a hair left of the hole in the ground, was still a bug and the code is still better for discovering and fixing it.

We as individuals all benefit from code being generally robust instead of generally fragile.

Re: Make Ubuntu packages 90% faster by rebuilding them

#127

Post by smallstepforman »

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 malloc again, others constantly release and acquire. How well do they handle fragmentation? What is the uptime (10 seconds or 10 years)? Sometimes the choice of allocators is the difference between long term stability vs short term speed.

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.

As already pointed out, engineering is a compromise.

Re: Make Ubuntu packages 90% faster by rebuilding them

#128

Post by notpushkin »

rgmerk wrote: post #111

It's a while since I had to deal with this kind of thing, but my memory was that as soon as you go beyond the flags that the upstream developers use (just to be clear, I mean the upstream developers, not the distro packagers) you're buying yourself weird bugs and a whole lot of indifference if they occur. I haven't used a non-libc malloc before but I suspect the same applies.

On the other hand, if your optimization helps consistently across platforms, you could convince upstream developers to implement it directly. (Not necessarily across all platforms – a sizable performance gain on just a single arch might still be enough to tweak configuration for that particular build).

Re: Make Ubuntu packages 90% faster by rebuilding them

#129

Post by vlovich123 »

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…

Mimalloc is a general purpose allocator like JEMalloc / TCMalloc. Glibc is known to have a pretty bad allocator that modern allocators like MIMalloc & the latest TCMalloc (not the one available by default in Ubuntu) run laps around. While of course speedup may be variable, generally the benchmarks show an across the board speedup (whether that matters for any given application is something entirely different). As for crashes, these are all general purpose multi-thread allocators and behave no differently from glibc (modulo bugs that can exist equally in glibc).

Re: Make Ubuntu packages 90% faster by rebuilding them

#130

Post by serbuvlad »

eru wrote: post #57
teitoklien wrote: post #40

Gentoo linux is essentially made specifically for people like this, to be able to optimize one’s own linux rig for one’s specific usecase. After initial setup, it’s pretty simple and easy to use, I remember making a ton of friends at matrix’s Gentoo Linux channel, was fun times. https://www.gentoo.org/ Fun fact, initial ChromeOS was basically just custom Gentoo Linux install, I’m not sure if they still use Gentoo Lin…

I used Gentoo for a while, but the temptation to endlessly fiddle with everything always let me to eventually break the system. (It's not Gentoo's fault, it's mine.) Afterwards I moved to ArchLinux, and that has been mostly fine for me. If you are using a fairly standard processor, then Gentoo shouldn't give you that much of an advantage?

I'd like to bring attention to the ALHP repos[1].

These are the Arch packages built for x86-64-v2, x86-64-v3 and x86-64-v4, which are basically names for different sets of x86-64 extensions. Selecting the highest level supported by your processor should get you most of the way to -march=native, without the hassle of compiling it yourself.

It also enables -O3 and LTO for all packages.

[1]: https://github.com/an0nfunc/ALHP

Post reply on HN