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

"tim" <TimJ@[EMAIL PROTECTED]
> wrote in message 
news:13u1v4dt59i28b6@[EMAIL PROTECTED]
> 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.
>

I am very well aware of all of that.

> Above a fairly small size it is the total amount of data being moved
that
> dominates the time, not the number of instructions executed.

I'm aware of that, too. The point is that I don't care about the "time" 
because it is small, even for a "large" table.

If it took more than 20 seconds, I'd probably look at another approach.

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

"slow" is relative; so is "small"...

I don't diasagree with your statement but the point you are missing is
that 
this happens ONCE, at initialization, it happens in memory, is overlapped 
with fetching the values (which takes many times longer), and the time is 
therefore three fifths of five eighths of **** all (or three eighths of
**** 
all, if you want to be pedantic :-))

Pete.
-- 
"I used to write COBOL...now I can do anything."