> 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.
quietbritishjim 7 hours ago [-]
Firefox on Windows user here, and it loads the blog fine. I don't have Chrome installed but Edge (which is Chromium engine based) doesn't load it.
ncruces 11 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.
A great idea for another article. A focus, on embedded and malloc()
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.
thomasmg 4 hours ago [-]
Interesting! I have also implemented a version of TLSF for my (currently single-threaded) programming language. I also found it to be good for my use case (embedded / minimal code size). I'll compare it against yours. One improvement I did is some kind of preallocation for small blocks.
https://github.com/thomasmueller/bau-lang/blob/main/src/main...
egberts1 8 hours ago [-]
It keeps certain web scrapers and inline transparent proxies/IDS/XNS from fetching, 100%
Certain browsers will suffer. Meh.
11 hours ago [-]
bom-d-van 12 hours ago [-]
legend.
benjojo12 13 hours ago [-]
ERR_SSL_VERSION_OR_CIPHER_MISMATCH on my phone it seems?
Rygian 10 hours ago [-]
TLS_CHACHA20_POLY1305_SHA256 (256 bit keys, TLS 1.3) successfully negotiated here (Firefox esr 140.14.0).
j4k0bfr 12 hours ago [-]
Same, from Chrome on Android
Someone 11 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”
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.
adrian_b 7 hours ago [-]
Yes, I do not know what this paragraph wants to say:
> "The first memory allocation scheme started with a stack-based memory allocation. Next came the dynamic-based memory allocation scheme where linked-list and bucket-heap mechanism are used to divide the private-heap using size class approach. Soon, garbage collection algorithm introduced the initial backend of the memory allocation scheme."
Since no specific operating system is mentioned, these sentences appear to refer to the general history of dynamic memory allocation, in which case they are wrong.
"malloc" is a late comer in this history. It has appeared as the statement "ALLOCATE", together with the statement "FREE", in the programming language PL/I of IBM, by the end of 1964. The C programming language has inherited these 2 functions from IBM PL/I, together with several other features.
At that time (1964-12), many other techniques of managing memory had already been used for a few years.
Dynamic allocation of memory has started during the fifties, with allocation without ever freeing the allocated memory before the termination of the process.
Then, in 1960, 3 methods of handling dynamic memory allocation and implicit freeing were published, which have remained important until today: the use of garbage collectors in April (John McCarthy), the use of stacks in May (E. W. Dijkstra), and the use of reference counts in December (George E. Collins @ IBM).
So the use of garbage collectors is actually the oldest published method for handling dynamic memory allocation, not a newer method, being used in LISP I about 5 years before the first release of PL/I with explicit allocation and freeing (mid 1965).
egberts1 4 hours ago [-]
Thank you for the insightful aspect. This too should be in the lore of memory allocations as well
Will research that, citations and all
adrian_b 2 hours ago [-]
To help you with the citations:
Garbage collectors: "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I", John McCarthy, Communications of the ACM, 1960-04, pp. 184-195 (open access at ACM).
Stacks and stack pointers: "Recursive Programming", Edsger Wybe Dijkstra, 1960-05-11 (available at the Dijkstra Archive).
Reference counts for memory allocation: "A Method for Overlapping and Erasure of Lists", George E. Collins (IBM), Communications of the ACM, Volume 3, Issue 12, 1960-12, pp. 655–657 (open access at ACM).
The first "malloc", i.e. the statements "ALLOCATE" and "FREE" appeared in "NPL Technical Report" at IBM in 1964-12 (available at bitsavers.org).
"NPL" was a provisional name for the new programming language of IBM, which was rebranded as "PL/I" when it was launched officially, a half of year later.
IBM did not document what kind of algorithm was used by their "malloc" implementation, but it already had to handle multi-threaded programs and it was specified that when a new thread was spawned, it could still access any variable that had been dynamically allocated in the parent thread, before the launching of the new thread, but the variables that were allocated in the new thread were private to that thread.
The C "malloc" became compatible with multi-threading only many decades after its ancestor from PL/I.
eqvinox 11 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).
egberts1 8 hours ago [-]
Thank you.
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.
skavi 9 hours 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.
zX41ZdbW 7 hours ago [-]
ClickHouse has been tested with jemalloc, mimalloc, tcmalloc (both variants), rpmalloc, lfalloc, hualloc, and ended up using jemalloc after a few patches and bug fixes.
skavi 6 hours ago [-]
a while back, our tests with a proprietary app led us to tcmalloc (new).
Invariably so but I'm mulling over malloc()s on embedded topic now.
egberts1 8 hours ago [-]
Thank you for the critique.
Compilations are hard to get 100% right.
ligarota 11 hours ago [-]
Please write a "how to setup SSL" article
eqvinox 11 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 9 hours 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.)
0c3ca83 5 hours ago [-]
Beats the hell out of most of the LLM-generated "honest assesments" of things on this site.
dezsiszabi 3 hours ago [-]
I might be stupid, but what's wrong with those sentences?
egberts1 8 hours ago [-]
Yes
egberts1 8 hours ago [-]
No
brcmthrowaway 2 hours ago [-]
What malloc does macOS use in userspace? How about kernel?
AnimalMuppet 7 hours ago [-]
Couldn't read the article (ERR_SSL_VERSION_OR_CIPHER_MISMATCH, Chrome on Windows). But I'm remembering something a coworker told me some time around... 1991 to 1993, maybe? Forgive me if I repeat some of what the article says - I did try to read it!
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.
egberts1 7 hours ago [-]
D. S. Hirschberg, A Class of Dynamic Memory Allocation, CACM 16(10) 1973 covered this variants of halving Buddy Allocator.
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.
> "The first memory allocation scheme started with a stack-based memory allocation. Next came the dynamic-based memory allocation scheme where linked-list and bucket-heap mechanism are used to divide the private-heap using size class approach. Soon, garbage collection algorithm introduced the initial backend of the memory allocation scheme."
Since no specific operating system is mentioned, these sentences appear to refer to the general history of dynamic memory allocation, in which case they are wrong.
"malloc" is a late comer in this history. It has appeared as the statement "ALLOCATE", together with the statement "FREE", in the programming language PL/I of IBM, by the end of 1964. The C programming language has inherited these 2 functions from IBM PL/I, together with several other features.
At that time (1964-12), many other techniques of managing memory had already been used for a few years.
Dynamic allocation of memory has started during the fifties, with allocation without ever freeing the allocated memory before the termination of the process.
Then, in 1960, 3 methods of handling dynamic memory allocation and implicit freeing were published, which have remained important until today: the use of garbage collectors in April (John McCarthy), the use of stacks in May (E. W. Dijkstra), and the use of reference counts in December (George E. Collins @ IBM).
So the use of garbage collectors is actually the oldest published method for handling dynamic memory allocation, not a newer method, being used in LISP I about 5 years before the first release of PL/I with explicit allocation and freeing (mid 1965).
Will research that, citations and all
Garbage collectors: "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I", John McCarthy, Communications of the ACM, 1960-04, pp. 184-195 (open access at ACM).
Stacks and stack pointers: "Recursive Programming", Edsger Wybe Dijkstra, 1960-05-11 (available at the Dijkstra Archive).
Reference counts for memory allocation: "A Method for Overlapping and Erasure of Lists", George E. Collins (IBM), Communications of the ACM, Volume 3, Issue 12, 1960-12, pp. 655–657 (open access at ACM).
The first "malloc", i.e. the statements "ALLOCATE" and "FREE" appeared in "NPL Technical Report" at IBM in 1964-12 (available at bitsavers.org).
"NPL" was a provisional name for the new programming language of IBM, which was rebranded as "PL/I" when it was launched officially, a half of year later.
IBM did not document what kind of algorithm was used by their "malloc" implementation, but it already had to handle multi-threaded programs and it was specified that when a new thread was spawned, it could still access any variable that had been dynamically allocated in the parent thread, before the launching of the new thread, but the variables that were allocated in the new thread were private to that thread.
The C "malloc" became compatible with multi-threading only many decades after its ancestor from PL/I.
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.
https://news.ycombinator.com/item?id=47403847
I am intrigued.
Is there a source for them?
for us, tc was among the fastest in runtime while being very space efficient [0]. large rust application using far too many threads.
we’ve since also had great success with tc’s built in profiling tools.
[0]: https://news.ycombinator.com/item?id=47403847
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.