Tom Ross's Share presentation on COBOL performance is excellent.
Scott ford www.identityforge.com On Jul 14, 2012, at 12:34 PM, Chris Mason <chrisma...@belgacom.net> wrote: > John > >> Integer arithmetic should never be done with anything but binary integers. > > "What never?" > > One excuse might be when the only arithmetic to be performed is to add up "a > column" of numbers and present the result. Converting to packed decimal, > adding using the packed decimal instruction and then converting the total to > the printable form might be an example of where staying with packed decimal > is the more efficient. > > "Well, hardly ever!" > > - > > To all following this topic > > Even before John Gilmore's assertion, I had in mind to tell a story > concerning the relative efficiency of packed decimal. > > Forty years ago in the north-west of England, an IBM salesman was faced with > losing one of his customers. Competition had muscled in and proposed a > machine potentially more suited to the demands made on the customer's > business - and their pocket. The salesman's response was to propose replacing > the 360/30 with a 360/25 which I believe had only recently - at the time - > been added to the 360 range, extending it "downwards" - ignoring - > *obviously* - the 360/20! > > The customer - or perhaps the competition - proposed running a benchmark and > the customer supplied both contenders with the source of an assembler program > key to their operation. > > It's important to know that the 360/30 the customer already had was literally > "basic" in that disks were not a feature of the configuration with all > storage on tape. Thus the operating system was Basic Programming System (BPS) > Tape. There was a BPS-Tape assembler compiler of course but there was no > COBOL compiler. It may have been a bit of a disappointment - maybe even a > surprise - for the competition that they were not provided with COBOL source. > > The customer was an organisation which set and evaluated examination papers > for secondary schools. The "benchmark" program had the responsibility of > sorting the sheep from the goats. It did so on the basis of assuming the > results formed a "bell curve" and then fenced the anxious teenagers based on > the standard deviation.[1] > > Obviously - or I wouldn't be telling this story! - all the arithmetic was > performed using packed decimal and the "heavy lifting" was in determining the > variance: the mean, the differences from the mean and the squares of the > latter.[2] > > I was one of a team of three assigned to win this benchmark to replace a > bigger machine with a smaller machine! The team leader initiated the effort > by simply writing the tape records as blocks. This reduced the execution time > by half from about 30 minutes to 15 minutes - and would probably have been > sufficient to win the contest. However I had my eye on those unsavoury packed > decimal instructions! > > Essentially I rewrote the whole program using binary arithmetic instructions > to replace the packed decimal instructions. I happened to mention what I was > doing - more strictly, had done - to one of my colleagues - of an academic > bent comparable to our own John Gilmore! He responded by reminding me - or in > case I didn't know - that use of base registers was faster than using index > registers. Of course, either I had forgotten or just didn't know before.[3] > Back to the 129 in order to rekey a significant percentage of the source > program cards with commas in front of the register numbers where a storage > reference was required - or implied. > > Mistake! The BPS-Tape assembler can't handle "(,R)" like its more > sophisticated cousins can. The BPS-Tape assembler requires "(0,R)". Back to > the 129 again. > > Did the fundamental change to the type of instruction performing the > arithmetic do any good? I seem to remember that a number of seconds were > "knocked" off the total time, trivial in comparison with the benefits of > improving the tape I/O. > > Again by means of a massive rewrite, I introduced another improvement. I > can't recall why it was necessary to read the tape with the results records > multiple times, but this was the way the original program worked and so, > until this point, I had kept that basic logic. Taking into account the > proposed storage, I reduced the number of tape passes from - IMMSMC - 10 to > 2. Again an improvement to be measured in seconds since I had managed to > extinguish the "wait light" and the tape now limped along where previously it > had sprinted.[4] > > - > > [1] There's a lot of discussion these days in the British news media of a > creep to larger percentages of the higher grades in exam results, > particularly the exams leading to university entrance. This would not be > possible if the exam boards continued to use the methodology embedded in the > analysis of results used by this exam board 40 years ago. > > [2] The calculation of the standard deviation was rather clever. In a way > this also promised to be "heavy lifting" since the determination of the > square root of the variance depended on iteration. However it must have been > considered that two iterations were always sufficient.[2.1] The refining > logic was framed by an initial BALR R,0 and a final BALR R,R. > > [2.1] I forget at how the initial guess was arrived but I suppose it may have > been a constant corresponding to a typical historical value. > > [3] The time for compilation of the program was also to taken into account. > Fortunately I had already been told - or perhaps noticed - that the tape > operations during compilation worked faster when all macros were kept near > the beginning of the program source. > > [4] I won't even mention that over a drink in the hotel bar before the > "trysting day", I realised that there was one more possible improvement. This > would have involved overlaying initialisation logic storage with working > space! There wasn't time now and it wasn't needed since the 360/30 was duly > replaced by a 360/25. > > - > > Chris Mason > > > On Sat, 14 Jul 2012 08:08:03 -0400, John Gilmore <jwgli...@gmail.com> wrote: > >> Doing integer--as opposed to real fixed-point--arithmetic with >> packed-decimal values is the real culprit here. >> >> Integer arithmetic should never be done with anything but binary >> integers. Operations on them are register operations, which are much >> faster than storage-to-storage ones; and zero is always positive. >> Moreover, it is now possible to make them behave in COBOL exactly as >> they do in assembly language. >> >> John Gilmore, Ashland, MA 01721 - USA > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
