5 ms·

>> separate and expensive instruction. > I see no proof of this anywhere. Huh. I see proof in your comment. > UMULH separate? Check. > UMULH has 1/4 and 6

• dmitrygr 8y ago
  not enough to explain the perf discrepancy. as i explained, both of these values 1/4 and 6 are hideable with proper instruction scheduling. at best author proved that arm gcc sucks at instruction scheduling, which is not news to anyone
  • tntn 8y ago
    Then quote the claim that you are objecting to, not the statement of fact (which is what you have currently quoted).
    • dmitrygr 8y ago
      objection was to the implied claim that this is the cause for the slowdown. It is implied by the sentence structure and the preceding paragraph. I've expanded the quote to make it clearer. Thanks
  • naniwaduni 8y ago
    A generation of programmers was indoctrinated to believe they couldn't beat the compiler. It is definitely surprisingly to find a popular compiler generating low-hanging fruit. For many use-cases, if code can't be written to get the compiler in use to generate that sequence of instructions, it might as well not exist.
  • BeeOnRope 8y ago
    I mean 1/4 isn't hideable with "proper instruction scheduling" if you are doing a multiplication-heavy benchmark. No amount of scheduling gymnastics is going to get you more than 1 MULH per 4 cycles. Since the wyhash function needs 2 64x64->128 multiplication, you'll need two high and two low muls on ARM, so this is pretty much a dense multiplication benchmark. No amount of scheduling can save you. Still by my calculation that should only put the ARM chip at a 5x disadvantage in multiplication throughput, but it was nearly 18x slower. Frequency difference probably explains some of that, but not all.