Re:Benchmarking C++ Allocators
by mitchs on Monday April 27, 2020 @04:07PM
(#22999451)
When I backtrace from my malloc wrapper, injected with LD_PRELOAD, I see malloc, std::new, then the call site that involved new. Unless std::new is doing some funky shit (Like detecting dlsym("malloc") isn't glibc's malloc, and changing implementations) I have my doubts about the claim that dynamic replacement is costly. It appears new is already dynamically linking malloc.
[ Parent
| on HN ]
That is the entire point of the post. If you leave the resolution of malloc to run time, the best you can hope for is that new calls malloc, out of line. If you build with an implementation of new, the outcomes may be dramatically better.
By the way there is no such thing as std::new. We are discussing ::new.
Heh, std::new was some cruft I got out of backtrace(3) with some wacky embedded tool chain.
Are these gains supposed to be from inlining the top level function of malloc into new? Compared to the costs of what can go on inside malloc... Is that the biggest problem?
Dynamic linking requires calling through the PLT to get to the implementation, so there's a data dependency on determining where the code for it is.
Independent of inlining (with LTO, since the C++ language rules requires inhibit optimizing out "operator new"), the static call is far simpler.