3 ms·

> So unless you did profile, your comment didn't really add anything. The previous comment explained why and how the author's analysis is flawed. Then it goes

by vog 11y ago

> So unless you did profile, your comment didn't really add anything. The previous comment explained why and how the author's analysis is flawed. Then it goes over top by speculating exactly into the opposite direction. But that doesn't reduce the quality of the first part of the comment. That part was still valuable to me.

vardump 11y ago
Ok, you have a point. Original author's analysis is flawed, it doesn't extend to multi-socket systems. What we don't know is how thing scales beyond a single socket. The graph is not going to tell us anything about that. Profiling will. Experience has shown to me assumptions are bad. So now I don't assume a certain call will succeed or even work the way I think it does. Instead I check return value of every call and test it against my assumptions. I never assume much about performance either. I might occasionally use microbenchmarks as a hint. But the main mode of operation is measuring as big of a piece of functionality as possible. Many different size, but realistic, workloads. Preferably on multiple different systems as well. If performance is the goal, I'd advocate one trying out different concurrent hash map implementations in the system one is building. Never assume.
- exDM69 11y ago
  > The graph is not going to tell us anything about that. Profiling will. What kind of profiling would you employ for a concurrent data structure like the hash map here? Instrumented code or sampling profilers? I'm afraid both kinds of profiling would yield quite meaningless information, because the individual operations are quite fast and the runtime may vary depending on e.g. cache utilization and contention. Profiling is good for bigger applications but it's not super useful for "primitive" operations like hash map inserts. If I were to optimize something like this, I'd first reach for the CPU performance counters trying to understand what aspect is the bottle neck.
  - vardump 11y ago
    > ... Instrumented code or sampling profilers? A sampling profiler would be helpful. Although most hash map related samples would likely fall on atomic ops it presumably uses for synchronization. On the other hand, you'd know whether you need to optimize this in the first place. Instrumented profiler would yield garbage data for a lot of reasons, I wouldn't use that, except maybe over a large group of hash map operations. > ... I'd first reach for the CPU performance counters I count CPU performance counters as profiling.

by vog 11y ago

vardump 11y ago

Ok, you have a point. Original author's analysis is flawed, it doesn't extend to multi-socket systems. What we don't know is how thing scales beyond a single socket. The graph is not going to tell us anything about that. Profiling will. Experience has shown to me assumptions are bad. So now I don't assume a certain call will succeed or even work the way I think it does. Instead I check return value of every call and test it against my assumptions. I never assume much about performance either. I might occasionally use microbenchmarks as a hint. But the main mode of operation is measuring as big of a piece of functionality as possible. Many different size, but realistic, workloads. Preferably on multiple different systems as well. If performance is the goal, I'd advocate one trying out different concurrent hash map implementations in the system one is building. Never assume.

exDM69 11y ago
> The graph is not going to tell us anything about that. Profiling will. What kind of profiling would you employ for a concurrent data structure like the hash map here? Instrumented code or sampling profilers? I'm afraid both kinds of profiling would yield quite meaningless information, because the individual operations are quite fast and the runtime may vary depending on e.g. cache utilization and contention. Profiling is good for bigger applications but it's not super useful for "primitive" operations like hash map inserts. If I were to optimize something like this, I'd first reach for the CPU performance counters trying to understand what aspect is the bottle neck.
- vardump 11y ago
  > ... Instrumented code or sampling profilers? A sampling profiler would be helpful. Although most hash map related samples would likely fall on atomic ops it presumably uses for synchronization. On the other hand, you'd know whether you need to optimize this in the first place. Instrumented profiler would yield garbage data for a lot of reasons, I wouldn't use that, except maybe over a large group of hash map operations. > ... I'd first reach for the CPU performance counters I count CPU performance counters as profiling.