4 ms·

> 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 need

by 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

> 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.