Re: IF NOTs

On Dec 20, 4:26 pm, Elizabeth D Rather <erat...@xxxxxxxxx> wrote:
rickman wrote:
On Dec 18, 4:15 am, Reinhold Straub <demarc...@xxxxxx> wrote:
On 18 Dez., 02:48, "Ed" <nos...@xxxxxxxxxxx> wrote:

There may once have been. Today, however, an optimizing compiler will
optimize NOT IF cases anyway. So all one saves is some typing.
NOT IF and NIF could provide different branch prediction hints to the
compiler.
So they would be logically different?  Used for different purposes?
No, only for performance tuning on some processors. Compare:

: a  IF x ELSE y THEN ;
: b  NIF y ELSE x THEN ;

This is logically equivalent, but on processors with static branch
prediction, usually "TRUE a" will be faster than "TRUE b" and "FALSE
a" will will slower than "FALSE a".

Can you explain this statement?  It would seem to me that the "TRUE a"
case (executing x) would be slower than the "TRUE b" case (also
executing x).  The "TRUE a" case has to execute two jumps, the first
one being conditional and the second at the "ELSE".  The "TRUE b"
example only has a single, conditional jump instruction.  The
manipulation of the flag depends on the details of the instruction set
of the processor used.  Some are capable of branching on zero or not
zero as needed.  Others have fewer condition options and would require
manipulation of the flag before the conditional instruction.

No, the code for IF (the "TRUE a" case) performs the test, but only
branches on zero (FALSE).  The TRUE case falls through into the TRUE
code, but then branches at the ELSE (which is why it's nice that ELSE is
optional).

Yes, it only take the branch on a FALSE, but the instruction is
executed regardless. The TRUE case always has to take a branch at the
end if there is an else case, so the TRUE case is slower. Both have a
branch, but the TRUE case runs the same code the FALSE case does, plus
the branch at the end. So the TRUE case is slower than the FALSE
given that a FALSE exists.

Rick
.

Relevant Pages

  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... I ask why WOULD it be slower? ... the extra instruction is small compared to the time to execute the move. ... Micro Focus' efficiency advice is exactly the same on every platform, ... becomes zero, rather than incrementing the counter from zero to n. ...
    (comp.lang.cobol)
  • Re: IF NOTs
    ... NOT IF and NIF could provide different branch prediction hints to the ... case (executing x) would be slower than the "TRUE b" case (also ... conditional jump instruction. ... Some are capable of branching on zero or not ...
    (comp.lang.forth)
  • Re: Cobol Myth Busters
    ... *subtracting* 5 from a register is certainly slower than subtracting 1 ... Intel has an INC instruction to add 1. ... the other is decrementing the counter to zero. ...
    (comp.lang.cobol)
  • Re: Cobol Myth Busters
    ... Do you think adding 5 is slower than adding 1? ... Intel has an INC instruction to add 1. ... the other is decrementing the counter to zero. ... but it gives an insight into optimization. ...
    (comp.lang.cobol)
  • Re: Cross-Modifying Code
    ... > There's an explicit warning that instruction fetch and page table accesses ... > don't honour xFENCE for prefetched code either. ... > then you don't know when to issue the CPUID. ... The Opteron manuals don't comment on the interaction between executing code ...
    (comp.lang.asm.x86)
Loading