Re: Is it always possible to write a COBOL program using only 1 sentence per paragrap

"Clark Morris" <cfmtech@istar.ca> wrote in message
 news:e1atd11fi2cshuqsgg11l78qp1n840102p@
4ax.com...
> On Tue, 19 Jul 2005 11:02:50 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
> 
<snip>>> 
>
> Not necessarily.

Yes, necessarily. :-)   Three factors affect online performance; two of them
are load time and capture time. The smaller  and tighter a module is, the
quicker it loads and it will be likely to require less capture time.

Capture time for a process will be improved if there is less code for the
process to execute (as long as it provides the same functionality, of
course.)

Adding code cannot possibly make it execute any faster than it is required
to. And if everything else is equal, the faster load time of a smaller
module makes overall execution quicker.  If a small module is being paged in
and out continually, as opposed to a large resident piece of code, then the
overall execution of the small module functionality may be longer, but that
implies that the large piece of code is doing more (otherwise, why is it so
large?), so the comparison is between apples and oranges

Given identical functionality and identical residence, the smaller the code
is, the quicker it will execute. Invariably.

> Some of the wild optimizations of IBM's mainframe
> COBOL include moving the code for PERFORMed paragraphs inline
> replacing the PERFORM depending on how many places the paragraph is
> PERFORMED from.  I am certain that the same exists in other compilers
> for various languages.

And how exactly does that invalidate my statement? :-) If the optimizer
expands code in line then 'less code' is not generated.

If you are thinking that page boundaries could make your statement true,
then that fails as well; shorter code is paged quicker because it occupies
fewer pages...

In modern systems 'locality of reference' is almost irrelevant, especially
when multitasking is proceeding anyway.

Think about it.

<snipped what we agree on... :-)>

Pete

In article <3k86utFl4gssU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>Given identical functionality and identical residence, the smaller the code
>is, the quicker it will execute. Invariably.

'Identical residence'?  I'm not sure what this represents, Mr Dashwood,
but I'd take exception with your assertion that 'less code = faster
execution' because it appears to ignore differences in the amount of time
it takes to execute different instructions.

I recall, years ago, talking with a Geezer who said that the first
airline reservations system he worked on used only register-to-register
(RR) instructions because they were so fast... in general they found that
rewriting other single instructions as multiple RR instructions still gave
them an overall drop in execution time (commonly known as 'faster code').
Consider the following example.

Using the IBM mainframe platform and every compiler I'm familiar with
since IKFCBL00: given:

05  FLDA PIC X.
05  FLDB PIC X.

then MOVE FLDA TO FLDB will compile to an MVI, IF FLDA = FLDB will compile
to a CLI.  Given:

05  FLDA PIC X(n).
05  FLDB PIC X(n).

... where n is an integer > 1 then MOVE FLDA TO FLDB will compile to an
MVC, IF FLDA = FLDB will compile to a CLC.

As I was taught, lo, those many years ago - and I do not know if this is
still valid for COBOL under modern conditions - an MVI executes
approximately three times faster than an MVC and a CLI thrice faster than
a CLC.  It can be readily postulated that code can be written which is
greater in volume of instructions ('larger') than other code ('smaller')
and yet will execute more rapidly due to faster constructs being employed.

DD

Pete,
Also see my other note (and this may or may not tie into your - unknown to
me - "identical residence" - term), on shared code.  For (older) IBM CICS
applications, a larger load module which kept "in storage" all same-logic-pa
th
code would often "run faster" than code that required "memory" swaps dependi
ng
upon logic flow.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:dbmtko$3a7$1@panix5.panix.com...
> In article <3k86utFl4gssU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
> 
>
> 'Identical residence'?  I'm not sure what this represents, Mr Dashwood,
> but I'd take exception with your assertion that 'less code = faster
> execution' because it appears to ignore differences in the amount of time
> it takes to execute different instructions.
>
> I recall, years ago, talking with a Geezer who said that the first
> airline reservations system he worked on used only register-to-register
> (RR) instructions because they were so fast... in general they found that
> rewriting other single instructions as multiple RR instructions still gave
> them an overall drop in execution time (commonly known as 'faster code').
> Consider the following example.
>
> Using the IBM mainframe platform and every compiler I'm familiar with
> since IKFCBL00: given:
>
>    05  FLDA PIC X.
>    05  FLDB PIC X.
>
> then MOVE FLDA TO FLDB will compile to an MVI, IF FLDA = FLDB will compile
> to a CLI.  Given:
>
>    05  FLDA PIC X(n).
>    05  FLDB PIC X(n).
>
> ... where n is an integer > 1 then MOVE FLDA TO FLDB will compile to an
> MVC, IF FLDA = FLDB will compile to a CLC.
>
> As I was taught, lo, those many years ago - and I do not know if this is
> still valid for COBOL under modern conditions - an MVI executes
> approximately three times faster than an MVC and a CLI thrice faster than
> a CLC.  It can be readily postulated that code can be written which is
> greater in volume of instructions ('larger') than other code ('smaller')
> and yet will execute more rapidly due to faster constructs being employed.
>
> DD

<docdwarf@panix.com> wrote in message news:dbmtko$3a7$1@panix5.panix.com...
> In article <3k86utFl4gssU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
> 
>
> 'Identical residence'?  I'm not sure what this represents, Mr Dashwood,
> but I'd take exception with your assertion that 'less code = faster
> execution' because it appears to ignore differences in the amount of time
> it takes to execute different instructions.
>

Might be best not to argue if you don't understand the terms... :-)

Three things govern efficiency in online environments. ( ...those are the
environments where efficiency actually matters...)

1. Queue wait time.
2. Load time.
3. Capture time.

Load time is simply dependent on module size. The smaller it is the quicker
it loads. Small is beautiful in online environments.
Capture time is not directly dependent on module size, like load time is,
but it is certainly more likely to be shorter for smaller modules than large
ones. (This is affected by OS and TP monitor architecture; timeslicing may
mean a larger module runs out of CPU time where a smaller one would have fit
the envelope; interrupt driven environments tend to encounter an interrupt
more often in large modues than they do in small ones (statistically, the
more code there is, the better chance of being interrupted and swapped...)
In either case, swapping a large module HAS to take more time than swapping
a small one...)

Bottom line: smaller modules execute faster. It is not just about
instruction architecture, and you can theorise about instruction sets and
postulate exception cases, for argument's sake, for as long as you like;
when you come to run it, it will be quicker if it is smaller... :-)

> I recall, years ago, talking with a Geezer who said that the first
> airline reservations system he worked on used only register-to-register
> (RR) instructions because they were so fast... in general they found that
> rewriting other single instructions as multiple RR instructions still gave
> them an overall drop in execution time (commonly known as 'faster code').
> Consider the following example.
>
> Using the IBM mainframe platform and every compiler I'm familiar with
> since IKFCBL00: given:
>
>    05  FLDA PIC X.
>    05  FLDB PIC X.
>
> then MOVE FLDA TO FLDB will compile to an MVI, IF FLDA = FLDB will compile
> to a CLI.  Given:
>
>    05  FLDA PIC X(n).
>    05  FLDB PIC X(n).
>
> ... where n is an integer > 1 then MOVE FLDA TO FLDB will compile to an
> MVC, IF FLDA = FLDB will compile to a CLC.
>
> As I was taught, lo, those many years ago - and I do not know if this is
> still valid for COBOL under modern conditions - an MVI executes
> approximately three times faster than an MVC and a CLI thrice faster than
> a CLC.  It can be readily postulated that code can be written which is
> greater in volume of instructions ('larger') than other code ('smaller')
> and yet will execute more rapidly due to faster constructs being employed.
>
Well it's a long time since I wrote any BAL and I don't have a green or
yellow card about the place, but from memory, I'll venture the following:

The MVI contains the data to be moved. In effect it is a move literal (that
is why it is 'immediate'). The MVC needs more information (registers and
offsets), so I would expect the instruction lengths to be different. I'm
sure someone here can confirm or deny this. So, while the MVI might well run
faster, you would need 256 of them to do the same job as a single MVC
addressing the max.

To say that an MVI executes three times faster than an MVC is silly, because
the time the MVC takes is dependent on the length of the operands. (Is it
three times faster than an MVC moving 1 byte, or an MVC moving 256 bytes?
Does it matter anyway? There are other more potent factors than instruction
architecture that will decide how quickly something gets executed (see
above). With the 'new' MVCL the limit of 256 bytes has been extended but the
overall time for the instruction  (in both cases) will be dependent on the
length being moved.

Despite your 'ready postulate' I disagree. The instructions that 'take
longer' will either be the same length or longer than the ones that are
quicker, but they will do more.

Show me an application program (on any platform) that does real work in a
real environment, where shortening it does NOT make it run faster. (Even if
you remove code that is never executed, it is STILL faster overall because
it loads quicker...)

My comments apply to real code running in the real world, not to contrived
exceptions designed for the sake of an argument. :-)

(And arguing it with you has not changed my mind :-))

Pete.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:hpDDe.503013$3V6.105715@fe04.news.easynews.com...
> Pete,
>  Also see my other note (and this may or may not tie into your - unknown
> to me - "identical residence" - term), on shared code.  For (older) IBM
> CICS applications, a larger load module which kept "in storage" all
> same-logic-path code would often "run faster" than code that required
> "memory" swaps depending upon logic flow.
>
Yes, I recognised that in my discourse :-)  Identical residence means what
it says. :-)

Pete.
<snip>>

In article <3k9fpeFtilonU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>(And arguing it with you has not changed my mind :-))

It seems, however, that code someone else posted did... sometimes a
different method is needed, that is all.

DD

<docdwarf@panix.com> wrote in message news:dboqvi$64$1@panix5.panix.com...
> In article <3k9fpeFtilonU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
> 
>
> It seems, however, that code someone else posted did... sometimes a
> different method is needed, that is all.

I guess so :-) But it is still fun to argue (in the classical sense) stuff
with people capable of doing so... :-)

I always enjoy your posts, Doc.

Pete.

In article <3kauckFtf29sU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:dboqvi$64$1@panix5.panix.com... 
>
>I guess so :-) But it is still fun to argue (in the classical sense) stuff
>with people capable of doing so... :-)

I agree... when you find such people would you be so kind as to introduce
me to them?  I think I'd be able to learn much!

>
>I always enjoy your posts, Doc.

Shucks... you'se jes' easily amused.

DD