5 ms·

I classify this kind of article as "just enough knowledge to be a pain in the ass". Even if you compile it separately per the instructions, trying to force the

I classify this kind of article as "just enough knowledge to be a pain in the ass". Even if you compile it separately per the instructions, trying to force the compiler to generate ABI-callable functions, you can still undo this error with LTO. Building this program with LTO is dramatically faster in both modes compared to either mode of the non-LTO program. If your program is performance-sensitive, profile it, peak-optimize it, and only then commit jackassery such as unpacking structs into arguments.

vlovich123 3y ago
That would be good advice except I’ve yet to see a compiler that can make this kind of stuff visible. First it’s distributed throughout your codebase and I’ve not seen any profiler that can show that impact unless you’re lucky and this becomes a hotspot. This applies to nearly all compiler generated code. Valgrind can measure it (sampling profiler probably can’t) but there’s no tooling to highlight diffuse code gen problems
- bugbuddy 3y ago
  This is clearly a hot path and not inlining a hot path call is probably the first thing any engineer worth his salt would attempt to fix. If and how it can be fixed is a different question.
  - vlovich123 3y ago
    Just because something is in the hot path does not mean a profiler will be able to highlight this as a hotspot.
rwmj 3y ago
Plus the guy is talking about the supreme importance of performance, but is using reference counting.
- FeepingCreature 3y ago
  (Author) The refcounting version is about as slow as the garbage collected D version on the benchmark. Refcounting operations can often be elided if you optimize a bit. And this is not a "supreme importance of performance" microoptimization. This single change moved me from place 23 to place 5. That's a 2x speedup!
  - rwmj 3y ago
    You won't see the problem with refcounting in microbenchmarks. It manifests when you have multiple threads accessing single pieces of data, or are under memory pressure. Refcounting turns reads into writes, unless steps are taken to avoid that, and/or you store the refcounts separately from the data.
    - FeepingCreature 3y ago
      Multiple threads accessing single pieces of data is always slow. The standard answer is "don't do that"; you can do that just as well with GC or manual management.
      - rwmj 3y ago
        Confirming you have no idea what you're talking about.
      - kragen 3y ago
        as i understand it, multiple threads reading single pieces of data is faster than multiple threads reading different copies of the same data, as long as you don't have to lock them or increment their reference counts. it's faster because it reduces cache pressure. rcu is a widely used, highly performant way for many threads to read single pieces of data without having to lock them even if they might change. often you can even implement garbage collection without having to acquire readlocks on garbage-collectable things
  - jeffbee 3y ago
    It only changes your rank in this benchmark because the benchmark fails to use whole program optimization, ie as a benchmark it is meaningless.

vlovich123 3y ago

That would be good advice except I’ve yet to see a compiler that can make this kind of stuff visible. First it’s distributed throughout your codebase and I’ve not seen any profiler that can show that impact unless you’re lucky and this becomes a hotspot. This applies to nearly all compiler generated code. Valgrind can measure it (sampling profiler probably can’t) but there’s no tooling to highlight diffuse code gen problems

bugbuddy 3y ago
This is clearly a hot path and not inlining a hot path call is probably the first thing any engineer worth his salt would attempt to fix. If and how it can be fixed is a different question.
- vlovich123 3y ago
  Just because something is in the hot path does not mean a profiler will be able to highlight this as a hotspot.

rwmj 3y ago

Plus the guy is talking about the supreme importance of performance, but is using reference counting.

FeepingCreature 3y ago
(Author) The refcounting version is about as slow as the garbage collected D version on the benchmark. Refcounting operations can often be elided if you optimize a bit. And this is not a "supreme importance of performance" microoptimization. This single change moved me from place 23 to place 5. That's a 2x speedup!
- rwmj 3y ago
  You won't see the problem with refcounting in microbenchmarks. It manifests when you have multiple threads accessing single pieces of data, or are under memory pressure. Refcounting turns reads into writes, unless steps are taken to avoid that, and/or you store the refcounts separately from the data.
  - FeepingCreature 3y ago
    Multiple threads accessing single pieces of data is always slow. The standard answer is "don't do that"; you can do that just as well with GC or manual management.
    - rwmj 3y ago
      Confirming you have no idea what you're talking about.
    - kragen 3y ago
      as i understand it, multiple threads reading single pieces of data is faster than multiple threads reading different copies of the same data, as long as you don't have to lock them or increment their reference counts. it's faster because it reduces cache pressure. rcu is a widely used, highly performant way for many threads to read single pieces of data without having to lock them even if they might change. often you can even implement garbage collection without having to acquire readlocks on garbage-collectable things
- jeffbee 3y ago
  It only changes your rank in this benchmark because the benchmark fails to use whole program optimization, ie as a benchmark it is meaningless.