Funny SSL setup. Explanation from here https://news.ycombinator.com/item?id=49133598
> Oh, certain browser will not work with this blog if it cannot negotiate ONLY for Cha-Cha/Poly. It's by design as a showcase of why that particular web browser refuses to do that.
I assume the "particular web browser" is Chromium, which won't load it on any OS I've tried. On Windows, Firefox and the built-in curl.exe also refuse to connect.
Article makes it look like nothing happened in the embed/low-memory/single-threaded malloc space in decades since Doug Lea's malloc.
I just implemented TLSF for my minimal Wasm libc: fragmentation is just as good, performance is a lot more consistent (and on average better), for a significant reduction in code size.
http://www.gii.upv.es/tlsf/index.html
https://github.com/ncruces/wasm2go/blob/main/libc-gen/c/mall...
I do do have a malloc() benchmark but it is in bad shape and directories have not coalesce nicely yet, tor a single run or a menu-driven one.
Certain browsers will suffer. Meh.
FTA: “When multiple threads simultaneously allocate or deallocate memory from the allocator, the allocator will serialize them. Programs making intensive use of the allocator actually slow down as the number of processors increases.”
The article does later retract on that, but that’s no reason to lead with such a blatantly false (with current allocators) statement.
Also FTA “In 2006, a third pool was introduced (after operating system memory pool and library-based memory pool) called the “arena”. Arena is a jemalloc-term”
Jemalloc is from around 2005 (http://jemalloc.net/), the idea of arenas is from the 1960s, and Wikipedia claims the term was coined in 1990 (https://en.wikipedia.org/wiki/Region-based_memory_management...), and the linked paper (https://www.cs.princeton.edu/techreports/1988/191.pdf) is from 1988.
Then, a typo: “as well as memory tied to specific to each of the multiple CPU core or even CPU infinity.”
“Infinity” should be “affinity” there.
I got tired of reading AI prose so I compiled and wrote it from my collections of others' whitepapers.
As a "For Reference Only", at the very least, for me.
As usual, anyone is welcome to improve upon it under CC BY-NC-SA.
allocators are so simple to just swap into your program. if you can put together a few representative workloads, you should just try out a few allocators and profile whatever metrics you care about.
Compilations are hard to get 100% right.
While he was at the university, they were experimenting with different kind of mallocs. One was called the "buddy" malloc. It kept a list of free blocks of various sizes, and when you asked for a block and it didn't have one, it asked the OS for twice as much as you asked for. From the rest, it made another block (identical to yours, called the "buddy" block), and put it on the free list of that size.
Well, they experimented with a similar algorithm, but the idea was that most requests were small. So it took the buddy block and broke it into smaller pieces, one half the size of the request, one a quarter the size, and so on, and put those on their respective free lists. They called this the "donner" malloc, because you carved up your buddy.
From the way my coworker smiled, I think he thought it was amusing, but I don't think he was making it up.