Cobol: Structured vs. "Drop-Down" Performance 
Author Message
 Cobol: Structured vs. "Drop-Down" Performance

Without getting into a major philosophical debate on the use of "goto"
vs. structured programming, can someone just quantify for me the
(possible) PERFORMANCE difference between the two methodologies?

I understand (and read the threads) on the code maintenance issues of
(so-called) structured programming vs. (so-called) un-structured
programming.

Please assume that maintenance is not an issue (which of course it
really is), and that I am solely concerned with raw performance.
Here's why: The legacy of Cobol coding at the company where I work has
been that "drop down" programming is faster than structured
programming (i.e. using "perform" to execute modular paragraphs).

In other words, logic starts at the beginning of the procedure
division and just goes straight down, with an occasional goto loop or
inline perform until it gets to the end.  In practical terms you can't
entirely get rid of some procedures, so resulting program generally
ends up something like this:

Procedure Division
- Initialization Logic (in-line)
- XXX-Main-Loop
- Read Next Record
      AT END GO TO Termination-Logic
- Main Logic Body (in-line)
- GO TO XXX-Main-Loop
- Support Paragraphs
- Termination-Logic (in-line)

I recently re-wrote in structured format a program like the above.
Over time it had simply become an un-maintainable abomination.

My boss and a co-worker insist however, that the new program simply
must be suffering from a performance hit as a result.  My boss is not
concerned with maintenance; these are programs used for conversions,
so he considers them one-time programs.  (Major changes are still done
for new conversions, however, hence my re-write)

So, down on the bare metal, performance-wise:

A "PERFORM" causes registers to be pushed onto a stack, a jump
instruction to be executed, registers to be popped from a stack, and a
return jump instruction to be executed on each iteration (at the very
least).  But, an optimizing compiler can optimize the code because it
can "see" what the code is doing, no?

A Microfocus document that came with their (old) 2.5.39 compiler even
stated:

"Put commonly used pieces of code in sections or paragraphs and
PERFORM them. This is saves space for any statement used more than
once that produces more than 4 bytes of generated code (in a NOTRICKLE
program).  It is often beneficial even on single statements, for
example edited moves, subprogram calls or file I/O."

Does this still apply?  No equivalent document in later versions.

A "GO TO" does not push/pop a stack.  It does, of course, execute
going and returning jump instructions.  However, can a compiler
optimize code with 'goto's?  (Of course, effect depends on how many or
few there are)

What is the effect of either method on the "fetch-decode-execute" flow
and processor cache loading of a modern micro-processor?  It was my
understanding that "goto"s break the flow and cause the processor to
have to flush (some part of) the instruction cache in order to start
reading at the new location where the goto's going, thus wasting the
read-ahead load of the instruction cache.

How does an optimizing compiler (e.g. Microfocus if it can be termed
that) handle a "perform" in this sense?

Obviously I'm not an expert in this area.  Any and all comments and
suggestions will be greatly appreciated!

Thank you much!

Kevin Arthur



Wed, 19 May 2004 11:11:46 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Just replying to one bit of your post:

Quote:

> What is the effect of either method on the "fetch-decode-execute" flow
> and processor cache loading of a modern micro-processor?  It was my
> understanding that "goto"s break the flow and cause the processor to
> have to flush (some part of) the instruction cache in order to start
> reading at the new location where the goto's going, thus wasting the
> read-ahead load of the instruction cache.

So does any other instruction that breaks the program flow  If you perform
some paragraph that's way off in the other end of the program, it is
highly unlikely that it'll be in the cache.  Or if you're in a big perform
loop, you may well incur the same penalty when you go from the bottom to
the top of the perform.  (Depends on the size of the cache, of course, and
how many programs are executing concurrently).  Whether or not goto's are
explicitly used in the source, the object code has to use them, so the
point is moot.

PL



Wed, 19 May 2004 13:10:11 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

> Without getting into a major philosophical debate on the use of "goto"
> vs. structured programming, can someone just quantify for me the
> (possible) PERFORMANCE difference between the two methodologies?

> I understand (and read the threads) on the code maintenance issues of
> (so-called) structured programming vs. (so-called) un-structured
> programming.

> Please assume that maintenance is not an issue (which of course it
> really is), and that I am solely concerned with raw performance.
> Here's why: The legacy of Cobol coding at the company where I work has
> been that "drop down" programming is faster than structured
> programming (i.e. using "perform" to execute modular paragraphs).

> In other words, logic starts at the beginning of the procedure
> division and just goes straight down, with an occasional goto loop or
> inline perform until it gets to the end.  In practical terms you can't
> entirely get rid of some procedures, so resulting program generally
> ends up something like this:

> Procedure Division
> - Initialization Logic (in-line)
> - XXX-Main-Loop
> - Read Next Record
>       AT END GO TO Termination-Logic
> - Main Logic Body (in-line)
> - GO TO XXX-Main-Loop
> - Support Paragraphs
> - Termination-Logic (in-line)

> I recently re-wrote in structured format a program like the above.
> Over time it had simply become an un-maintainable abomination.

> My boss and a co-worker insist however, that the new program simply
> must be suffering from a performance hit as a result.  My boss is not
> concerned with maintenance; these are programs used for conversions,
> so he considers them one-time programs.  (Major changes are still done
> for new conversions, however, hence my re-write)

*****
Who sez. ? Just a gut feeling - if so, not good enough. Are they measuring
elapsed time between different versions of the same program.
*****

- Show quoted text -

Quote:

> So, down on the bare metal, performance-wise:

> A "PERFORM" causes registers to be pushed onto a stack, a jump
> instruction to be executed, registers to be popped from a stack, and a
> return jump instruction to be executed on each iteration (at the very
> least).  But, an optimizing compiler can optimize the code because it
> can "see" what the code is doing, no?

> A Microfocus document that came with their (old) 2.5.39 compiler even
> stated:

> "Put commonly used pieces of code in sections or paragraphs and
> PERFORM them. This is saves space for any statement used more than
> once that produces more than 4 bytes of generated code (in a NOTRICKLE
> program).  It is often beneficial even on single statements, for
> example edited moves, subprogram calls or file I/O."

> Does this still apply?  No equivalent document in later versions.

> A "GO TO" does not push/pop a stack.  It does, of course, execute
> going and returning jump instructions.  However, can a compiler
> optimize code with 'goto's?  (Of course, effect depends on how many or
> few there are)

> What is the effect of either method on the "fetch-decode-execute" flow
> and processor cache loading of a modern micro-processor?  It was my
> understanding that "goto"s break the flow and cause the processor to
> have to flush (some part of) the instruction cache in order to start
> reading at the new location where the goto's going, thus wasting the
> read-ahead load of the instruction cache.

> How does an optimizing compiler (e.g. Microfocus if it can be termed
> that) handle a "perform" in this sense?

> Obviously I'm not an expert in this area.  Any and all comments and
> suggestions will be greatly appreciated!

> Thank you much!

> Kevin Arthur

Oh my Gawd ! There should be a law banning people like you., (i.e. DARING
to mention yet again the wretched GO TO). It appears to me that your
co-workers have got entrenched into a particular style - and no way Jose,
do they want to give up on that.

The simple answer is BS to the performance - Maintenance, (i.e., clarity
of the coding and segregation into meaningful paragraphs) should be the
first criteria and performance will flow from that. Maintenance wise even
one-time programs can go wrong, or even worse, they finish up as a regular
feature program. I know, I've been there ! Given the ever increasing
speed  of computers, why worry about the odd nano-seconds. (20 years ago
on a Radio Shack a one program COBOL compile could absorb 30 minutes, now
we are down to seconds - and the seconds I'm talking about are Micro
Focus).

Mainframe wise, agreed there will be instances where a program handling
considerably large volumes should be tweaked for performance, but as a
generalization for peace of mind, consider maintenance first.

Consider other aspects of performance, like IFs or EVALUATES - strictly
speaking, we should follow Pareto (20% of conditions account for 80% of
the action), so we should arrange the tests in descending value - but how
many of us actually do that - we think Red, White and Blue and rarely does
it occur to us to arrange the code to test Blue first, because that gets
the most hits in a given situation.

Even, as in your example where you start at the top, your mainline can
still be a set of PERFORMS - and to keep your boss and co-worker happy,
list those PERFORMS in a downwards sequence <G>

Jimmy



Wed, 19 May 2004 13:41:41 GMT  
 Cobol: Structured vs. "Drop-Down" Performance
I did tuning work on mainframe COBOL programs for years and never found an
instance where performs made a discernable difference. The instructions per
straight perform are about 4. A typical move will burn up 5-15. It is a
non-issue unless you are really in the very inner CPU intensive loop. In such
a case you probably have to recode in assembler to get worthwhile
improvements in my experience.

The slowest instruction these days is IF, because it causes pipeline breaks.
And CALL. CALL seems to burn up 120-150 instructions and can really hurt you
if overused. Especially dynamic calls. And there are extra instructions per
argument.

If a perform is a hidden IF, it will cost like an IF eg

PERFORM x-para until flag-y.

The 'until' is like an IF.

You have to look at the circumstances. Computer history is full of people
spending $100,000's to save $1 worth of CPU time. How often is the
job/transaction run? How much CPU does it use? At 5c per CPU second, does
anyone care? Sometimes someone does. We had a table access routine that was
called 5,000,000,000 times per night during the critical batch window. That
justified assembler code built on the fly to eliminate pipeline breaks and
keep it all in cache.

Tim Josling

Quote:


> > Without getting into a major philosophical debate on the use of "goto"
> > vs. structured programming, can someone just quantify for me the
> > (possible) PERFORMANCE difference between the two methodologies?

> > Kevin Arthur



Wed, 19 May 2004 14:53:05 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

> (snip)
> A "PERFORM" causes registers to be pushed onto a stack, a jump
> instruction to be executed, registers to be popped from a stack, and a
> return jump instruction to be executed on each iteration (at the very
> least).  But, an optimizing compiler can optimize the code because it
> can "see" what the code is doing, no?

This is not true for IBM mainframe COBOL.  First of all, the system
has no hardware stack, although it is true that registers may need to
be saved for subroutine calls, and certainly for program CALL's.

Secondly, IBM's COBOL optimizer will move performed code in-line when
it perceives that it will result in a performance improvement.  So the
code you PERFORM may not be located away from the mainline.

Using GO TO does not automatically result in a faster running
program.  Using PERFORM does not automatically result in a slower
running program.  Tim Josling points out that IF and CALL are the most
expensive instuctions.  How can you improve those by using GO TO?

The typical causes of poor runtime performance are bad I/O planning
and poor algorithm design.  You might find some useful tips on
improving COBOL performance here:
http://home.att.net/~arnold.trembley/cob-rte.htm

--
http://arnold.trembley.home.att.net/



Wed, 19 May 2004 18:10:32 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:
> Without getting into a major philosophical debate on the use of "goto"
> vs. structured programming, can someone just quantify for me the
> (possible) PERFORMANCE difference between the two methodologies?

IMNSHO, and without quantification, any performance impact is moot.

MCM



Thu, 20 May 2004 01:19:32 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

> The typical causes of poor runtime performance are bad I/O planning
> and poor algorithm design.  

In the 1970s I worked in Calgary with a man who would bet that he could double
performance touching nothing but JCL.  He rarely lost the bet.

--
Ed Guy P.Eng,CDP,MIEE
Information Technology Consultant

http://www.guysoftware.com
"Check out HELLLP!, WinHelp author tool for WinWord 2.0 through 2000,
 PlanBee Project Management Planning and Scheduling
 and ParseRat, the File Parser, Converter and Reorganizer"



Thu, 20 May 2004 02:00:24 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

> Without getting into a major philosophical debate on the use of "goto"
> vs. structured programming, can someone just quantify for me the
> (possible) PERFORMANCE difference between the two methodologies?

This was argued about 30 years ago when CPU performance and memory
limitations actually mattered.  The result was that there was no real
difference in performance, even then.

Quote:
> Here's why: The legacy of Cobol coding at the company where I work has
> been that "drop down" programming is faster than structured
> programming (i.e. using "perform" to execute modular paragraphs).

Obviously they learnt something 30 years ago and have had their minds
clamped shut ever since (eg they became managers).

Quote:
> I recently re-wrote in structured format a program like the above.
> Over time it had simply become an un-maintainable abomination.

Exactly.  Not only that but there is usually no way that an unstructured
mess can be analysed for performance issues and improved.

Quote:
> My boss and a co-worker insist however, that the new program simply
> must be suffering from a performance hit as a result.  

Your boss learnt something 30 years ago and since then has had his mind
clamped shut by becoming a manager.  The lackey co-worker knows which
side bread is buttered.

Quote:
> My boss is not
> concerned with maintenance; these are programs used for conversions,
> so he considers them one-time programs.  (Major changes are still done
> for new conversions, however, hence my re-write)

Why would _anyone_ care about performance of a one-off conversion ?  The
_only_ issue is that it run correctly first time.  Having to rerun it
once because it wasn't perfect will negate any trivial 'performance
issues' in a thousand runs.

Quote:
> So, down on the bare metal, performance-wise:

If it is a conversion program, or indeed anything that has file I/O,
then CPU performance is irrelevant to the program run-time, the program
will be spending 99% of the time waiting for data transfers.  In any
computer built in the last quarter century (except possibly the
Commodore 64), the I/O will be overlapped with the CPU using disk
caching or buffering and so the CPU run-time of the program is not even
additive to the file I/O time.

Arguing about GO TO vs PERFORM as a performance issue is a complete
waste of time anyway - it is the algorithms that are important.

The slackest coded quick-sort in interpreted Basic will outperform the
best hand coded assembler bubble sort (given appropriate data).  The
best way to reduce run time is to code so it works first time, every
time.  Small easily understood, separately testable modules, performed
from higher level logic will be more likely to do this (for you).



Thu, 20 May 2004 18:20:29 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

>Why would _anyone_ care about performance of a one-off conversion ?  The
>_only_ issue is that it run correctly first time.  Having to rerun it
>once because it wasn't perfect will negate any trivial 'performance
>issues' in a thousand runs.

Performance in a one-of conversion is still important when the
base program is used as a shell for every future conversion process
on other files of similar format.
Performance is performance.  Not many people are happy to wait around
all day for a million record extract/conversion/build process to complete.
Most other post conversion processes are dependent upon verification
that the converted files balance and are accurate before stepping forward
with the new production files.


Thu, 20 May 2004 08:31:06 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:



> >Why would _anyone_ care about performance of a one-off conversion ?  The
> >_only_ issue is that it run correctly first time.  Having to rerun it
> >once because it wasn't perfect will negate any trivial 'performance
> >issues' in a thousand runs.

> Performance in a one-of conversion is still important when the
> base program is used as a shell for every future conversion process
> on other files of similar format.
> Performance is performance.  Not many people are happy to wait around
> all day for a million record extract/conversion/build process to complete.

You'll still be I/O bound in a big conversion, since there is no way that the incoming
data will be cached.  You can do a hell of a lot of crunching while the next record is
being fetched.

--
Ed Guy P.Eng,CDP,MIEE
Information Technology Consultant

http://www.guysoftware.com
"Check out HELLLP!, WinHelp author tool for WinWord 2.0 through 2000,
 PlanBee Project Management Planning and Scheduling
 and ParseRat, the File Parser, Converter and Reorganizer"



Thu, 20 May 2004 23:13:17 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

> Without getting into a major philosophical debate on the use of "goto"
> vs. structured programming, can someone just quantify for me the
> (possible) PERFORMANCE difference between the two methodologies?

[Any one who posts an answer to this, don't do it in an
"interpreted" code gen fashion. Read the full argument
before injecting answers that are meaningless once you get
to the end of the whole answer.]

We must start with a little history and memory theory, so
let's begin with the S/370 machines.

The performance difference is not about cache misses
(although that is a detriment to performance). The problem
is one of locality of reference with regards to Virtual
Storage (VS). So, the bigger the program, the more likely
that code you need to execute is paged out of the system (PC
or Mainframe, you still get swap/trim). It makes no
difference on GOTO or PERFORM with what I'm discussing. And,
we are not going to take into consideration the DATA
DIVISION part of a program as we will assume it would be the
same size regardless of coding style (fall through v.
structured).

That said, let us look at reality. S/370 up to 1990, central
storage was expensive (it was getting progressively
cheaper). Mainframes using VS made 4MB appear to be 16MB
(VSE & VS1 for the whole memory scheme, while MVS did this
per address space). Therefore, at the slower machine speeds
than we have now, a COBOL program would exist partly in a
page data set rather than all of it in memory (assuming a
moderately or greater loaded machine). The perform logic
could not be optimized completely to negate this, so CICS
programmers (We are going back to 1.5 and earlier) generally
found that fall through logic was the fastest. Please
remember that I/O xfer at that point was at best 3MB/sec for
any DASD I/O.

The locality of reference problem here was that, even though
the DAT Buffers (i.e., Dynamic Address Translation
Tables/Cache store) were loaded with all the addresses for
all pages of your program, the moment you lost the dispatch
slice, a new locality of reference took place. NOTICE:
Locality of reference here is with regards to page
boundaries. The next time your program gets executed, DAT
had to rebuild its cache (even though the segment and page
tables were still pointing to page frames and not DASD).
This is a time consuming thing which causes your dispatch
slice to spend time recovering. Now let us make this worse
and assume that you did not get dispatched again until after
two memory cleanup cycles (I'm sorry, I've forgotten what
this is called in S/370-z/Architecture terms). This then
causes page trim (your pages haven't been touched for x
seconds, so they get scheduled to a page data set).
Therefore, a fall through program would perform better than
a program with performs of paragraphs that are on/in
different pages.

Now we have a new locality of reference problem. Every time
we attempt to resolve a Virtual Address, we find that the
page table entry is "invalid" and so we have to schedule a
page to be brought back into storage. While this is going
on, you have lost your dispatch cycle. Now do you see why a
structured program that did not use GOTO would cause CICS
some serious performance hits? If you don't, I can continue
with this and show you how a program that is large enough to
take over 12 page frames can cause a CICS region (or any
other for that matter) to cause something called thrashing.
Particularly if it is written top down structured with
performs all over the place.

That was YESTERDAY's problems. We need to look at TODAY and
the machines we have TODAY.

Today you can't find a mainframe with less than 64MB of
C-Store (RAM to the rest of you). So the VS locality of
reference problems gets more focus on the cache misses. GOTO
or GOTO-less programming will generally suffer the same.
[There are some problems where a COBOL program written in a
fall through fashion will see certain performance boots, but
there aren't that many that are worth the attendant
headaches.]

Now let us add the idea of cached DASD controllers and
faster I/O channels and you negate some of the VS
performance issues.

Next take a machine and give it more than 128MB of RAM
(C-Store for the mainframe folks) and the paging issues
actually become moot (especially when you consider E-store).
Add to this the data xfer rates that are now above 16MB/sec
and reduced latency, etc. etc. and paging is much much
faster (assuming you even have a paging problem). And the
advent of larger DAT Buffers (which was promoted by MDF and
now PR/SM).

Now let look back to about 1995 and mainframes with 2GB
C-store and 2GB E-store. Your program is how large compared
to everything else that is running? The processor speed is
what compared to a S370/168MP?

About 1998 we have mainframes with over 300MIPS, PCs with
greater than 500MHz clocks and most machines with more RAM
than good sense (OK, micros**t platforms do suffer from
serious code bloat).

At this point in time, one is much better off to write any
program for maintainability than for raw CPU speed
(exception, the kind of code that I sometimes get to write
-- SVCs & PC routines that become part of the O/S, but then
I do this in ALC). With optimization done by the compiler
and memory management that has been greatly enhanced within
OS/390 (I won't even speak to micros**t in this area),
structured programming only makes sense today (this from a
die hard GOTO user).

--
Steve Thompson
OSP Consulting
330/335-9907 office



Thu, 20 May 2004 23:53:05 GMT  
 Cobol: Structured vs. "Drop-Down" Performance
Good exposition there, Steve.

It took me back... to the days when Virtual storage was invented.

As a young programmer imbued with zeal and idealism I made it my business to
completely understand as much as possible about the system side of 360 (and
, later, of course, 370)

When the first VS OSes appeared many of us were just dismayed...let me
explain why.

Computer Programming in those days was an art...There were 2 primary
constraints:

1. Space.

Ths was expensive and limited (as you described). The idea of "paging" code,
even with a very fast (ha, ha!) drum device was anathema. Overlaying was
something we did very carefully and organised our "segment limits" (old
COBOL) with great regard to the processing flow of our programs. How could
the system software possibly do as good a job as we did?

2. Time.

Even the fastest processors available were slower than a PC-AT. I remember
when I first found out that core storage took 1.5 microseconds to access (on
a 360-30 in 1966) how impressed I was and how long it took to get my head
round the fact that disk IO was thousands of time slower. Today the memory
in the Notebook I am writing this on is around 2000 times faster than
that...

The "art" was in balancing the two constraints. You couldn't teach it like a
science. It required imagination and sensitivity and skill and judgement.

If you gave a program more "space" (took more memory) it usually ran faster.
Just like today, we were always trying to get things to run as quickly as
possible, so we spent many hours optimising our code within the available
constraints. (No optimizing compilers to do it for us; "good" COBOL
programmers understood the Assembler code generated and experimented with
ways to get the compiler to generate better code...organise WS to avoid data
conversion, use MVI instructions to set flags and CLC to test them because
it was cheaper than arithmetic, and all that stuff (to this day my flags are
always "pic x", on ANY platform...<G>). I was very interested to see exactly
 this kind of exchange being posted here in CLC under the "unsigned packed
numeric" topic...It is good to see that there are still people around who
care about this stuff...<G>)

But, as with most things, there was a necessity to "dumb it down". So they
invented Virtual Storage which removed the space constraint (well, it did in
theory...<G>) and the natural evolution of technology took care of providing
more power. No need for "art" any more, just teach the language and let them
loose... the system will cope with the inefficiency.

As you can imagine, those of us who took our work seriously (the intensity
of the young is kind of frightening, isn't it <G>) were totally dismayed by
this new proud release from IBM. We fought a tooth and nail rearguard action
to discredit the new technology (doesn't that sound familiar?...nothing
really changes <G>).

The first thing was to understand how it worked and then write programs that
would give it a real hard time...

A couple of us revamped a certain production suite to ensure that the
locality of reference which Steve described was as inefficient as
possible... The run time went from 14 minutes to over an hour. Much wailing
and gnashing of teeth from Management and we just looked smug and said
"Well, that's the new IBM technology you insist on buying..." Of course we
couldn't get away with it indefinitely, and I later made quite a lot of
money optimising systems that were suffering due to improper use of locality
of reference (and bad I/O)... Make the Poacher a Gamekeeper <G>...Today, I
understand that the optimizing compilers do all this for you... I have mixed
feelings about that.

Thanks for the post Steven.

Brought back some happy memories of working at the coalface with other
"miners" who were characters... I guess today the coalface has moved and the
challenge is in better application understanding, but there is still a small
place for the kind of skills we acquired then.

I have deliberately refrained from entering the "structured" vs "drop down"
debate because I believe it is pointless. It is pointless for the reasons
you explained. Today's systems will handle either model with many times the
efficiency that was available in the middle decades of the last century.

So the primary concern HAS to be maintainability of code.

(That's one reason why I use OO...<G>)

I believe this thread started because the original poster was faced with
Management stuck in the 70s.

My advice: Don't worry about it.

It is their money, let them call the shots. You've explained your case and
given it your best shot. Respect their right to be wrong. During the course
of your IT career you will encounter MANY cases where Management get it
wrong.

Deal with it.

As long as you are taking their money, give them the best advice you can,
but don't lose sleep over it...

It is only computer programming  <G>.

Pete.


Quote:

> > Without getting into a major philosophical debate on the use of "goto"
> > vs. structured programming, can someone just quantify for me the
> > (possible) PERFORMANCE difference between the two methodologies?

> [Any one who posts an answer to this, don't do it in an
> "interpreted" code gen fashion. Read the full argument
> before injecting answers that are meaningless once you get
> to the end of the whole answer.]

> We must start with a little history and memory theory, so
> let's begin with the S/370 machines.

> The performance difference is not about cache misses
> (although that is a detriment to performance). The problem
> is one of locality of reference with regards to Virtual
> Storage (VS). So, the bigger the program, the more likely
> that code you need to execute is paged out of the system (PC
> or Mainframe, you still get swap/trim). It makes no
> difference on GOTO or PERFORM with what I'm discussing. And,
> we are not going to take into consideration the DATA
> DIVISION part of a program as we will assume it would be the
> same size regardless of coding style (fall through v.
> structured).

> That said, let us look at reality. S/370 up to 1990, central
> storage was expensive (it was getting progressively
> cheaper). Mainframes using VS made 4MB appear to be 16MB
> (VSE & VS1 for the whole memory scheme, while MVS did this
> per address space). Therefore, at the slower machine speeds
> than we have now, a COBOL program would exist partly in a
> page data set rather than all of it in memory (assuming a
> moderately or greater loaded machine). The perform logic
> could not be optimized completely to negate this, so CICS
> programmers (We are going back to 1.5 and earlier) generally
> found that fall through logic was the fastest. Please
> remember that I/O xfer at that point was at best 3MB/sec for
> any DASD I/O.

> The locality of reference problem here was that, even though
> the DAT Buffers (i.e., Dynamic Address Translation
> Tables/Cache store) were loaded with all the addresses for
> all pages of your program, the moment you lost the dispatch
> slice, a new locality of reference took place. NOTICE:
> Locality of reference here is with regards to page
> boundaries. The next time your program gets executed, DAT
> had to rebuild its cache (even though the segment and page
> tables were still pointing to page frames and not DASD).
> This is a time consuming thing which causes your dispatch
> slice to spend time recovering. Now let us make this worse
> and assume that you did not get dispatched again until after
> two memory cleanup cycles (I'm sorry, I've forgotten what
> this is called in S/370-z/Architecture terms). This then
> causes page trim (your pages haven't been touched for x
> seconds, so they get scheduled to a page data set).
> Therefore, a fall through program would perform better than
> a program with performs of paragraphs that are on/in
> different pages.

> Now we have a new locality of reference problem. Every time
> we attempt to resolve a Virtual Address, we find that the
> page table entry is "invalid" and so we have to schedule a
> page to be brought back into storage. While this is going
> on, you have lost your dispatch cycle. Now do you see why a
> structured program that did not use GOTO would cause CICS
> some serious performance hits? If you don't, I can continue
> with this and show you how a program that is large enough to
> take over 12 page frames can cause a CICS region (or any
> other for that matter) to cause something called thrashing.
> Particularly if it is written top down structured with
> performs all over the place.

> That was YESTERDAY's problems. We need to look at TODAY and
> the machines we have TODAY.

> Today you can't find a mainframe with less than 64MB of
> C-Store (RAM to the rest of you). So the VS locality of
> reference problems gets more focus on the cache misses. GOTO
> or GOTO-less programming will generally suffer the same.
> [There are some problems where a COBOL program written in a
> fall through fashion will see certain performance boots, but
> there aren't that many that are worth the attendant
> headaches.]

> Now let us add the idea of cached DASD controllers and
> faster I/O channels and you negate some of the VS
> performance issues.

> Next take a machine and give it more than 128MB of RAM
> (C-Store for the mainframe folks) and the paging issues
> actually become moot (especially when you consider E-store).
> Add to this the data xfer rates that are now above 16MB/sec
> and reduced latency, etc. etc. and paging is much much
> faster (assuming you even have a paging problem). And the
> advent of larger DAT Buffers (which was promoted by MDF and
> now PR/SM).

> Now let look back to about 1995 and mainframes with 2GB
> C-store and 2GB E-store. Your program is how large compared
> to everything else that is running? The processor speed is
> what compared to a

...

read more »



Fri, 21 May 2004 07:45:57 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

>You'll still be I/O bound in a big conversion, since there is no way that the
>incoming
>data will be cached.  You can do a hell of a lot of crunching while the next
>record is
>being fetched.

I am not sure what you mean by I/O bound and cacheing.  In my experience with
sequential flat file conversion, I/O performance bottleneck can be mitigated by
proper use of blocking factors and alternate areas which in effect can grab
multiple records in a single physical access.  Your I/O delay is reduced even
further with the write-behind caching provided by the system resources.


Fri, 21 May 2004 12:04:26 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:


> >You'll still be I/O bound in a big conversion, since there is no way that the
> >incoming
> >data will be cached.  You can do a hell of a lot of crunching while the next
> >record is
> >being fetched.

> I am not sure what you mean by I/O bound and cacheing.  In my experience with
> sequential flat file conversion, I/O performance bottleneck can be mitigated by
> proper use of blocking factors and alternate areas which in effect can grab
> multiple records in a single physical access.  Your I/O delay is reduced even
> further with the write-behind caching provided by the system resources.

You can do all sorts of things to mitigate it, BUT you have to physically read it and
the CPU can be doing your crunching while the read is happening.  This is always
assuming it's a big file so that you can't grab it all in one gob, but if it was small
enough that you could, you wouldn't be concerned about performance.

--
Ed Guy P.Eng,CDP,MIEE
Information Technology Consultant

http://www.guysoftware.com
"Check out HELLLP!, WinHelp author tool for WinWord 2.0 through 2000,
 PlanBee Project Management Planning and Scheduling
 and ParseRat, the File Parser, Converter and Reorganizer"



Fri, 21 May 2004 14:38:45 GMT  
 Cobol: Structured vs. "Drop-Down" Performance

Quote:

> Good exposition there, Steve.

> It took me back... to the days when Virtual storage was invented.

> 2. Time.

> Even the fastest processors available were slower than a PC-AT. I remember
> when I first found out that core storage took 1.5 microseconds to access (on
> a 360-30 in 1966) how impressed I was and how long it took to get my head
> round the fact that disk IO was thousands of time slower. Today the memory
> in the Notebook I am writing this on is around 2000 times faster than
> that...

Yep, and the one I was working on didn't even have hardware multiply.  Really slowed
down array processing.

--
Ed Guy P.Eng,CDP,MIEE
Information Technology Consultant

http://www.guysoftware.com
"Check out HELLLP!, WinHelp author tool for WinWord 2.0 through 2000,
 PlanBee Project Management Planning and Scheduling
 and ParseRat, the File Parser, Converter and Reorganizer"



Fri, 21 May 2004 14:43:24 GMT  
 
 [ 30 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Enterprise COBOL "Performance Tuning paper"

2. VA COBOL "CALL" performance problem

3. "C" vs Cobol

4. "BIG E vs little e", was pre-condition vs post-condition

5. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

6. "Legacy Systems"--down with that term!

7. Send Program "Down for Maintenance"

8. SHUT DOWN A "WINDOW"

9. "Down with Lambda Lifting"?

10. COBOL FAQ - and the topic of "off-toic"posts in the COBOL Newsgroups

11. button gets stuck "down"

12. File Loaded Drop Box "None" Record

 

 
Powered by phpBB® Forum Software