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

On Thu, 20 Mar 2008 00:25:50 +1300, Pete Dashwood wrote:

> Four flaws, as follows:
> 
> 1. Most computers have instruction sets that move bytes quickly. (So the

> "energy" (time) required to push books down the shelf is minimal)
> 2. You have not taken into account the overheads in setting up and
utilising 
> your "gaps".
> 3. Your "gapped" solution has 1200 entries instead of 1000 so it
occupies 
> more space.
> 4. It cannot be implemented with OCCURS DEPENDING ON so you couldn't use
it 
> anyway.
> 
> On reflection, I might agree it may run faster in theory, but it is not
as 
> easy to implement in a general form,  practically, as my solution is,
and my 
> solution is WAY better than OCCURS DEPENDING ON which is what this 
> discussion is really all about.
> 
> You have failed to persuade me to change to ODO (but that was never
likely 
> to happen anyway... :-)
> 
> Pete.

On the IBM mainframe COBOL the moves probably turn into multiple MVCs (max
256 bytes per instruction) or one MVCL. The MVCL is a restartable
instruction. In effect it gets split up into multiple instructions by the
microcode/hardware.

On X86 it likely ends up as rep movs or load/store words followed by
loopX.

Above a fairly small size it is the total amount of data being moved that
dominates the time, not the number of instructions executed. The compiler
should be able to write code that is entirely constrained by memory
bandwidth. Some compilers will use the vector / SSE instructions to ensure
this is the case.

Whether you care how long it takes depends on how large the moves are and
how often they get executed. I have seen one program use several hours CPU
per day executing "move low-values to work-area". As your algorithm is
O(N**2) it will be slow for anything other than small tables.

Tim