Re: J4 - presentation/discussion on "Future of the COBOL Standard"

On Mar 14, 6:37 pm, Robert <n...@[EMAIL PROTECTED]
> wrote:
> On Thu, 13 Mar 2008 13:13:56 -0700 (PDT), Richard <rip...@[EMAIL PROTECTED]
>
wrote:
> >On Mar 14, 8:41 am, Richard <rip...@[EMAIL PROTECTED]
> wrote:
>
> >> No, I am not assuming anything.  I tested Fujitsu (no bound checks,
no
> >> DO changing) loading a table compared to a fixed size and found the
> >> ODO was consistently slower, granted by just 1%. It is obviously
using
> >> a different instruction sequence somewhere.
>
> >Further to that the test was doing just one MOVE in each iteration of
> >stepping through the table.  This meant that most of the time in the
> >tests was exactly the same set of PERFORM loops.
>
> False. I subtracted the PERFORM overhead. My test compared MOVE of an
ODO item to MOVE of
> an identical item without ODO.

Try reading the message again, Robert. The 'further to ..' clearly
indicates that I am talking about _my_ test.

> >By changing it to
> >several MOVEs in each iteration I got a consistent 8% difference:
>
> >+00003910   ODO
> >+00003654   fixed occurs
>
> >Thus my actual tests _PROVE_, for the Fujitsu COBOL that I use, that
> >the MF claim of "access is less efficient" is TRUE.
>
> I'd have to see the code. On a guess, it sounds like the Fujitsu
optimizer found a way to
> optimize the 2nd and 3rd move on fixed that it did not apply to the
corresponding moves on
> ODO. If so, that proves ODO less efficient on consecutive moves.

I still had a 1% difference when it was one move buried in all the
PERFORMs, which I didn't bother to subtract. Perhaps I'll find 20%
difference if I did.


> It is easy to picture that happening, because the optimizer thinks the
1st or 2nd move
> might have changed either the subscript or the DO item, so it recomputes
the subscript for
> each move.

You are mere speculating again. It may also be that "access is less
efficient" as MF and HP claims.


> >Not that 'SEARCH ALL saving an iteration or two' is not inconsistent
> >with 'access is less efficient'.
>
> I don't recall posting test results for SEARCH ALL.

No, your claim was based simply on the number of chops being reduced.
It may well be that for complex keys the inefficiency of the of
accesses to compare the keys may be such that the saving of one or two
chops is less than the cost of the slow access.

> >Robert's beliefs (and narrow view), in this case that "ODO is not
> >slow" is once again shown to be WRONG.
>
> It would be much easier to construct cases where ODO is faster. For
instance, moving a 30
> byte word containing 10 bytes of data and 20 spaces. That's a typical
and realistic use of
> ODO.

Only if it _is_ actuallu faster.


> The proposition I tested was that subscript evaluation is slower for
ODO.

This was what you claimed was false:

"""The Micro Focus Server Express performance tips manual says it is
slower; an IBM manual you linked to says the same."""

and:

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

My tests show, for the compiler that I used, that these are true (and
thus your claim is wrong).