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

Meta’s renewed commitment to jemalloc

engineering.fb.com

Post reply on HN
Print view View original

201–210 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#201

Post by torginus »

rwaksmunski wrote: post #184
openclaw01 wrote: post #179

[dead]

jemalloc 5.2.1 vs mimalloc v3.2.8 in Rust software processing hundreds of Terabytes. Could not measure a meaningful difference, but mimalloc would release freed memory to the OS a lot sooner and therefore look nicer in top. That said, older mimalloc from default rust crate would cause memory corruption with large allocations >2Gb in about 5% of the cases. Stuck with battle hardened jemalloc for now.

Mimalloc my beloved. The fact that jemalloc is this fiendishly complex allocator with a gazillion algorithms and approaches ( and a huge binary), yet mimalloc (a simple allocator with one bitmap-tracked pool per allocation size, and one pool collection per thread) is one of the bigger wins in software simplicity in recent memory.

Re: Meta’s renewed commitment to jemalloc

#202

Post by lukeh »

apatheticonion wrote: post #117

As an Australian who was just made redundant from a role that involved this type of low level programming - I love working on these these kinds of challenges. I'm saddened that the job market in Australia is largely React CRUD applications and that it's unlikely I will find a role that lets me leverage my niche skill set (which is also my hobby)

I hear you. Actually I read this thread because we’re using jemalloc in an embedded product. The only way I found to work on interesting problems here was to work for myself. (Having said that I think Apple might have some security research in Canberra? Years ago there was LinuxCare there and a lot of smart people. But that was in 2003…)

Re: Meta’s renewed commitment to jemalloc

#204

Post by mywacaday »

The only option for cookies is to accept these terms and conditions, I thought implied consent was explicitly not allowed due to GDPR?

"To help personalize content, tailor and measure ads and provide a safer experience, we use cookies. By clicking or navigating the site, you agree to allow our collection of information on and off Facebook through cookies. Learn more, including about available controls:

https://engineering.fb.com/privacy"

Re: Meta’s renewed commitment to jemalloc

#205

Post by vesselapi »

bmenrigh wrote: post #8

I recently started using Microsoft's mimalloc (via an LD_PRELOAD) to better use huge (1 GB) pages in a memory intensive program. The performance gains are significant (around 20%). It feels rather strange using an open source MS library for performance on my Linux system. There needs to be more competition in the malloc space. Between various huge page sizes and transparent huge pages, there are a lot of gains to be…

[dead]

Re: Meta’s renewed commitment to jemalloc

#206

Post by tosti »

bmenrigh wrote: post #37
jeffbee wrote: post #27

Earlier quoted context omitted.

Just out of curiosity are you getting 1GB huge pages on Xeon or some other platform? I always thought this class of page is the hardest to exploit, considering that the machine only has, if I recall correctly, one TLB slot for those.

Modern x86_64 has supported multiple page sizes for a long time. I'm on commodity Zen 5 hardware (9900X) with 128 GiB of RAM. Linux will still use a base page size of 4kb but also supports both 2 MiB and 1 GiB huge pages. You can pass something like `default_hugepagesz=2M hugepagesz=1G hugepages=16` to your kernel on boot to use 2 MiB pages but reserve 16 1 GiB pages for later use. The nice thing about mimalloc is th…

    > commodity
    > zen 5
    > 128GiB
Are you from the future?

Re: Meta’s renewed commitment to jemalloc

#207

Post by specialist »

hedayet wrote: post #189
genxy wrote: post #180

Earlier quoted context omitted.

That is, wow, a story. At what point did you realize how different fb engineering was from what you expected?

For me it happened around my first week after the bootcamp, so about 6 weeks from joining. An important nuance - most Facebook engineers don't believe that Facebook/Meta would continue to grow next year; and that disbelief had been there since as early as in 2018 (when I'd joined). very few facebook employees use their products outside of testing, which is a big contributor to that fear - they just can't believe that…

> don't believe that Facebook/Meta would continue to grow next year

Huh.

The time I worked at a hyper growth company, us working in the coal mine had much the same skepticism. Our growth rate seemed ridiculous, surely we're over building, how much longer can this last?!

Happily, the marketing research team regularly presented stuff to our department. They explained who are customers were, projected market sizes (regionally, internationally), projected growth rates, competitive analysis (incumbents and upstarts), etc.

It helped so much. And although their forecasts seemed unbelievable, we over performed every year-over-year. Such that you sort of start to trust the (serious) marketing research types.

Re: Meta’s renewed commitment to jemalloc

#209

Post by skavi »

hedora wrote: post #54
skavi wrote: post #47

Earlier quoted context omitted.

We evaluated a few allocators for some of our Linux apps and found (modern) tcmalloc to consistently win in time and space. Our applications are primarily written in Rust and the allocators were linked in statically (except for glibc). Unfortunately I didn't capture much context on the allocation patterns. I think in general the apps allocate and deallocate at a higher rate than most Rust apps (or more than I'd like…

I’m surprised (unless they replaced the core tcmalloc algorithm but kept the name). tcmalloc (thread caching malloc) assumes memory allocations have good thread locality. This is often a double win (less false sharing of cache lines, and most allocations hit thread-local data structures in the allocator). Multithreaded async systems destroy that locality, so it constantly has to run through the exception case: A allo…

also:

1. tcmalloc is actually the only allocator I tested which was not using thread local caches. even glibc malloc has tcache.

2. async executors typically shouldn’t have tasks jumping willy nilly between threads. i see the issue u describe more often with the use of thread pools (like rayon or tokio’s spawn_blocking). i’d argue that the use of thread pools isn’t necessarily an inherent feature of async executors. certainly tokio relies on its threadpool for fs operations, but io-uring (for example) makes that mostly unnecessary.

Re: Meta’s renewed commitment to jemalloc

#210

Post by kbolino »

adgjlsfhk1 wrote: post #156
NooneAtAll3 wrote: post #44

Earlier quoted context omitted.

doesn't java also? I heard that was a common complaint for minecraft

Minecraft for somewhat silly reasons was largely stuck using Java8 for ~a decade longer than it should have which meant that it was using some fairly outdated GC algorithms.

So much software was stuck on Java 8 and for so long that some of the better GC algorithms got backported to it.
Post reply on HN