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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
