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

31–39 of 39 posts

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

#31

Post by surajrmal »

anonymousiam wrote: post #30
surajrmal wrote: post #25

Earlier quoted context omitted.

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

Luckily no one is enabling c++ exceptions in embedded environments where ram usage at this level matters.

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

#33

Post by pjmlp »

surajrmal wrote: post #26
pjmlp wrote: post #9

This is compiler specific and cannot be generalised as C++.

I would also expect it to depend on whether or not you have exceptions enabled. Half the ecosystem has them disabled.

I really hate that, and believe if they would have been there since the beginning, the split would not have happened as the option to disable them would not exist in first place.

It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.

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

#34

Post by rramadass »

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.

Right.

Unfortunately, a lot of system level knowledge like this is not found in a single place but spread over many articles/manuals/books/etc.

However, the book Advanced C and C++ Compiling: An Engineering Guide to Compiling, Linking and Libraries using C and C++ by Milan Stevanovic brings together a lot of information which you might find interesting.

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

#35

Post by danhor »

pjmlp wrote: post #33
surajrmal wrote: post #26

Earlier quoted context omitted.

I would also expect it to depend on whether or not you have exceptions enabled. Half the ecosystem has them disabled.

I really hate that, and believe if they would have been there since the beginning, the split would not have happened as the option to disable them would not exist in first place. It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.

It's often a requirement for bare metal embedded development (too heavy in terms of memory), so it's basically unavoidable. Non-standard languages are very common for this kind of thing, just look at the linux-flavoured C.

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

#36

Post by surajrmal »

pjmlp wrote: post #33
surajrmal wrote: post #26

Earlier quoted context omitted.

I would also expect it to depend on whether or not you have exceptions enabled. Half the ecosystem has them disabled.

I really hate that, and believe if they would have been there since the beginning, the split would not have happened as the option to disable them would not exist in first place. It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.

Even rust let's you turn panics into asserts. It saves a lot of binary size and arguably is equally debugable. We also see improved performance from being more cache friendly. C++ usage wouldn't be nearly as high if there wasn't such an option. As far as I'm concerned the primary downside is not being able to return errors in constructors and handle allocation failures but both are solve able via some common idioms (static methods and custom placement new)

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

#37

Post by pjmlp »

surajrmal wrote: post #36
pjmlp wrote: post #33

Earlier quoted context omitted.

I really hate that, and believe if they would have been there since the beginning, the split would not have happened as the option to disable them would not exist in first place. It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.

Even rust let's you turn panics into asserts. It saves a lot of binary size and arguably is equally debugable. We also see improved performance from being more cache friendly. C++ usage wouldn't be nearly as high if there wasn't such an option. As far as I'm concerned the primary downside is not being able to return errors in constructors and handle allocation failures but both are solve able via some common idioms (…

Constructors and destructors can have function level try-catch blocks.

Yes the syntax could have been much better.

As proven by ongoing work done by Khalil Estell, in some embedded scenarios exceptions aren't that great only due to quality of implementation, someone added the support and call it done, no effort at all to improve it.

Even Ada's Ravenscar profile does allow for exceptions in high integrity computing scenarios, in embedded systems.

Well I for one, if that would mean less "C programming with C++ compiler" that still plagues the security history to this day, great they can keep using C for that.

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

#38

Post by jebarker »

userbinator wrote: post #29
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.

That might be true for this particular thing, but there’ll still be some other perceived barrier of complexity, e.g. maybe it’s hardware, maybe it’s math, maybe it’s some higher level application like graphics. My point was that I was reminded to not just assume something would be hard without looking into it.

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

#39

Post by nineteen999 »

ozgrakkurt wrote: post #28
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…

100% - the number of times you will need to use a super optimized memcpy() in real life versus the benefit you can get from looking at and writing basic versions of it for different CPU's is very slim.

Then you'll have a much better idea of when to _really_ use one that depends on intrinsics, is optimized etc, and how to benchmark them ... those are the real skills.

Post reply on HN