3 ms·

Without more context about what the code actually does this doesn't tell me all that much, other than what I could guess from the intended usecases of the chips

by mhh__ 4y ago

Without more context about what the code actually does this doesn't tell me all that much, other than what I could guess from the intended usecases of the chips. The strength of Apple silicon is that it can crush benchmarks and transfer that power very well to real world concurrent workloads too e.g. is this basically just measuring the L1 latency? If not are the compilers generating the right instructions etc. (One would assume they are but I have had issues with getting good arm codegen previously, only to find that the compiler couldn't work out what ISA to target other than a conservative guess)

renewiltord 4y ago
Git repo available from post.
- mhh__ 4y ago
  I ain't readin' all that (OK maybe I will but lemire does do this quite a lot, his blog is 40% gems 60% slightly sloppy borderline factoids that only make sense if you think in exactly the same way he does)
KerrAvon 4y ago
Yes. Since it's Ada, I'm suspicious of codegen tuning being a major factor here.
- wtallis 4y ago
  Is there something specific about this library that makes you suspicious, or are you assuming from the name that this is using the Ada programming language?
- zimpenfish 4y ago
  "Ada is a fast and spec-compliant URL parser written in C++." Wouldn't modern C++ compilers have decent codegen tuning for all these platforms?
dan-robertson 4y ago
It does seem the benchmark has its data in cache, based on the timings. If the benchmark were only measuring L1 latency, what would that imply about the ‘scaling by inverse clock speed’ bit? My guess is as follows. Chips with higher clock rates will be penalised: (a) it is harder to decrease latencies (memory, pipeline length, etc) in absolute terms than run at a higher clock speed to maybe do non-memory things faster; and (b) if you’re waiting 5ns to read some data, that hurts you more after the scaling if your clock speed is higher. The fact that the M1 wins after the scaling despite the higher clock rate suggests to me that either they have a big advantage on memory latency or there’s some non-memory-latency advantage in scheduling or branch prediction that leads to more useful instructions being retired per cycle. But maybe I’m interpreting it the wrong way.

by mhh__ 4y ago

renewiltord 4y ago

Git repo available from post.

mhh__ 4y ago
I ain't readin' all that (OK maybe I will but lemire does do this quite a lot, his blog is 40% gems 60% slightly sloppy borderline factoids that only make sense if you think in exactly the same way he does)

KerrAvon 4y ago

Yes. Since it's Ada, I'm suspicious of codegen tuning being a major factor here.

wtallis 4y ago
Is there something specific about this library that makes you suspicious, or are you assuming from the name that this is using the Ada programming language?
zimpenfish 4y ago
"Ada is a fast and spec-compliant URL parser written in C++." Wouldn't modern C++ compilers have decent codegen tuning for all these platforms?

dan-robertson 4y ago

It does seem the benchmark has its data in cache, based on the timings. If the benchmark were only measuring L1 latency, what would that imply about the ‘scaling by inverse clock speed’ bit? My guess is as follows. Chips with higher clock rates will be penalised: (a) it is harder to decrease latencies (memory, pipeline length, etc) in absolute terms than run at a higher clock speed to maybe do non-memory things faster; and (b) if you’re waiting 5ns to read some data, that hurts you more after the scaling if your clock speed is higher. The fact that the M1 wins after the scaling despite the higher clock rate suggests to me that either they have a big advantage on memory latency or there’s some non-memory-latency advantage in scheduling or branch prediction that leads to more useful instructions being retired per cycle. But maybe I’m interpreting it the wrong way.