Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

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

#31

Post by paroneayea »

tosti wrote: post #9
bitbasher wrote: post #7

Earlier quoted context omitted.

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

Does your makefile also do this https://github.com/xtellect/spaces/blob/422dbba85b5a7e9a209a...

This repo is full of so many strange and hilarious things. Look, I'm a lisper, and this is even too many parentheses for me https://github.com/xtellect/spaces/blob/master/spaces.c#L471...

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

#33

Post by xantronix »

Brother. What is up with the Makefile rule 'test'? I don't mean to be harsh but is this performance art?

Edit: Homie. Why is bench.sh fetching external resources? Call me old fashioned, but it would be nice if when I cloned the repository (and checked out any submodules that may exist), I've got everything I need, right there.

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

#34

Post by MaulingMonkey »

bitbasher wrote: post #18
drob518 wrote: post #13

Earlier quoted context omitted.

It may have been released with a new repo created, losing all the previously-private history.

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…

> no commit history, 10k+ lines of complicated code

This kind of pattern is incredibly common when e.g. a sublibrary of a closed source project is extracted from a monorepository. Search for "_LICENSE" in the source code and you'll see leftover signs that this was indeed at one point limited to "single-process-package hardware" for rent extraction purpouses.

Now, for me, my bread and butter monorepos are Perforce based, contain 100GB+ of binaries (gamedev - so high-resolution textures, meshes, animation data, voxely nonsense, etc.) which take an hour+ to check out the latest commit, and frequently have mishandled bulk file moves (copied and deleted, instead of explicitly moved through p4/p4v) which might mean terrabytes of bandwidth would be used over days if trying to create a git equivalent of the full history... all to mostly throw it away and then give yourself the added task of scrubbing said history to ensure it contains no code signing keys, trade secrets, unprofessional easter eggs, or other such nonsense.

There are times when such attention to detail and extra work make sense, but I have no reason to suspect this is one of them. And I've seen monocommits of much worse - typically injested from .zip or similar dumps of "golden master" copies, archived for the purpouses of contract fulfillment, without full VCS history.

Even Linux, the titular git project, has some of these shenannigans going on. You need to resort to git grafts to go earlier than the Linux-2.6.12-rc2 dump, which is significantly girthier.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

https://github.com/torvalds/linux/commit/1da177e4c3f41524e88...

0 parents.

> It looks to be generated from another code base as a sorta amalgamation (either through code generation, ai, or another means).

I'm only skimming the code, but other posters point out some C macros may have been expanded. The repeated pattern of `(chunk)->...` reminds me of a C-ism where you defensively parenthesize macro args in case they're something complex like `a + b`, so it expands to `(a + b)->...` instead of `a + b->...`.

One explaination for that would be stripping "out of scope" macros that the sublibrary depends on but wishes to avoid including.

> We're supposed to implicitly trust this person

Not necessairly, but cleaner code, git history, and a more previously active account aren't necessairly meant to suggest trust either.

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

#35

Post by MaulingMonkey »

MaulingMonkey wrote: post #34
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…

> no commit history, 10k+ lines of complicated code This kind of pattern is incredibly common when e.g. a sublibrary of a closed source project is extracted from a monorepository. Search for "_LICENSE" in the source code and you'll see leftover signs that this was indeed at one point limited to "single-process-package hardware" for rent extraction purpouses. Now, for me, my bread and butter monorepos are Perforce bas…

> One explaination for that would be stripping "out of scope" macros that the sublibrary depends on but wishes to avoid including.

Another explaination would be the original source being multi-file, with the single-file variant being generated. E.g. duktape ( https://github.com/svaarala/duktape ) generates src-custom/duktape.c from src-input/*/*.c ( https://github.com/svaarala/duktape/tree/master/src-input ) via python script, as documented in the Readme:

https://github.com/svaarala/duktape/tree/master?tab=readme-o...

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

#36

Post by tidwall »

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 do this all the time. I’ll spend weeks or months on a project, with thousands of wip commits and various fragmented branches. When ready, I’ll squash it all into a single initial commit for public consumption.

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

#37

Post by throwaway27448 »

convolvatron wrote: post #25
throwaway27448 wrote: post #20

Earlier quoted context omitted.

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

If you have a need for vetted & customizable & extensible allocators, I recommend https://github.com/emeryberger/Heap-Layers

In the meantime, I don't see much value from your criticism of this particular project. I don't think this is a great example of AI slop even if it is generated, and you haven't clearly articulated harm.

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

#38

Post by hrmtst93837 »

throwaway2027 wrote: post #4
enduku wrote: post #2

I wrote this because I wanted more explicit control over heaps when building different subsystems in C. Standard options like jemalloc and mimalloc are incredibly fast, but they act as black boxes. You can't easily cap a parser's memory at 256MB or wipe it all out in one go without writing a custom pool allocator. Spaces takes a different approach. It uses 64KB-aligned slabs, and the metadata lookup is just a pointer…

When dealing with memory in C defaulting to malloc or some opaque structure behind it is unless you just want to allocate and forget it for some one off program that frees memory on proc exit seems bad to me now. For any kind of sophisticated system or module you almost always want to write your own variety of slab, arena, pool, bump whatever it may be allocator.

[flagged]

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

#39

Post by skippyboxedhero »

bitbasher wrote: post #3

There's a single commit in the whole repository. Was this AI generated?

Elements of the readme are a dead giveaway.

I can also tell you that this was written with Claude.

No issues with that in principle but I definitely would not trust Claude to get this stuff correct. Generally, it is quite bad at this kind of thing and usually in ways that are not obvious to people without experience.

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

#40

Post by varispeed »

skippyboxedhero wrote: post #39
bitbasher wrote: post #3

There's a single commit in the whole repository. Was this AI generated?

Elements of the readme are a dead giveaway. I can also tell you that this was written with Claude. No issues with that in principle but I definitely would not trust Claude to get this stuff correct. Generally, it is quite bad at this kind of thing and usually in ways that are not obvious to people without experience.

You have to spend a ton of time on writing comprehensive test suite. It can do so many subtle bugs you would otherwise only find from vague customer report and reproducing by chance.
Post reply on HN