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

On Mar 15, 2:52 pm, Robert <n...@xxxxxx> wrote:
On Thu, 13 Mar 2008 22:40:09 -0700 (PDT), Richard <rip...@xxxxxxxxxxxx> wrote:
On Mar 14, 6:37 pm, Robert <n...@xxxxxx> wrote:
On Thu, 13 Mar 2008 13:13:56 -0700 (PDT), Richard <rip...@xxxxxxxxxxxx> wrote:
On Mar 14, 8:41 am, Richard <rip...@xxxxxxxxxxxx> 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.


I was extrapolating from the _actual_ results that I had obtained by
testing, which at least is a vastly better than your untested
assumptions that it would not be 'less efficient'.

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.


Perhaps your 'logic' fails you because you don't have access to the
same information that Micro Focus and others had when they wrote the
compiler and stated that 'access is less efficient'.


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.


No. Wrong. An OCCURS clause can specify several keys, both ASCENDING
and DESCENDING. The WHEN allows multiple AND clauses, each of which is
an 'equals'.


The difference is not one or two chops (minimizing), it is a 10% reduction in search time.

The reduction for a single SEARCH ALL can only be an integral number
of chops: zero, 1, 2, or so. If the DO makes the table half the total
size or less than you will on average save one chop.

Whether there is _any_ saving at all depends on how much 'less
efficient' the access actually is (now that I have show that it is
actually less so, at least on my tests).

If the 'less efficient' is 10% and the 'saving' is 10% then the SEARCH
ALL will not be improved at all.

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.


If you really cared about high speed you would use a hash table, which
potentially can be _much_ faster. Of course this may depend on
suitable keys or sufficiently low packing density.

Or one could implement a binary tree in a table. A tree could be
optimised based on some history of previous usage so that high hit
rates are in early nodes.


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

That would give a single chop, real good sample testing.

Do a million SEARCH ALLs on that middle key without ODO.
Do a million SEARCH ALLs on that middle key with ODO.
Report the time of the first populate and million searches versus the second.
I predict the second will be 10% faster.

.

Relevant Pages