Old Is Gold: Optimizing Single-Threaded Applications with Exgen-Malloc

16•todsacerdoti•3mo ago

Comments

fanf2•3mo ago

At a quick skim this looks like they reinvented something very similar to phkmalloc, but they didn’t cite phkmalloc nor include it in their benchmarks.

https://phk.freebsd.dk/sagas/phkmalloc/

https://cgit.freebsd.org/src/tree/lib/libc/stdlib/malloc.c?h...

jauntywundrkind•3mo ago

It feels like there's so many weird interesting wins from abandoning SMP CPU coherency. Giving each core its own memory space & own work skips by so many gotchas & contentions.

This is nicely moving down the stack from some other nearby work. ByteDance just released code for Parker, a Linux multi-kernel approach where each core gets its own copy of Linux (and there's one coordinator core). There's another more general multi-kernel on one system approach that also has been quite active recently, that's more general (not strictly 1:1 cores kernel). https://www.phoronix.com/news/Linux-Parker-Proposal https://www.phoronix.com/news/Multi-Kernel-Linux-v2

(Obviously we can and do do lots of single thread per core work already: these emerging multi-kernel ideas are trying to push new territory, new isolation, eliminate yet more contention.)

bcrl•3mo ago

Parker is what Larry McVoy advocated for Linux back during the early days of multiprocessor scaling work. The idea was basically to treat an MP system as a cluster. Everything old is new again!

Personally, I would never agree to give up SMP CPU coherency. Multiprocessor systems are hard enough to debug with hardware cache coherency that adding in entirely new unpredictable non-deterministic behaviour would lead to more developers losing the rest of their hair prematurely. And it would likely introduce an entirely new class of security issues that nobody ever imagined that would require even worse performance draining software workarounds.

Some things are best done in hardware.

vacuity•3mo ago

See also Barrelfish for a multikernel research implementation. I think fos also qualifies.

> Personally, I would never agree to give up SMP CPU coherency. Multiprocessor systems are hard enough to debug with hardware cache coherency that adding in entirely new unpredictable non-deterministic behaviour would lead to more developers losing the rest of their hair prematurely. And it would likely introduce an entirely new class of security issues that nobody ever imagined that would require even worse performance draining software workarounds.

What are you envisioning is the alternative hardware (or is it software?), and why? I assume this is referring to some mechanism for multikernel support that doesn't rely on cache coherence. It seems like there are probably alternatives to full cache coherence that would be neutral, or better, after experience. You didn't provide substantive evidence, but on the other hand, at least multikernels on unmodified hardware seem promising.

gregw2•3mo ago

Larry (SGI) had lived through IRIX fine grained locking and even SGI's NUMA hardware cache coherency based on Stanford research right? Was his take that the complexity wasn't worth it given his experiences at SGI, or that it was just too much for an open source community to tackle without owning the hardware layers?

(And did Maddog (DEC) with a different set of experiences agree?)

vacuity•3mo ago

The trend of multicore and NUMA means that hardware increasingly looks like a traditional network of many separate computers. The natural conclusions of single-core scaled up to, say, 4 cores, shift when there are 8+ cores. Locality becomes crucial; just as you wouldn't split up data-path dependencies across LANs, you shouldn't split them up across NUMA sockets either. Ignoring arguments about locking, message passing, cache management, and whatever, the most pressing argument for multikernels (or at least, far increased per-core state and reduced shared state) is that locality is essential for performance.

layla5alive•3mo ago

Yup, data movement and contention and coherencey are the things that will increasingly dominate power use as core scaling continues. Exploiting locality is a must for high performance systems.

Linux would benefit from a scheduler per CCD (in AMD parlance) approach being a first-class option. CCD pinning is a mechanism to push in this direction today, but partitioning kernel scheduler(s) along hardware boundaries would reduce complexity and overhead for a lot of use cases..

We Mourn Our Craft

Speed up responses with fast mode

Hoot: Scheme on WebAssembly

Stories from 25 Years of Software Development

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

U.S. Jobs Disappear at Fastest January Pace Since Great Recession

Al Lowe on model trains, funny deaths and working with Disney

Brookhaven Lab's RHIC Concludes 25-Year Run with Final Collisions

The AI boom is causing shortages everywhere else

The Waymo World Model

Reinforcement Learning from Human Feedback

Start all of your commands with a comma (2009)

I Write Games in C (yes, C)

SectorC: A C Compiler in 512 bytes

Vocal Guide – belt sing without killing yourself

France's homegrown open source online office suite

Coding agents have replaced every framework I used

A Fresh Look at IBM 3270 Information Display System

Selection Rather Than Prediction

History and Timeline of the Proco Rat Pedal (2021)

72M Points of Interest

Unseen Footage of Atari Battlezone Arcade Cabinet Production

Where did all the starships go?

Show HN: I saw this cool navigation reveal, so I made a simple HTML+CSS version

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Learning from context is harder than we thought

Show HN: Kappal – CLI to Run Docker Compose YML on Kubernetes for Local Dev

Monty: A minimal, secure Python interpreter written in Rust for use by AI

Making geo joins faster with H3 indexes

Software factories and the agentic moment