7 ms·

> it can be hard to prove that using the addressing mode is faster in the absence of the register pressure scenario I described. Maybe you personally weren't a

by acqq 6y ago

> it can be hard to prove that using the addressing mode is faster in the absence of the register pressure scenario I described. Maybe you personally weren't able to prove to yourself if you did some very small microbenchmarking, but I really believe that measuring the differences of bigger code built with one or another approach it should be relatively straightforward to demonstrate the advantage of using the more compact instructions.

pizlonator 6y ago
Wow you are presumptive. These were giant macrobenchmarks. And I said hard, not impossible. As in, most code doesn’t care if you shift or lea, unless it affects regalloc, which it almost always does. It’s true that having smaller code is better regardless of perf - so if perf was neutral we would still use those instructions. The benefit of the smaller instructions for perf is better register allocation, as I said. So, for macrobenchmarks, using the smaller instructions is a win every single time. And that win comes mostly from fewer spills. That’s the point of what I’m saying. I suppose someone could do the experiment of turning on instruction selection patterns for address modes but still “pinning down” a register as if it was needed for the shift-add sequence you would have otherwise emitted. Feel free to do that if you want to prove me wrong. But just hand waving that I must not have run big benchmarks isn’t going to help you learn more about compilers.
- acqq 6y ago
  > I suppose someone could do the experiment of turning on instruction selection patterns for address modes but still “pinning down” a register as if it was needed for the shift-add sequence you would have otherwise emitted. Starting with that as a thought experiment, isn't it expected that the bigger code can be shown to execute slower, as soon as the performance isn't measured with a microbenchmarking test which avoids to stress caches? Or to be more specific, imagine starting with your proposed modification of the compiler and recompiling both an OS and all the applications. Would the resulting change in the performance be measurable or not? I honestly can't imagine how it wouldn't.
  - pizlonator 6y ago
    > Starting with that as a thought experiment, isn't it expected that the bigger code can be shown to execute slower, as soon as the performance isn't measured with a microbenchmarking test which avoids to stress caches? I agree that it “should” be so. I’m just saying that based on data I’ve seen so far, I don’t think it actually is. But only one way to find out, and that’s to run the experiment. Note that some apps care about icache for perf and some kinda don’t. Sometimes the thing that the program is blocked on in the cpu is data or something else, not instruction fetching, so if you make the fetching slower it won’t affect the end-to-end perf. Basically run time is not a linear function of overheads but rather something much more complex since there is queueing and asynchrony going on. It’s possible for one element of a program to be worse but it doesn’t affect running time because the CPU is blocked elsewhere. And lets stop talking about microbenchmarks, ok? I don’t use those. None of my claims are based on them. > Or to be more specific, imagine starting with your proposed modification of the compiler and recompiling both an OS and all the applications. Would the resulting change in the performance be measurable or not? I honestly can't imagine how it wouldn't. Yeah, that’s an experiment someone could try. I think probabilistically so I don’t want to say that I believe that the experiment will definitely go one way or another. But I can give you my odds: - 20% chance you see a speedup of any kind, and only 5% chance it’ll be uncontroversial (remember when you test big shit, somethings will be faster and others slower and you’ll have noise - so good chance you’ll see data that makes you feel like something is just wrong). - 80% chance that speedup is less than a quarter of the speedup if you hadn’t pinned down the register.
    - pizlonator 6y ago
      Thinking about it even more - if you did see a speedup and you had the ability to analyze why it sped up, then I bet that increased work in the cpu would be the cause sooner than icache pressure. On x86, I think that an instruction with a memory address always takes a cycle to compute it no matter how simple or hard it is, so if you do the computation in a separate instruction, you are likely to add cycles.

by acqq 6y ago

pizlonator 6y ago

Wow you are presumptive. These were giant macrobenchmarks. And I said hard, not impossible. As in, most code doesn’t care if you shift or lea, unless it affects regalloc, which it almost always does. It’s true that having smaller code is better regardless of perf - so if perf was neutral we would still use those instructions. The benefit of the smaller instructions for perf is better register allocation, as I said. So, for macrobenchmarks, using the smaller instructions is a win every single time. And that win comes mostly from fewer spills. That’s the point of what I’m saying. I suppose someone could do the experiment of turning on instruction selection patterns for address modes but still “pinning down” a register as if it was needed for the shift-add sequence you would have otherwise emitted. Feel free to do that if you want to prove me wrong. But just hand waving that I must not have run big benchmarks isn’t going to help you learn more about compilers.

acqq 6y ago
> I suppose someone could do the experiment of turning on instruction selection patterns for address modes but still “pinning down” a register as if it was needed for the shift-add sequence you would have otherwise emitted. Starting with that as a thought experiment, isn't it expected that the bigger code can be shown to execute slower, as soon as the performance isn't measured with a microbenchmarking test which avoids to stress caches? Or to be more specific, imagine starting with your proposed modification of the compiler and recompiling both an OS and all the applications. Would the resulting change in the performance be measurable or not? I honestly can't imagine how it wouldn't.
- pizlonator 6y ago
  > Starting with that as a thought experiment, isn't it expected that the bigger code can be shown to execute slower, as soon as the performance isn't measured with a microbenchmarking test which avoids to stress caches? I agree that it “should” be so. I’m just saying that based on data I’ve seen so far, I don’t think it actually is. But only one way to find out, and that’s to run the experiment. Note that some apps care about icache for perf and some kinda don’t. Sometimes the thing that the program is blocked on in the cpu is data or something else, not instruction fetching, so if you make the fetching slower it won’t affect the end-to-end perf. Basically run time is not a linear function of overheads but rather something much more complex since there is queueing and asynchrony going on. It’s possible for one element of a program to be worse but it doesn’t affect running time because the CPU is blocked elsewhere. And lets stop talking about microbenchmarks, ok? I don’t use those. None of my claims are based on them. > Or to be more specific, imagine starting with your proposed modification of the compiler and recompiling both an OS and all the applications. Would the resulting change in the performance be measurable or not? I honestly can't imagine how it wouldn't. Yeah, that’s an experiment someone could try. I think probabilistically so I don’t want to say that I believe that the experiment will definitely go one way or another. But I can give you my odds: - 20% chance you see a speedup of any kind, and only 5% chance it’ll be uncontroversial (remember when you test big shit, somethings will be faster and others slower and you’ll have noise - so good chance you’ll see data that makes you feel like something is just wrong). - 80% chance that speedup is less than a quarter of the speedup if you hadn’t pinned down the register.
  - pizlonator 6y ago
    Thinking about it even more - if you did see a speedup and you had the ability to analyze why it sped up, then I bet that increased work in the cpu would be the cause sooner than icache pressure. On x86, I think that an instruction with a memory address always takes a cycle to compute it no matter how simple or hard it is, so if you do the computation in a separate instruction, you are likely to add cycles.