A single-file C allocator with explicit heaps and tuning knobs • Hacker News Board

Re: A single-file C allocator with explicit heaps and tuning knobs

#21

Post by mzajc » Sat, Mar 28, 2026, 3:12 PM UTC

ntoslinux wrote: post #8

What is the reason for the weird `{ code };` blocks everywhere and is the below code machine generated? ```c ((PageSize) (chunk->pageSize - ((PageSize) ((PageSize) ((PageSize) (sizeof(Page) + (sizeof(struct _Block))) + (PageSize) ((sizeof(double)) - 1u)) & ((PageSize) (~((PageSize) ((sizeof(double)) - 1u)))))) - ((PageSize) ((PageSize) ((PageSize) ((sizeof(FreeBlock) + sizeof(PageSize))) + (PageSize) (((((sizeof(doub…

Worse yet, there's several places with empty code blocks, eg. [0] and [1]. Even without that, the formatting contains so much unnecessary whitespace, newlines, casts, etc; I'm not sure why, given the already massive source file. How do you even fit [2] on a screen?

[0]: https://github.com/xtellect/spaces/blob/422dbba85b5a7e9a209a...

[1]: https://github.com/xtellect/spaces/blob/422dbba85b5a7e9a209a...

[2]: https://github.com/xtellect/spaces/blob/422dbba85b5a7e9a209a...

Re: A single-file C allocator with explicit heaps and tuning knobs

#22

Post by jeffbee » Sat, Mar 28, 2026, 3:57 PM UTC

"That costs ~5 ns when the line is cold"

I don't see how that could possibly be true. Sounds like a low-ball estimate.

Also i wish to point out that the "tcmalloc" being used as a baseline in these performance claims is Ye Olde tcmalloc, the abandoned and now community-maintained version of the project. The current version of tcmalloc is a completely different thing that the mimalloc-bench project doesn't support (correctly; I just checked).

Re: A single-file C allocator with explicit heaps and tuning knobs

#23

Post by lstodd » Sat, Mar 28, 2026, 4:18 PM UTC

Zig got this right to such a degree that I'm sometimes tempted to export its allocators to C via FFI. Then I sober up a bit and just rewrite it all in zig, all its instability nonwithstanding.

Re: A single-file C allocator with explicit heaps and tuning knobs

#24

Post by dnautics » Sat, Mar 28, 2026, 4:25 PM UTC

lstodd wrote: post #23

Zig got this right to such a degree that I'm sometimes tempted to export its allocators to C via FFI. Then I sober up a bit and just rewrite it all in zig, all its instability nonwithstanding.

Not only that, since there is a super-standard std allocator api, it makes itself very amenable to memory safety analysis, as long as you don't sneakily implement allocations outside of that api.

https://github.com/ityonemo/clr

Re: A single-file C allocator with explicit heaps and tuning knobs

#25

Post by convolvatron » Sat, Mar 28, 2026, 4:46 PM UTC

throwaway27448 wrote: post #20

bitbasher wrote: post #18

Earlier quoted context omitted.

Yes and no. Have you looked at the code? It was clearly generated in one form or another (see the other comments). The author created a new GitHub account and this is their first repository. It looks to be generated from another code base as a sorta amalgamation (either through code generation, ai, or another means). We're supposed to implicitly trust this person (new GitHub account, first repository, no commit histo…

> We're supposed to implicitly trust this person That would be rather foolish even with a fully viewable history. I don't understand why you're so worked up about this—nobody is forcing you to use the code.

I think there are 3 levels at play here. One is code as curation, a model I'm not particularly interested in. Clearly the publisher, despite not being paid, is a supplicant. and as a curator I'm as much or more interested the in process being used and the longetivity of the code base.

The second is code as artifact. Is this code useful, performant, with a reasonable API.

The third is code as concept, or architecture. This is really what interests me here. I use explicit allocators any time I can get away with it, and it's an excellent tool for involved systems projects. I'm not really interested in using this code, but having implemented these things many times, looking at how other people made the various tradeoffs, how it all came together, is really valuable input for when I'm going to do this again. Maybe there are some really brand new ideas here.

While I'm unsympathetic to the first perspective, it's valid. But I don't think its fair to castigate someone who put something on GitHub for not meeting someones adoption criteria.

Re: A single-file C allocator with explicit heaps and tuning knobs

#26

Post by fatty_patty89 » Sat, Mar 28, 2026, 5:02 PM UTC

bitbasher wrote: post #11

tosti wrote: post #9

Earlier quoted context omitted.

I also do this. Lots of weird commit messages because fuck that, I'm busy. Commits that are just there to put some stuff aside, things like that. I don't owe it to anyone to show how messy my kitchen is.

> I don't owe it to anyone to show how messy my kitchen is. There was once a time when sharing code had a social obligation. This attitude you have isn't in the same spirit. GitHub (or any forge) was never meant to be a garbage dumping ground for whatever idea you cooked up at 3AM.

that world never existed

Re: A single-file C allocator with explicit heaps and tuning knobs

#27

Post by lstodd » Sat, Mar 28, 2026, 5:04 PM UTC

dnautics wrote: post #24

lstodd wrote: post #23

Zig got this right to such a degree that I'm sometimes tempted to export its allocators to C via FFI. Then I sober up a bit and just rewrite it all in zig, all its instability nonwithstanding.

Not only that, since there is a super-standard std allocator api, it makes itself very amenable to memory safety analysis, as long as you don't sneakily implement allocations outside of that api. https://github.com/ityonemo/clr

Now this is very interesting. Thank you for sharing.

Re: A single-file C allocator with explicit heaps and tuning knobs

#28

Post by johnisgood » Sat, Mar 28, 2026, 5:14 PM UTC

bitbasher wrote: post #7

sebazzz wrote: post #5

Earlier quoted context omitted.

You still have things like git squash etc.

That doesn't make any sense. There's 10,000+ lines of code. There shouldn't be a single commit "Initial commit". I'm fine with squashing some commits and creating a clean history, but this isn't a clean history it's obfuscated.

I have done "Initial commit"s after having almost finished something. Sometimes fter >10k lines. Totally unrelated to LLMs, as I have done it years ago as well, and has nothing to do with LLMs. I see why you would think what you do though, but it does not logically follow.

Re: A single-file C allocator with explicit heaps and tuning knobs

#29

Post by motters » Sat, Mar 28, 2026, 5:15 PM UTC

As a long time C coder I checked this out, because I have my own malloc replacement. The source code is nonsensical garbage.

Re: A single-file C allocator with explicit heaps and tuning knobs

#30

Post by kstrauser » Sat, Mar 28, 2026, 5:27 PM UTC

bitbasher wrote: post #11

tosti wrote: post #9

Earlier quoted context omitted.

I also do this. Lots of weird commit messages because fuck that, I'm busy. Commits that are just there to put some stuff aside, things like that. I don't owe it to anyone to show how messy my kitchen is.

> I don't owe it to anyone to show how messy my kitchen is. There was once a time when sharing code had a social obligation. This attitude you have isn't in the same spirit. GitHub (or any forge) was never meant to be a garbage dumping ground for whatever idea you cooked up at 3AM.

Never happened. My projects start with me goofing around and playing with things, accidentally committing my editor config or a logfile, etc. The first commit on my public release is a snapshot of the first working version, minus all the dumb typos and malcommits I made along the way.

I don’t owe it to anyone to show how the sausage was made. Once it’s out the door and public, things are different. But before then? No one was the moral right to see all my mistakes leading up to the first release.