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

On Thu, 13 Mar 2008 22:40:09 -0700 (PDT), Richard <riplin@[EMAIL PROTECTED]
>
wrote:

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

I stand corrected. 

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

Speculating what might have happened is not a convincing way to present
evidence. 

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

A tester (experimenter) would measure the speed. A programmer
(theoritician) would figure
it out with logic. As a programmer, I ask why WOULD it be slower? A
reference to a
subscripted element has no reason to reference the DO item, only a
reference to a group
name does. It gets the size from the DO item and multiplies by the reach
of an occurrance.
That's two instructions. The alternative is to load the length from a
literal. Time for
the extra instruction is small compared to the time to execute the move. 

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

Complex keys is babbling. A SEARCH ALL looks for one key, with an equal
comparison.

The difference is not one or two chops (minimizing), it is a 10% reduction
in search time.
If you didn't care about speed, you wouldn't be using SEARCH ALL in the
first place, you'd
be using a serial SEARCH .. or be querying a file or database.

>> 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).

We're talking about table searches, yet your test did not measure the
speed of table
searches. 

Do this:

Define a table with 1,000 entries.
Initialize it to high-values.
Populate 500 entries with data that's in sequence. 
Get the key of entry (250). 
Do a million SEARCH ALLs on that middle key without ODO. 
Do a million SEARCH ALLs on that middle key with ODO. 
Re****t the time of the first populate and million searches versus the
second.
I predict the second will be 10% faster.