Re: Cobol Myth Busters

On Sep 10, 5:54 pm, Robert <n...@xxxxxx> wrote:
On Sun, 09 Sep 2007 19:52:29 -0700, Richard <rip...@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.

Do you know of _any_ compiler for any language that would do that ?


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.

So another advice might be: "Don't loop around doing the same
identical piece of code, just do it once".

Once again the compiler was cleverer than you are.


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

Assertion rather than evidence. That's par for the course with you.


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.

But it _was_ faster. You busted nothing yet again.

PERFORM 10 TIMES was significantly slower than either.

So, you were wrong about that too.

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.

Maybe but your tests were incompetent and your times were meaningless.

You started out to "prove" that the advise was "bad" but failed. Just
more grandstanding Wagnerisms.


.

Relevant Pages

  • Re: Cobol Myth Busters
    ... No optimization is done on arithmetic statements if the ... ON SIZE ERROR phrase is used. ... You hit on *why* the subscript was faster. ... 01 depending-area. ...
    (comp.lang.cobol)
  • Re: Redundant match clauses (Re: Which programming language is better to start)
    ... "Will Lisp perform pattern match optimisations as ML does? ... imply certain semantics that must be maintained by a compiler. ... Which phrase are you referring to? ... compiler optimizations and pattern matching. ...
    (comp.lang.functional)
  • 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)
  • Re: Rounding timings
    ... you DID claim to "but the myth" for ROUNDED. ... ON SIZE ERROR phrase is used. ... faster to use ROUNDED than try to round the result using your own routine. ...
    (comp.lang.cobol)