Re: Cobol Myth Busters

On Sun, 09 Sep 2007 19:52:29 -0700, Richard <riplin@xxxxxxxxxxxx> wrote:

On Sep 1, 2:22 pm, Robert <n...@xxxxxx> wrote:

Proposition: "Do not use the REMAINDER, ROUNDED, ON SIZE ERROR or CORRESPONDING phrases if
you want the fastest performance. No optimization is done on arithmetic statements if the
ON SIZE ERROR phrase is used. For this reason, we recommend you do not use this phrase if
high performance is required. The ROUNDED phrase impacts performance, but it is generally
faster to use ROUNDED than try to round the result using your own routine. "

Test:
compute binary-number rounded = binary-number + 1 *> 1 us (no penalty)
add 1 to binary-number *> 15 us
on size error display 'overflow'
end-add

Finding: busted for rounded, confirmed for size error.

You have 'busted' nothing. Rounding will not be needed on an add. You
have merely shown that the compiler is cleverer than you are.

A later test computed binary-number rounded = binary-number + .5, which ran slowly. The
compiler wasn't clever enough to just add 1.

Legacy belief: indexes are faster than subscripts

Test:
05 s-subscript binary pic s9(09) sync.
01 misaligned-area sync.
05 array-element occurs 4096 indexed x-index.
10 misaligned-number comp-5 pic s9(09).
10 to-cause-misalignment pic x(01).
move array-element (s-subscript) to test-byte *> 3 us
move array-element (x-index) to test-byte *> 6 us

Finding: BUSTED. Index is actually slower.

Were they moving the same element ? In any case this is just one
factor in the use of subscript/index. What about performance of
setting the value using SET, UP/DOWN, or MOVE and then accessing the
table ?

You hit on *why* the subscript was faster. The optimizer figured out it wasn't changed
inside the loop, so used the one it had in a register. The index was reloaded each
iteration.

SET .. UP BY 1 should be the same speed as adding 1 to a binary number.

Proposition: When incrementing or decrementing a counter, terminate it with a literal
value rather than a value held in a data item. For example, to execute a loop n times, set
the counter to n and then decrement the counter until it becomes zero, rather than
incrementing the counter from zero to n.

Test:
perform varying binary-number from 10 by -1 until binary-number = 0 *> 150 us
perform varying binary-number from 1 by 1 until binary-number > 10 *> 154 us

Finding: BUSTED

You have busted nothing. You don't seem to know what a 'data item' is.

In a later test, one of the limits was a data item. The literal ran only slightly faster.
PERFORM 10 TIMES was significantly slower than either.

Proposition: Access to tables defined with OCCURS ... DEPENDING is less efficient than
access to tables of fixed size, and so should be avoided where high performance is needed.

Test:

01 depending-area.
05 depending-element occurs 1 to 4096 depending on binary-number.
10 comp-5 pic s9(09).
10 pic x(01).
move array-element (s-subscript) to test-byte *> 3 us
move depending-element (s-subscript) to test-byte *> 3 us

Finding: BUSTED

You have busted nothing. 3us is less than the 5us resolution. Now try
it with bound checking on (which is the default).

You may well claim that turning bound checking off is more effective
than avoiding ODO, but that is a different claim.

Bounds checking doesn't use the ODO variable on Micro Focus. It checks that the subscript
is below the allocated maximum.

To be continued with the most unexpected and interesting case: does aligning numbers on
memory boundaries matter?

On some hardware it matters enormously. For example a 680x0 is byte
addressable but gives an exception if an add is done using an odd
address.

Same on the HP PA, as I demonstrated.

Your usual highly opinionated rant that doesn't let facts get in the
way.

Measured times ARE facts. I didn't choose the propositions to test, them came from a Micro
Focus manual.
.

Relevant Pages

  • Re: Cobol Myth Busters
    ... ON SIZE ERROR phrase is used. ... 01 depending-area. ... add 1 to packed-number *> 160 us ... Packed is almost as slow as display. ...
    (comp.lang.cobol)
  • Re: Cobol Myth Busters
    ... No optimization is done on arithmetic statements if the ... ON SIZE ERROR phrase is used. ... have merely shown that the compiler is cleverer than you are. ...
    (comp.lang.cobol)
  • Re: separate stacks
    ... Care to tell us what/where that is? ... Size optimization is even more important on smaller processors. ... One can also freely use this phrase for just ... and have a hardware stack that can't overflow/underflow. ...
    (comp.lang.forth)
  • Re: separate stacks
    ... Size optimization is even more important on smaller processors. ... One can also freely use this phrase for just ... and have a hardware stack that can't overflow/underflow. ...
    (comp.lang.forth)