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

Why is the first C++ (m)allocation always 72 KB?

joelsiks.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Why is the first C++ (m)allocation always 72 KB?

#21

Post by syncsynchalt »

jebarker wrote: post #20

Reading this was a good reminder not to be intimidated by assumptions about complexity. (Without giving it much thought) I would have assumed that it would be hard to replace malloc for such fundamental applications as ls, but it's surprisingly simple.

There's usually an easy-ish way to override malloc/calloc/realloc/free on Unix, as it's very useful to do when debugging issues or just to collect allocation metrics.

In ELF objects (i.e. on Linux) this is usually done with the "Weak" symbol binding. This is an optional flag for symbols in ELF format that let you override a symbol by providing a competing non-weak symbol, which the linker will prefer when there is a conflict. https://en.wikipedia.org/wiki/Weak_symbol

You can see the list of Weak symbols by looking for a 'W' in the output of `nm` on linux hosts.

Re: Why is the first C++ (m)allocation always 72 KB?

#22

Post by anonymousiam »

So basically, before any of the code even runs, this environment begins by gobbling up more than the total RAM that most of my first computers had (SYM-1, IAMSAI-8080, Ferguson Big Board, Kaypro II, and CCS S-100 Z-80). All of these systems were 8-bit, with various RAM sizes from 8KB to 64KB. That was the maximum RAM available, and it was shared by the OS and the applications.

Re: Why is the first C++ (m)allocation always 72 KB?

#24

Post by pjmlp »

appreciatorBus wrote: post #19
pjmlp wrote: post #16

Earlier quoted context omitted.

Yeah, but that isn't C++ in isolation, thus the tile is incorrect.

Article has been updated > EDIT (March 1, 2026): I updated the title to to clarify that this observation is specific to my environment. The original title may have implied a universal behavior, which isn’t the case. Thanks for the feedback!

Thanks for the update!

Re: Why is the first C++ (m)allocation always 72 KB?

#25

Post by surajrmal »

anonymousiam wrote: post #22

So basically, before any of the code even runs, this environment begins by gobbling up more than the total RAM that most of my first computers had (SYM-1, IAMSAI-8080, Ferguson Big Board, Kaypro II, and CCS S-100 Z-80). All of these systems were 8-bit, with various RAM sizes from 8KB to 64KB. That was the maximum RAM available, and it was shared by the OS and the applications.

What's the purpose of making such a comparison? The implication is that we're being wasteful, but I'm not certain that's the point you're trying to make.

Re: Why is the first C++ (m)allocation always 72 KB?

#28

Post by ozgrakkurt »

jebarker wrote: post #20

Reading this was a good reminder not to be intimidated by assumptions about complexity. (Without giving it much thought) I would have assumed that it would be hard to replace malloc for such fundamental applications as ls, but it's surprisingly simple.

This applies to a lot of things unfortunately. There is a cult of just being afraid and scaring other people.

"You can't do it, just use a library.". "Just use this library, everyone uses it.". "Even google uses this library, do you think you are better." etc.

To add another example to this, you will read that memcpy is super mega optimized on libc and you shouldn't do it yourself etc. etc. etc.

But if you just check clickhouse [1] as an example. They implemented it, it is pretty basic and they say it works well in the comments of the code.

Also you can check musl libc code etc. and it is fairly simple.

People still would argue that you used some intrinsic so it isn't portable or you just benchmarked on one case so it won't work well overall.

Well you CAN benchmark as wide as you want inside your project and have a different memcpy code per project. This kind of thing isn't as bad as people make it out to be in my opinion.

Ofc memcpy is just an example here and it applies similarly to memory allocation, io etc.

As a negative note, imo this is one of the major reasons why most software is super crappy now. Everything uses some library -> those libraries change all the time -> more breaking -> more maintenance. Similar chain happens in terms of performance because the person that wrote that library probably doesn't even know how I am using the library.

This is also why people have endless arguments about what library/tool to use while they can be learning more and more things every day.

[1] https://github.com/ClickHouse/ClickHouse/blob/master/base/gl...

Re: Why is the first C++ (m)allocation always 72 KB?

#29

Post by userbinator »

jebarker wrote: post #20

Reading this was a good reminder not to be intimidated by assumptions about complexity. (Without giving it much thought) I would have assumed that it would be hard to replace malloc for such fundamental applications as ls, but it's surprisingly simple.

If you started learning from the "bottom-up", you wouldn't think it's intimidating. Fortunately, it's never too late to start learning.

Re: Why is the first C++ (m)allocation always 72 KB?

#30

Post by anonymousiam »

surajrmal wrote: post #25
anonymousiam wrote: post #22

So basically, before any of the code even runs, this environment begins by gobbling up more than the total RAM that most of my first computers had (SYM-1, IAMSAI-8080, Ferguson Big Board, Kaypro II, and CCS S-100 Z-80). All of these systems were 8-bit, with various RAM sizes from 8KB to 64KB. That was the maximum RAM available, and it was shared by the OS and the applications.

What's the purpose of making such a comparison? The implication is that we're being wasteful, but I'm not certain that's the point you're trying to make.

That was close to my point. RAM prices are up 400% over last year. I know that 72KB seems like a pittance today, but any waste is bad -- especially in embedded environments.

I'm not really even saying this is wasteful. Maybe a static allocation would make more sense for critical exception handling code...

Post reply on HN