NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
Comparison of Malloc() Algorithms (egbert.net)
Nnnes 4 hours ago [-]
https://web.archive.org/web/20260915165314/https://egbert.ne...

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.

ncruces 2 hours ago [-]
Thanks for the link.

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...

2 hours ago [-]
bom-d-van 3 hours ago [-]
legend.
benjojo12 4 hours ago [-]
ERR_SSL_VERSION_OR_CIPHER_MISMATCH on my phone it seems?
Rygian 1 hours ago [-]
TLS_CHACHA20_POLY1305_SHA256 (256 bit keys, TLS 1.3) successfully negotiated here (Firefox esr 140.14.0).
j4k0bfr 3 hours ago [-]
Same, from Chrome on Android
ligarota 3 hours ago [-]
Please write a "how to setup SSL" article
eqvinox 2 hours ago [-]
It seems to be intentional & if somebody wants to make a statement about TLS with their personal website that's their choice to make and execute.
entrope 16 minutes ago [-]
On the bright side, lots of people will be saved from reading bad prose like "Malloc (libc) is the worst memory allocation API to use" and "Programs should avoid, if possible, allocating/deallocating memory too often". (By definition, "too often" means it can possibly be avoided, and usually that it can practically be avoided.)
Someone 2 hours ago [-]
Not a good article, IMO.

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.

skavi 13 minutes ago [-]
yup and the characterization of each allocator is so fuzzy, with zero methodology provided.

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.

eqvinox 2 hours ago [-]
The tables look mostly correct, and that's what I'll be bookmarking this for… I don't think I've seen any elsewhere that are this extensive (in both axis, total allocators covered & details per allocator).
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 10:52:04 GMT+0000 (Coordinated Universal Time) with Vercel.