Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx>
- Date: Thu, 21 Jul 2005 23:38:17 +1200
<docdwarf@xxxxxxxxx> wrote in message news:dbmtko$3a7$1@xxxxxxxxxxxxxxxxxxx
> In article <3k86utFl4gssU1@xxxxxxxxxxxxxx>,
> Pete Dashwood <dashwood@xxxxxxxxxxxxxx> 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.
>
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.
.
- Follow-Ups:
- References:
- Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- From: Oliver Wong
- Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- From: Pete Dashwood
- Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- From: Clark Morris
- Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- From: Pete Dashwood
- Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- From: docdwarf
- Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- Prev by Date: Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- Next by Date: Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- Previous by thread: Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- Next by thread: Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
- Index(es):
Relevant Pages
|
