COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
in [Cobol]
|
Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Robert on 26 Sep 2007 20:19 On Wed, 26 Sep 2007 09:36:42 -0400, "Charles Hottel" <chottel(a)earthlink.net> wrote: >I was in somewhat of a hurry when I converted Roberts program to use my >mainframe timer routine. Looking at the TIMER-OFF: > > TIMER-OFF. > PERFORM READ-THE-TIME > COMPUTE ELAPSED-TIME ROUNDED = > ((TIME-NOW - TIME-START) - TIMER-OVERHEAD) /1000000 > > IF ELAPSED-TIME NOT GREATER THAN ZERO > MOVE 'ERROR' TO ELAPSED-TIME-DISPLAY > ELSE > COMPUTE ELAPSED-TIME-EDITED ROUNDED = ELAPSED-TIME * 10 > END-IF > DISPLAY TEST-NAME ELAPSED-TIME-DISPLAY > >My timing routine computes the time in microseconds since the task started. > >The ELAPSED-TIME-EDITED is ELAPSED-TIME multiplied by 10, so I think all of >the times I published may be 10 times higher than the actual elasped time. I >am somewhat skeptical of measuring actual times on a mainframe without >repeating the tests six to ten times and computing an average, variance >and/or standard deviation. I did not spend much time thinking about whether >to remove that COMPUTE because to me it was the relative speeds that were >important. Also I did not analyze Roberts timing method or the rationale for >this COMPUTE because my past experience using his timing method showed it >was grossly inaccurate on a mainframe (the task gets swapped out, put into a >wait state, but the time of day clock keeps on ticking). Sorry I guess I was >lazy, and my only excuse is that I am still far from being 100% of my old >self lately. My objective was to express duration as a two digit number, for easy comprehension. The numbers displayed are wall clock seconds times 10. There is no way to measure process-active time in Cobol. If I had done it with operating system calls, the program wouldn't be portable.
From: Jeff Campbell on 26 Sep 2007 20:42 Roger While wrote: > I really, really tried to keep away from this subject but ... > One of the problems with the speed2 prog is the > attempt to deduce the perform cost. > Now OC produces exactly the C code that reflects > the statements eg. > /* speed2.cob:63: PERFORM */ > { > for (n0 = ((int)COB_BSWAP_32(*(int *)(b_18 + 30))); n0 > 0; n0--) > { > { > /* speed2.cob:64: EXIT */ > { > goto l_5; > } > } > > /* EXIT PERFORM CYCLE 5: */ > l_5:; > } > } > > BUT gcc (in current versions) is far more > clever and deletes the whole thing :-) > > Revised test prog - > (This should be compatible with most compilers) > > identification division. > program-id. speed5. > data division. > working-storage section. > 01 comp5-number comp-5 pic s9(09). > 01 s-subscript binary pic s9(09). > 01 repeat-factor value 900000000 comp-5 pic s9(09). > 01 test-byte pic x(01). > > 01 misaligned-area. > 05 array-element occurs 4096 indexed x-index. > 10 misaligned-number comp-5 pic s9(09). > 10 to-cause-misalignment pic x(01). > 05 byte-element occurs 4096 indexed x-index-1 pic x. > > procedure division. > > initialize misaligned-area > > display "Start prog " function current-date > set x-index to 1000 > display "Index start " function current-date > perform repeat-factor times > if x-index = 1000 > set x-index up by 1 > else > set x-index down by 1 > end-if > move array-element (x-index) to test-byte > end-perform > display "Index end " function current-date > > move 1000 to s-subscript > display "COMP start " function current-date > perform repeat-factor times > if s-subscript = 1000 > add 1 to s-subscript > else > subtract 1 from s-subscript > end-if > move array-element (s-subscript) to test-byte > end-perform > display "COMP end " function current-date > > move 1000 to comp5-number > display "COMP-5 start " function current-date > perform repeat-factor times > if comp5-number = 1000 > add 1 to comp5-number > else > subtract 1 from comp5-number > end-if > move array-element (comp5-number) to test-byte > end-perform > display "COMP-5 end " function current-date > > set x-index-1 to 1000 > display "Index start " function current-date > perform repeat-factor times > if x-index-1 = 1000 > set x-index-1 up by 1 > else > set x-index-1 down by 1 > end-if > move byte-element (x-index-1) to test-byte > end-perform > display "Index end " function current-date > > move 1000 to s-subscript > display "COMP start " function current-date > perform repeat-factor times > if s-subscript = 1000 > add 1 to s-subscript > else > subtract 1 from s-subscript > end-if > move byte-element (s-subscript) to test-byte > end-perform > display "COMP end " function current-date > > move 1000 to comp5-number > display "COMP-5 start " function current-date > perform repeat-factor times > if comp5-number = 1000 > add 1 to comp5-number > else > subtract 1 from comp5-number > end-if > move byte-element (comp5-number) to test-byte > end-perform > display "COMP-5 end " function current-date > > stop run. > > Note that the repeat count is pushed up, otherwise the results are > statistically meaningless.Tests repeated 5 times with +- 1/100 second > difference. > > Results from Linux boxen (in single-user mode) > (As all benchmarks should be done on 'nix systems) > (32 bit is P4 prescott with 3.2GhZ) > (64 bit is P4 > > MF SE 2.2 (Linux x86 32 bit) > cob -u -O -C notrunc -C sourceformat=free speed5.cob > cobrun speed5 > Start prog 2007092612363397+0200 > Index start 2007092612363397+0200 > Index end 2007092612363681+0200 > COMP start 2007092612363681+0200 > COMP end 2007092612364047+0200 > COMP-5 start 2007092612364047+0200 > COMP-5 end 2007092612364361+0200 > Index start 2007092612364361+0200 > Index end 2007092612364672+0200 > COMP start 2007092612364672+0200 > COMP end 2007092612365034+0200 > COMP-5 start 2007092612365034+0200 > COMP-5 end 2007092612365357+0200 > > OC 0.33 current - > cobc -x -O2 -std=mf -free speed5.cob > ./speed5 > Start prog 2007092612311407+0200 > Index start 2007092612311407+0200 > Index end 2007092612311690+0200 > COMP start 2007092612311690+0200 > COMP end 2007092612312044+0200 > COMP-5 start 2007092612312044+0200 > COMP-5 end 2007092612312326+0200 > Index start 2007092612312326+0200 > Index end 2007092612312609+0200 > COMP start 2007092612312609+0200 > COMP end 2007092612312963+0200 > COMP-5 start 2007092612312963+0200 > COMP-5 end 2007092612313246+0200 > > OC 0.33 current on Linux x86_64 (64 bit) > cobc -x -O2 -std=mf -free speed5.cob > ./speed5 > Start prog 2007092612285455+0200 > Index start 2007092612285455+0200 > Index end 2007092612285602+0200 > COMP start 2007092612285602+0200 > COMP end 2007092612285855+0200 > COMP-5 start 2007092612285855+0200 > COMP-5 end 2007092612290004+0200 > Index start 2007092612290004+0200 > Index end 2007092612290135+0200 > COMP start 2007092612290135+0200 > COMP end 2007092612290366+0200 > COMP-5 start 2007092612290366+0200 > COMP-5 end 2007092612290497+0200 > > Now as to what has all been said in this thread, then I have the > following comments - > COMP (aka BINARY) is stored as big-endian by all > compilers these days. > Therefore there is a penalty on little-endian machines > (or better the OS/firmware for eg. bi-endian) to > byte-swap, operate and re-byteswap results. > This, of course, affects eg. x86(_64). > However, see below > > Alignment - > There are in fact not that many alignment tolerant machines there. > Intel x86(_64) and Power PC are known. (The Itanium is not) > This means that any reference to a COMP/COMP-5 item must > be moved to an intermediate area unless it can be proved at compile > time that it is appropiately aligned. (eg. at 01 level) > > So we have to look at a bisection of the above two attributes. > Generally speaking, for performance, (other than INDEX) > one should use COMP-5 (aka BINARY-LONG SIGNED/UNSIGNED) > for subscripts/counters etc. and define them at the 01 level. > > Not only that, a particular compiler implementation has it's > own INDEX definition which is somewhat difficult to ascertain. > (And which is not necessarily a C-5 item) > > Roger > The only change I had to make was to add a paragraph label. 8-) Alpha Personal Workstation 600au running OpenVMS 7.3-1: $ cobo/list:speed5/noansi/notrun/opti speed5 $ link speed5 $ run speed5 Start prog 200709270036324700000 Index start 200709270036324700000 Index end 200709270036355100000 COMP start 200709270036355100000 COMP end 200709270036385500000 COMP-5 start 200709270036385500000 COMP-5 end 200709270036415900000 Index start 200709270036415900000 Index end 200709270036446200000 COMP start 200709270036446200000 COMP end 200709270036476600000 COMP-5 start 200709270036476600000 COMP-5 end 200709270036507000000 $ Jeff ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
From: Pete Dashwood on 26 Sep 2007 21:03 "Robert" <no(a)e.mail> wrote in message news:b7tlf3hifb1qfde4trikpetrel84gs08ro(a)4ax.com... > On Wed, 26 Sep 2007 09:36:42 -0400, "Charles Hottel" > <chottel(a)earthlink.net> wrote: > >>I was in somewhat of a hurry when I converted Roberts program to use my >>mainframe timer routine. Looking at the TIMER-OFF: >> >> TIMER-OFF. >> PERFORM READ-THE-TIME >> COMPUTE ELAPSED-TIME ROUNDED = >> ((TIME-NOW - TIME-START) - TIMER-OVERHEAD) /1000000 >> >> IF ELAPSED-TIME NOT GREATER THAN ZERO >> MOVE 'ERROR' TO ELAPSED-TIME-DISPLAY >> ELSE >> COMPUTE ELAPSED-TIME-EDITED ROUNDED = ELAPSED-TIME * 10 >> END-IF >> DISPLAY TEST-NAME ELAPSED-TIME-DISPLAY >> >>My timing routine computes the time in microseconds since the task >>started. >> >>The ELAPSED-TIME-EDITED is ELAPSED-TIME multiplied by 10, so I think all >>of >>the times I published may be 10 times higher than the actual elasped time. >>I >>am somewhat skeptical of measuring actual times on a mainframe without >>repeating the tests six to ten times and computing an average, variance >>and/or standard deviation. I did not spend much time thinking about >>whether >>to remove that COMPUTE because to me it was the relative speeds that were >>important. Also I did not analyze Roberts timing method or the rationale >>for >>this COMPUTE because my past experience using his timing method showed it >>was grossly inaccurate on a mainframe (the task gets swapped out, put into >>a >>wait state, but the time of day clock keeps on ticking). Sorry I guess I >>was >>lazy, and my only excuse is that I am still far from being 100% of my old >>self lately. > > My objective was to express duration as a two digit number, for easy > comprehension. > The numbers displayed are wall clock seconds times 10. While I'm all in favour of a simple display (I haven't checked Roger's version because it is too much hassle combing through the output, it cannot be easily compared to other runs, and I have neither time nor inclination to amend the code to do the calculations in the program), I question whether the numbers displayed are wall clock seconds times 10, Robert. As my run gave a result of 22 or so for subscripts, that would mean the job ran for at least 220 seconds. It didn't run anything like that. I didn't actually time it, but it was not more than a few seconds of elapsed time. If I get a chance later today, I'll run it again and time it. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 26 Sep 2007 22:08 On Wed, 26 Sep 2007 09:33:16 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <uq8jf3pd3rq48eqio0hdtqo172nv2c16is(a)4ax.com>, >Robert <no(a)e.mail> wrote: >>On Tue, 25 Sep 2007 22:45:12 +0000 (UTC), docdwarf(a)panix.com () wrote: >> >>>In article <regif3d0b34nreavsckap09omqjhptnik8(a)4ax.com>, >>>Robert <no(a)e.mail> wrote: >>>>On Tue, 25 Sep 2007 09:25:04 +0000 (UTC), docdwarf(a)panix.com () wrote: >>>> >> >>>>>Now, Mr Wagner... is one to expect another dreary series of repetitions >>>>>about how mainframers who said that indices were faster than subscripts >>>>>were, in fact, right about something? >>>> >>>>I expected I-told-you-so from the mainframe camp. >>> >>>It may be interesting to see if you get one; my point - and pardon the >>>obscure manner of its making - was that you made a series of repetitions >>>which a demonstration has disproved and it may be interesting to see if an >>>equally lengthy series of repetitions follows... or if it just Goes Away >>>until you next get an idea about something... and begin another, similar >>>series of repetitions. >> >>We saw that subscript and index run at the same speed on three CPU >>families -- HP PA >>(SuperDome), DEC Alpha (Cray) and Richard's undisclosed machine, >>possibly Intel. > >I can barely speak for myself, Mr Wagner, let alone some 'we'... but I >recall seeing post after post were you indicated, rather pointedly, that >the speed superiority of indices over subscripts was something maintained >by mainframers and was, according to your test, an obsolete belief. > >Results were then posted, purporting to be from a mainframe run, which >appeared to verify this obsolete belief. > >>I am >>confident we'd see the same on Intel, PowerPC (pseries, iseries, Mac) >>and SPARC, based on >>tests I ran a few years ago. Thus the generalizaton. I was surprised to >>see zSeries did >>not follow the pattern of the others. > >A wonderful world it is, Mr Wagner... and perhaps this inconsistency of >performance might work itsself into your own consistency of performance. >It might be an interesting exercise, saying, in the future, 'this-and-that >is quite obviously the case... but remember, when I said that-and-this was >the case I was, quite soundly and publicly, shown an example to the >contrary.' > >> >>My previous idea, that memory alignment no longer matters, turned out to >>be wrong. It does >>matter on modern RISC machines. >> >>There's a good chance I'll get another idea. > >That's to be be hoped for... and even more so that it will be shaped by >one's previous ideas, both proven right *and* proven wrong. As a classics scholar, you know ad hominem means 'against the person', not 'insult' as commonly thought. What's wrong with ad hominem is not that it's unmannerly; what's wrong is that it is a logical ERROR OF IRRELEVANCE. When someone says we should believe him because he is an expert and knows more than we do, he is making an argument from authority. In that case, and ONLY that case, an attack on his veracity is relevant, because he used it as a premise of his argument. Legitimate experts (such as Bill Klien) seldom argue from authority, except as expert witnesses in court or as TV commentators. In hard science circles, the 'authority' would be advised to take his expertise plus an additional $3 to the nearest Starbucks. When someone makes NO claim to authority, posits an argument that uses verifiable facts as premises, rebuttal pointing out his prior errors is logically invalid .. because it doesn't deal with anything he said. Why is ad hominem such a common informal fallacy? Why are politicians and TV spokesmen judged on their believability? Because the most common decision processes are based on emotion rather than logic. I won't go into the reasons why because this isn't a psychology forum. I only wanted to point out why attacking credibility is an invalid response.
From: Robert on 26 Sep 2007 22:15
On Thu, 27 Sep 2007 13:03:39 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:b7tlf3hifb1qfde4trikpetrel84gs08ro(a)4ax.com... >> On Wed, 26 Sep 2007 09:36:42 -0400, "Charles Hottel" >> <chottel(a)earthlink.net> wrote: >> >>>I was in somewhat of a hurry when I converted Roberts program to use my >>>mainframe timer routine. Looking at the TIMER-OFF: >>> >>> TIMER-OFF. >>> PERFORM READ-THE-TIME >>> COMPUTE ELAPSED-TIME ROUNDED = >>> ((TIME-NOW - TIME-START) - TIMER-OVERHEAD) /1000000 >>> >>> IF ELAPSED-TIME NOT GREATER THAN ZERO >>> MOVE 'ERROR' TO ELAPSED-TIME-DISPLAY >>> ELSE >>> COMPUTE ELAPSED-TIME-EDITED ROUNDED = ELAPSED-TIME * 10 >>> END-IF >>> DISPLAY TEST-NAME ELAPSED-TIME-DISPLAY >>> >>>My timing routine computes the time in microseconds since the task >>>started. >>> >>>The ELAPSED-TIME-EDITED is ELAPSED-TIME multiplied by 10, so I think all >>>of >>>the times I published may be 10 times higher than the actual elasped time. >>>I >>>am somewhat skeptical of measuring actual times on a mainframe without >>>repeating the tests six to ten times and computing an average, variance >>>and/or standard deviation. I did not spend much time thinking about >>>whether >>>to remove that COMPUTE because to me it was the relative speeds that were >>>important. Also I did not analyze Roberts timing method or the rationale >>>for >>>this COMPUTE because my past experience using his timing method showed it >>>was grossly inaccurate on a mainframe (the task gets swapped out, put into >>>a >>>wait state, but the time of day clock keeps on ticking). Sorry I guess I >>>was >>>lazy, and my only excuse is that I am still far from being 100% of my old >>>self lately. >> >> My objective was to express duration as a two digit number, for easy >> comprehension. >> The numbers displayed are wall clock seconds times 10. > >While I'm all in favour of a simple display (I haven't checked Roger's >version because it is too much hassle combing through the output, it cannot >be easily compared to other runs, and I have neither time nor inclination to >amend the code to do the calculations in the program), I question whether >the numbers displayed are wall clock seconds times 10, Robert. As my run >gave a result of 22 or so for subscripts, that would mean the job ran for at >least 220 seconds. It didn't run anything like that. I didn't actually time >it, but it was not more than a few seconds of elapsed time. If I get a >chance later today, I'll run it again and time it. Ah, innumeracy. I said TIMES 10, not divided by 10. Run time of 2.2 seconds times 10 equals 22. |