3 ms·

Maybe I misunderstood your claim. I thought your claim was that the LEA needs to be three operand plus satisfy one of the claims in the list? If you are just s

Maybe I misunderstood your claim. I thought your claim was that the LEA needs to be three operand plus satisfy one of the claims in the list? If you are just saying that the issue is that the author says "ebp as base" rather than "ebp as base in an indexed addressing mode", then I agree.

acqq 7y ago
> If you are just saying that the issue is that the author says "ebp as base" rather than "ebp as base in an indexed addressing mode" Correct. I specifically wrote "One can write a lot of LEAs without three operands or without index register and of course use {E,R}BP in them without any issue." Even if "OR" list notes that some uses of LEA are slower (actually, if I would say, with "higher latency"), LEA with BP is still too useful to reduce the logic to the article's claim: "using EBP, RBP, or R13 as the base address will make LEA slower." No it won't for enough cases where it's important to use it. I didn't even address the topic that higher latency doesn't even have to mean that the throughput is reduced at all, when the rest of the code fits. But even at the low level of precision of the article, it's still a wrong claim, that what's written in that sentence. It's just a detail, but at this level (of caring about which instruction to use where), everything is exactly about the details.
- BeeOnRope 7y ago
  Yes, the author should have made it clear that the slow LEA caveat only applies to the indexed addressing case. I probably misunderstood what you were saying here: > Note "with three source operands" and "uses base and index" as in "both at the same time." When you said "both" I thought you were referring to both clauses you mentioned ("3-arg" and "base and index"), but I see now you may have saying both base and index (it was the mention of 3-arg that threw me off). Slow LEA is slower in a throughput sense too: half the throughput on modern mainstream Intel except Ice Lake. > I didn't even address the topic that higher latency doesn't even have to mean that the throughput is reduced at all, when the rest of the code fits. Agreed, but that's true of almost any fine-granied performance discussion ever. I think it's fine to say that a LEA with half the throughput and triple the latency is slower in a sense, even though "in-situ" there may be plenty of cases where it makes no measurable difference. The same is true of other slow stuff like muls, divs, branch mispredictions, atomic ops: there are cases where all of those don't matter (not just in an approximate sense, as in "the penalty is zero"). You are not wrong but always putting that caveat gets tiring, it would be nice if we could just assume it. Beyond that, almost any use of a "slower" instruction can actually speed things up, e.g. due to an alignment or scheduling effect, but man I don't want to mention that every time either. As a practical matter, few people have the capability to mentally simulate the pipeline to determine whether slow LEA is going to have an impact or not (and this is error prone and in any case not all the details are out there to do it totally accurately. So the problematic r13/rbp cases are mostly easy to avoid, just avoiding them seems like reasonable advice.
  - acqq 7y ago
    > As a practical matter, few people have the capability to mentally simulate the pipeline to determine whether slow LEA is going to have an impact or not That's why the people should not do it most of the time, that's why we have compilers. And I claim that a compiler programmed in absolutes as advised by the article "just don't use EBP with LEA" would produce poor code. And that much is easy to follow even by humans.
    - BeeOnRope 7y ago
      If you were writing a compiler, you'd just use the correct rule (and you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. I'm wasn't even arguing for the use of the over-broad rule in the part you quoted: I was actually arguing for the use of the full rule but without worrying too much about the caveat that even using slow lea might be just as fast (or faster, due to non-monotonic effects).
      - acqq 7y ago
        > you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. There's nothing that prevents existing assemblers to already do this -- I haven't checked them though, since I used my own -- I use the term "compiler" as everything together up to the parts that produce the actual binary codes. I know that e.g. gcc makes (or, at least, made) an explicit separation producing the assembly in the source form. But it still would be plausible that it's already implemented in such assemblers -- which would make the userbinator's argument here even less relevant.
        BeeOnRope 7y ago
        As far as I know at least some assemblers do this - certainly nasm, for example, makes all kinds of similar optimizations to the encoding, and I expect it to get this one right. It's kind of too little, too late though: you want the higher level compiler to be avoiding rbp/r13 in scenarios where this could occur and the assembler couldn't fix it. I don't think compilers do this, though.

acqq 7y ago

> If you are just saying that the issue is that the author says "ebp as base" rather than "ebp as base in an indexed addressing mode" Correct. I specifically wrote "One can write a lot of LEAs without three operands or without index register and of course use {E,R}BP in them without any issue." Even if "OR" list notes that some uses of LEA are slower (actually, if I would say, with "higher latency"), LEA with BP is still too useful to reduce the logic to the article's claim: "using EBP, RBP, or R13 as the base address will make LEA slower." No it won't for enough cases where it's important to use it. I didn't even address the topic that higher latency doesn't even have to mean that the throughput is reduced at all, when the rest of the code fits. But even at the low level of precision of the article, it's still a wrong claim, that what's written in that sentence. It's just a detail, but at this level (of caring about which instruction to use where), everything is exactly about the details.

BeeOnRope 7y ago
Yes, the author should have made it clear that the slow LEA caveat only applies to the indexed addressing case. I probably misunderstood what you were saying here: > Note "with three source operands" and "uses base and index" as in "both at the same time." When you said "both" I thought you were referring to both clauses you mentioned ("3-arg" and "base and index"), but I see now you may have saying both base and index (it was the mention of 3-arg that threw me off). Slow LEA is slower in a throughput sense too: half the throughput on modern mainstream Intel except Ice Lake. > I didn't even address the topic that higher latency doesn't even have to mean that the throughput is reduced at all, when the rest of the code fits. Agreed, but that's true of almost any fine-granied performance discussion ever. I think it's fine to say that a LEA with half the throughput and triple the latency is slower in a sense, even though "in-situ" there may be plenty of cases where it makes no measurable difference. The same is true of other slow stuff like muls, divs, branch mispredictions, atomic ops: there are cases where all of those don't matter (not just in an approximate sense, as in "the penalty is zero"). You are not wrong but always putting that caveat gets tiring, it would be nice if we could just assume it. Beyond that, almost any use of a "slower" instruction can actually speed things up, e.g. due to an alignment or scheduling effect, but man I don't want to mention that every time either. As a practical matter, few people have the capability to mentally simulate the pipeline to determine whether slow LEA is going to have an impact or not (and this is error prone and in any case not all the details are out there to do it totally accurately. So the problematic r13/rbp cases are mostly easy to avoid, just avoiding them seems like reasonable advice.
- acqq 7y ago
  > As a practical matter, few people have the capability to mentally simulate the pipeline to determine whether slow LEA is going to have an impact or not That's why the people should not do it most of the time, that's why we have compilers. And I claim that a compiler programmed in absolutes as advised by the article "just don't use EBP with LEA" would produce poor code. And that much is easy to follow even by humans.
  - BeeOnRope 7y ago
    If you were writing a compiler, you'd just use the correct rule (and you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. I'm wasn't even arguing for the use of the over-broad rule in the part you quoted: I was actually arguing for the use of the full rule but without worrying too much about the caveat that even using slow lea might be just as fast (or faster, due to non-monotonic effects).
    - acqq 7y ago
      > you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. There's nothing that prevents existing assemblers to already do this -- I haven't checked them though, since I used my own -- I use the term "compiler" as everything together up to the parts that produce the actual binary codes. I know that e.g. gcc makes (or, at least, made) an explicit separation producing the assembly in the source form. But it still would be plausible that it's already implemented in such assemblers -- which would make the userbinator's argument here even less relevant.
      - BeeOnRope 7y ago
        As far as I know at least some assemblers do this - certainly nasm, for example, makes all kinds of similar optimizations to the encoding, and I expect it to get this one right. It's kind of too little, too late though: you want the higher level compiler to be avoiding rbp/r13 in scenarios where this could occur and the assembler couldn't fix it. I don't think compilers do this, though.