I find this site interesting because of its mixture of good topic choice and inaccurate details. I think it's generated by LLMs.
Specifically catching my eye in this collection of articles is the highly misleading one about huge pages. All recent Linux distributions have THP set to "madvise" by default. Many programs exploit THP automatically, including any Go program and any JVM program with a flag set. The tcmalloc shared library that comes with Ubuntu is probably the single worst way to experience huge pages. Mi-malloc is the better choice if you must preload a library, but there are even better choices. Explicit huge pages are little-used because managing them is annoying. Finally, latest Linux kernels have features called "folios"and "mTHP" that make THP even smoother.
The huge page article is sequitur with official documentation like https://docs.redhat.com/en/documentation/red_hat_enterprise_.... THP can only issue up to 2MB pages on amd64 so it's not necessarily a silver bullet for large persistent consumers like a DB or GC language and worth knowing about the older methods.
To me they look like marketing posts, but they aren't void of effort or meaning as a quick intro to various topics.
Linking the allocator into your program when you build it, instead of overriding just malloc and free at runtime. Then you can choose between jemalloc, mi-malloc, TCMalloc, or whatever you please, and get better features such as C++ sized delete. Rust makes this easy with for example "use tcmalloc_better::TCMalloc".
I find this site interesting because of its mixture of good topic choice and inaccurate details. I think it's generated by LLMs.
Specifically catching my eye in this collection of articles is the highly misleading one about huge pages. All recent Linux distributions have THP set to "madvise" by default. Many programs exploit THP automatically, including any Go program and any JVM program with a flag set. The tcmalloc shared library that comes with Ubuntu is probably the single worst way to experience huge pages. Mi-malloc is the better choice if you must preload a library, but there are even better choices. Explicit huge pages are little-used because managing them is annoying. Finally, latest Linux kernels have features called "folios"and "mTHP" that make THP even smoother.
The huge page article is sequitur with official documentation like https://docs.redhat.com/en/documentation/red_hat_enterprise_.... THP can only issue up to 2MB pages on amd64 so it's not necessarily a silver bullet for large persistent consumers like a DB or GC language and worth knowing about the older methods.
To me they look like marketing posts, but they aren't void of effort or meaning as a quick intro to various topics.
> Mi-malloc is the better choice if you must preload a library, but there are even better choices.
What’s a better choice?
Linking the allocator into your program when you build it, instead of overriding just malloc and free at runtime. Then you can choose between jemalloc, mi-malloc, TCMalloc, or whatever you please, and get better features such as C++ sized delete. Rust makes this easy with for example "use tcmalloc_better::TCMalloc".