Live data from Hacker News

The Horror in the Standard Library

zerotier.com

11–20 of 222 posts

Re: The Horror in the Standard Library

#11

People forget that C++ is just a tool , like a screwdriver or a hammer. A good carpenter knows when it's time to take a metallurgy class and resmelt his hammer, because its composition is not correct for being a hammer.

I am pretty sure there has never been a carpenter who resmelted his hammer.

Re: The Horror in the Standard Library

#12
post #5

I myself ran across this same scenario many years ago with a similar amount of hair pulling and eventually concluding that the GNU libstdc++ allocator wasn't reusing memory properly. Unfortunately, I was never able to pare down the application to the point that I had a reproducible test case to report upstream. GLIBCPP_FORCE_NEW was the solution for the near term and since I was deploying on Solaris boxes I eventuall…

It really bugs me that nobody links bug on bugtracker or filed it. I know I'm asking a lot and being an ass.

Re: The Horror in the Standard Library

#13

People forget that C++ is just a tool , like a screwdriver or a hammer. A good carpenter knows when it's time to take a metallurgy class and resmelt his hammer, because its composition is not correct for being a hammer.

If occasionally when you try to use a hammer to hit a nail, the hammer swings the other way and hits you, that tool has violated some essential assumptions about how tools work, and the "it's just a tool" reasoning might not apply as clearly any more. :)

Re: The Horror in the Standard Library

#14

People forget that C++ is just a tool , like a screwdriver or a hammer. A good carpenter knows when it's time to take a metallurgy class and resmelt his hammer, because its composition is not correct for being a hammer.

I am pretty sure there has never been a carpenter who resmelted his hammer.

I think that is the joke...

Re: The Horror in the Standard Library

#15
Yeah malloc() is pretty terrible in glibc by modern standards. For some workloads it just can't keep up and ends up fragmenting space in such a way that memory can't be returned to the OS (and thus be used for the page cache) and you end up in this performance spiral.

I always deploy C++ server on jemalloc. Been doing it for years and while there's been occasional hicks up when updating it has provided much more predictable performance.

Re: The Horror in the Standard Library

#16

People forget that C++ is just a tool , like a screwdriver or a hammer. A good carpenter knows when it's time to take a metallurgy class and resmelt his hammer, because its composition is not correct for being a hammer.

I am pretty sure there has never been a carpenter who resmelted his hammer.

I'm not sure "resmelting" is even a thing. I am sure that the GP is joking.

Re: The Horror in the Standard Library

#17
> Nothing made any sense until we noticed the controller microservice's memory consumption. A service that should be using perhaps a few hundred megabytes at most was using gigabytes and growing... and growing... and growing... and growing...

Not identifying this until many hours after symptoms were impacting users sounds like a pretty big monitoring blind spot.

Re: The Horror in the Standard Library

#18
post #15

Yeah malloc() is pretty terrible in glibc by modern standards. For some workloads it just can't keep up and ends up fragmenting space in such a way that memory can't be returned to the OS (and thus be used for the page cache) and you end up in this performance spiral. I always deploy C++ server on jemalloc. Been doing it for years and while there's been occasional hicks up when updating it has provided much more pred…

This has nothing to do with glibc malloc()

Re: The Horror in the Standard Library

#19
post #16

Earlier quoted context omitted.

I am pretty sure there has never been a carpenter who resmelted his hammer.

I'm not sure "resmelting" is even a thing. I am sure that the GP is joking.

It's not a thing. Smelting means purifying from ore by melting. Unless you turn your hammer back into iron ore, there's no way to "resmelt" it

Re: The Horror in the Standard Library

#20
post #15

Yeah malloc() is pretty terrible in glibc by modern standards. For some workloads it just can't keep up and ends up fragmenting space in such a way that memory can't be returned to the OS (and thus be used for the page cache) and you end up in this performance spiral. I always deploy C++ server on jemalloc. Been doing it for years and while there's been occasional hicks up when updating it has provided much more pred…

Actually from my understanding, it's libstdc++'s allocator that is causing the issue, not malloc.
Post reply on HN