5 ms·

One more entitled developer with a claim that something is slow but can't really prove it because he can't measure it nor does he have any other working code to

One more entitled developer with a claim that something is slow but can't really prove it because he can't measure it nor does he have any other working code to compare how blazingly fast can it be. Gotcha. Tip to the author: you can implement a lock-free buffer pool cache for as many threads you need in ~200 LoC. Another tip: it's not gonna be faster but you may get more control over the resources

pjc50 2y ago
You didn't read the article, did you. Not to mention being spectacularly rude about it.
- menaerus 2y ago
  No, I actually read the article and I don't think I was spectacularly rude. I was rather just straight to the point. And rather than bitching "omg, why, oh why did a compiler turn a ctr into a function-call here?!" what I think I gave is a constructive suggestion how to fix the problem, if there was even one to begin with. What I see here in the article is pure theoreticizing and dwelling over details which in 99.9% of the cases do _not_ matter. There wasn't a single experiment shown by the author by which he shows that his use-case is in that 0.01%. I was basically done with reading the article when I read the following nonsense > accessing an extern thread_local with a constructor involves a function call, with the function testing the guard variable of the translation unit where the thread_local is defined. And then > But with inlining, the fast path is quite fast on a good processor. Right, the fast path of inlined ctr call vs slow path of non-inlined ctr call. Really? I call this a BS, especially without the experiments showing the data.
  - otterley 2y ago
    Maybe you should write your own blog post that counters the author’s so that others can learn from your experience.
    - menaerus 2y ago
      I have no such aspirations. Commenting here when I have time and to learn something and not to prove something to somebody else.
MobiusHorizons 2y ago
At the bottom of the article the author provides links to regression reports. In one workload calculating the thread local address was taking 10% of execution time up from 1%. The burden of proof would seem to be on you.
- menaerus 2y ago
  No, that's not how it works. The burden of proof is on the one who is claiming the regression or design flaw, and in this case I am not sure what exactly the author can even claim? He did not run a single experiment where he would show that a non-inlined ctr call is creating a runtime pressure on his fancy profiler. Not a single experiment. Not a single data. This is a pure form of cargo-cult programming not engineering. The unfortunate effect of this and similar blogs is that tomorrow you will have to deal with someone at your work who happened to read this and such material on the web and will take it for granted. He will take it further and implement an "optimization" yet when you ask to demonstrate the problem he was solving you will get big nothing. Just as in this case.

pjc50 2y ago

You didn't read the article, did you. Not to mention being spectacularly rude about it.

menaerus 2y ago
No, I actually read the article and I don't think I was spectacularly rude. I was rather just straight to the point. And rather than bitching "omg, why, oh why did a compiler turn a ctr into a function-call here?!" what I think I gave is a constructive suggestion how to fix the problem, if there was even one to begin with. What I see here in the article is pure theoreticizing and dwelling over details which in 99.9% of the cases do _not_ matter. There wasn't a single experiment shown by the author by which he shows that his use-case is in that 0.01%. I was basically done with reading the article when I read the following nonsense > accessing an extern thread_local with a constructor involves a function call, with the function testing the guard variable of the translation unit where the thread_local is defined. And then > But with inlining, the fast path is quite fast on a good processor. Right, the fast path of inlined ctr call vs slow path of non-inlined ctr call. Really? I call this a BS, especially without the experiments showing the data.
- otterley 2y ago
  Maybe you should write your own blog post that counters the author’s so that others can learn from your experience.
  - menaerus 2y ago
    I have no such aspirations. Commenting here when I have time and to learn something and not to prove something to somebody else.

MobiusHorizons 2y ago

At the bottom of the article the author provides links to regression reports. In one workload calculating the thread local address was taking 10% of execution time up from 1%. The burden of proof would seem to be on you.

menaerus 2y ago
No, that's not how it works. The burden of proof is on the one who is claiming the regression or design flaw, and in this case I am not sure what exactly the author can even claim? He did not run a single experiment where he would show that a non-inlined ctr call is creating a runtime pressure on his fancy profiler. Not a single experiment. Not a single data. This is a pure form of cargo-cult programming not engineering. The unfortunate effect of this and similar blogs is that tomorrow you will have to deal with someone at your work who happened to read this and such material on the web and will take it for granted. He will take it further and implement an "optimization" yet when you ask to demonstrate the problem he was solving you will get big nothing. Just as in this case.