News for hackers. Stuff that matters.

A comment on Benchmarking C++ Allocators. Parent comment

Re:Benchmarking C++ Allocators by jlebar on Monday April 27, 2020 @05:09PM (#23000045)
> My data says that perf of malloc/free in actual programs (not fake ass shit calling malloc in a loop) is never affected by the call overhead.

Your data is legitimate, but you've got to ask yourself, would Jeff specifically and Google more generally care so much about it if it were also true for their use-cases?

[ Parent | on HN ]
Re:Benchmarking C++ Allocators by pizlonator on Monday April 27, 2020 @05:21PM (#23000179)
I don’t consider appeals to authority when thinking about technical issues.
[ Parent | on HN ]
Re:Benchmarking C++ Allocators by jlebar on Monday April 27, 2020 @05:31PM (#23000316)
This isn't an appeal to authority. It's a suggestion that we consider the possibility that they are not wasting their time on make-work.

This is Bayesian logic (our prior is that the systems engineers at Google are not incompetent), not an appeal to anything.

[ Parent | on HN ]
Re:Benchmarking C++ Allocators by pizlonator on Monday April 27, 2020 @06:01PM (#23000622)
Just because someone isn’t incompetent doesn’t mean that we should assume they are right. Highly competent people are often wrong. Questioning things is good.
[ Parent | on HN ]
Re:Benchmarking C++ Allocators by jlebar on Monday April 27, 2020 @07:12PM (#23001275)
> Questioning things is good.

HN could indeed use more epistemic uncertainty and gray (vs black-and-white) thinking.

[ Parent | on HN ]