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 01:47 On Wed, 26 Sep 2007 16:08:25 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:uq8jf3pd3rq48eqio0hdtqo172nv2c16is(a)4ax.com... >> 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 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. > >Well, Robert, I don't want to shake your confidence, and I deliberately >refrained from posting these results (I felt you were getting enough >flak...), but reconsidered when I saw your statement above :-) > >Here are the results of "Speed2" from a genuine Intel Celeron Core 2 Duo >Vaio AR250G notebook with 2 GB of main memory, running under Windows XP with >SP2 applied, using your code (with the following amendments: all asterisks >and comments removed, exit perform cycle removed), compiled with no options >other than the defaults (which includes "Optimize"), with the Fujitsu >NetCOBOL version 6 compiler, compiled to .EXE: > >Null test 1 >Index 3 >Subscript 25 >Subscript comp-5 3 >Index 1 3 >Subscript 1 22 >Subscript 1 comp-5 3 > >As you can see, indexing is between 7 and 8 times more efficient than >subscripting, unless you use optimized subscripts, in this environment. I read your results to say subscripting and indexing run at the same speed. Comp-5 is the NORMAL type for subscripts in code I write. In the Old Style code I work on, millions of lines, 'they' use either comp or comp-5. I think Fujitsu's slowness came not from subscript calculation but rather from truncation checking. Is there a NOTRUNC option? >(I was surprised that the figures are 3 times faster than the z/OS mainframe >figures posted by Charlie...:-) I'm not. :) A SPARC would show approx. 5. I think an Itanium would show 1. Without exit perform cycle, my PA showed 14. >I've had this machine for around a year now, >bought it at Fry's in L.A a few days after Core 2 became available in the >marketplace, and have become blase about the speed of it. A few days ago I >was running a test on a P4 notebook that had to create a couple of million >rows on an ACCESS database. It ran for 20 minutes, then closed down due to a >thermal cutoff. (If the CPU runs at or near 100% for an extended period, the >machine closes down :-) It was made in Germany and I bought it in England. >It is an annoying, although valuable feature of this machine, that it >protects itself. Anyway, I transferred the job to the Vaio and tried again: >It never even broke into a sweat; no fans came on and the job was done in 7 >minutes...(It does NOT have a high speed disk, runs at 5400 RPM but is well >buffered, and they claim it was the first disk drive for a notebook that had >200GB)) > >It is things like this that make me wonder why we even bother about >performance and have heated discussions about things like indexes and >subscripts, when the technology is advancing rapidly enough to simply take >care of it. I've said the same, but no one listens. Cobol people like to optimize. What started this discussion was Micro Focus' placement of speed tips as Chapter 1 of a programming manual. >More importantly, I hope Robert you will accept that generalizations about >performance simply don't stack up. Sometimes the most unexpected results are >obtained. The only reliable way to check performance is empirically (I give >you credit for doing that, and publishing results even when they didn't tell >you what you wanted to hear) and, outside of test results, everything else >should be accorded the same degree of credibility that we accord glossy >marketing brochures ("MIGHT be true...but the person presenting it has a >definite axe to grind :-)) Few threads in CLC are based on empirical evidence. Most are based on opinion.
From: William M. Klein on 26 Sep 2007 01:48 "Robert" <no(a)e.mail> wrote in message news:1eljf358c4bph284c6md1oorfos07q76q0(a)4ax.com... > On Wed, 26 Sep 2007 02:29:59 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > <snip> > As you requested, I compiled speed2 with ENTCOBOL and NOMF at the end of the > options > already there. Getting it to compile required three changes: > Change To > comp-5 binary > goback stop run > exit perform cycle continue Robert, Please post your LISTING (with SETING(COL3)) as being rquired to change COMP-5 and GOBACK means that SOMETHING you did wasn't right. NOMF DIALECT(ENTCOBOL) FLAGAS(S) (ro example) should accept both of those. If you did NOT use the "dialect" directive, then you need to use NOMF ENTCOBOL FLAG(ENTCOBOL) FLAGAS(S) (using SETTING(COL3) and LIST() will show which directives you actually have on.> -- Bill Klein wmklein <at> ix.netcom.com
From: William M. Klein on 26 Sep 2007 01:56 "Robert" <no(a)e.mail> wrote in message news:44rjf3d2v6sc60fadkk326985hnhu3jmre(a)4ax.com... > On Wed, 26 Sep 2007 16:08:25 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > <snip> >>Here are the results of "Speed2" from a genuine Intel Celeron Core 2 Duo >>Vaio AR250G notebook with 2 GB of main memory, running under Windows XP with >>SP2 applied, using your code (with the following amendments: all asterisks >>and comments removed, exit perform cycle removed), compiled with no options >>other than the defaults (which includes "Optimize"), with the Fujitsu >>NetCOBOL version 6 compiler, compiled to .EXE: >> >>Null test 1 >>Index 3 >>Subscript 25 >>Subscript comp-5 3 >>Index 1 3 >>Subscript 1 22 >>Subscript 1 comp-5 3 >> >>As you can see, indexing is between 7 and 8 times more efficient than >>subscripting, unless you use optimized subscripts, in this environment. > > I read your results to say subscripting and indexing run at the same speed. > Comp-5 is the NORMAL type for subscripts in code I write. In the Old Style > code I work on, > millions of lines, 'they' use either comp or comp-5. > > I think Fujitsu's slowness came not from subscript calculation but rather from > truncation > checking. Is there a NOTRUNC option? > >>(I was surprised that the figures are 3 times faster than the z/OS mainframe >>figures posted by Charlie...:-) > I am not all that surprised that Fujitsu's results have some "similarity" to that on IBM mainframes. As we have discussed in this forum before, Fujitsu has many UNDOCUMENTED "IBM extensions" in their (Windows) compiler. I believe that all of this goes way back to the Fujitsu/IBM legal situation where Fujitsu's software - including their COBOL compiler for their mainframe - started out with IBM products' code. My guess (and I have had some evidence before on this) is that the earlier Fujitsu Windows COBOL compilers was a "port" of their IBM-derived compiler. I have no firm evidence of this - but results like this certainly seem to support - not confirm - it. P.S. Related to "NOTRUNC" - this is another issue where using the IBM "TRUNC(BIN)" whish is most similar to NOTRUNC actually SERIOUSLY slows down, BINARY, COMP, and COMP-5 behavior. I have *never* understood what IBM did with generated code to make this ture, but it is and they document it that way. -- Bill Klein wmklein <at> ix.netcom.com
From: Richard on 26 Sep 2007 02:34 On Sep 26, 5:47 pm, Robert <n...(a)e.mail> wrote: > On Wed, 26 Sep 2007 16:08:25 +1200, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> > wrote: > > > > > > >"Robert" <n...(a)e.mail> wrote in message > >news:uq8jf3pd3rq48eqio0hdtqo172nv2c16is(a)4ax.com... > >> On Tue, 25 Sep 2007 22:45:12 +0000 (UTC), docdw...(a)panix.com () wrote: > > >>>In article <regif3d0b34nreavsckap09omqjhptn...(a)4ax.com>, > >>>Robert <n...(a)e.mail> wrote: > >>>>On Tue, 25 Sep 2007 09:25:04 +0000 (UTC), docdw...(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 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. > > >Well, Robert, I don't want to shake your confidence, and I deliberately > >refrained from posting these results (I felt you were getting enough > >flak...), but reconsidered when I saw your statement above :-) > > >Here are the results of "Speed2" from a genuine Intel Celeron Core 2 Duo > >Vaio AR250G notebook with 2 GB of main memory, running under Windows XP with > >SP2 applied, using your code (with the following amendments: all asterisks > >and comments removed, exit perform cycle removed), compiled with no options > >other than the defaults (which includes "Optimize"), with the Fujitsu > >NetCOBOL version 6 compiler, compiled to .EXE: > > >Null test 1 > >Index 3 > >Subscript 25 > >Subscript comp-5 3 > >Index 1 3 > >Subscript 1 22 > >Subscript 1 comp-5 3 > > >As you can see, indexing is between 7 and 8 times more efficient than > >subscripting, unless you use optimized subscripts, in this environment. > > I read your results to say subscripting and indexing run at the same speed. > Comp-5 is the NORMAL type for subscripts in code I write. In the Old Style code I work on, > millions of lines, 'they' use either comp or comp-5. > > I think Fujitsu's slowness came not from subscript calculation but rather from truncation > checking. Is there a NOTRUNC option? > > >(I was surprised that the figures are 3 times faster than the z/OS mainframe > >figures posted by Charlie...:-) > > I'm not. :) A SPARC would show approx. 5. I think an Itanium would show 1. > Without exit perform cycle, my PA showed 14. > > > > >I've had this machine for around a year now, > >bought it at Fry's in L.A a few days after Core 2 became available in the > >marketplace, and have become blase about the speed of it. A few days ago I > >was running a test on a P4 notebook that had to create a couple of million > >rows on an ACCESS database. It ran for 20 minutes, then closed down due to a > >thermal cutoff. (If the CPU runs at or near 100% for an extended period, the > >machine closes down :-) It was made in Germany and I bought it in England. > >It is an annoying, although valuable feature of this machine, that it > >protects itself. Anyway, I transferred the job to the Vaio and tried again: > >It never even broke into a sweat; no fans came on and the job was done in 7 > >minutes...(It does NOT have a high speed disk, runs at 5400 RPM but is well > >buffered, and they claim it was the first disk drive for a notebook that had > >200GB)) .. > >It is things like this that make me wonder why we even bother about > >performance and have heated discussions about things like indexes and > >subscripts, when the technology is advancing rapidly enough to simply take > >care of it. > I've said the same, but no one listens. Cobol people like to optimize. What nonsense. You advocated subscripts 'because they were faster'. You advocated linked lists 'because they were faster' (even though actually they weren't). You advocated multi-threading 'because it was faster'. > What started this > discussion was Micro Focus' placement of speed tips as Chapter 1 of a programming manual. Which, AFAIK, never mentions index vs. subscript. That was something you made up. You wanted to denigrate the tips, but failed to (partly because you didn't understand some of them). > >More importantly, I hope Robert you will accept that generalizations about > >performance simply don't stack up. Sometimes the most unexpected results are > >obtained. The only reliable way to check performance is empirically (I give > >you credit for doing that, and publishing results even when they didn't tell > >you what you wanted to hear) and, outside of test results, everything else > >should be accorded the same degree of credibility that we accord glossy > >marketing brochures ("MIGHT be true...but the person presenting it has a > >definite axe to grind :-)) > > Few threads in CLC are based on empirical evidence. Most are based on opinion. And your empirical evidence for this is ? Oh, wait ...
From: Richard on 26 Sep 2007 03:03
On Sep 26, 5:47 pm, Robert <n...(a)e.mail> wrote: > On Wed, 26 Sep 2007 16:08:25 +1200, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> > wrote: > > > > > > >"Robert" <n...(a)e.mail> wrote in message > >news:uq8jf3pd3rq48eqio0hdtqo172nv2c16is(a)4ax.com... > >> On Tue, 25 Sep 2007 22:45:12 +0000 (UTC), docdw...(a)panix.com () wrote: > > >>>In article <regif3d0b34nreavsckap09omqjhptn...(a)4ax.com>, > >>>Robert <n...(a)e.mail> wrote: > >>>>On Tue, 25 Sep 2007 09:25:04 +0000 (UTC), docdw...(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 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. > > >Well, Robert, I don't want to shake your confidence, and I deliberately > >refrained from posting these results (I felt you were getting enough > >flak...), but reconsidered when I saw your statement above :-) > > >Here are the results of "Speed2" from a genuine Intel Celeron Core 2 Duo > >Vaio AR250G notebook with 2 GB of main memory, running under Windows XP with > >SP2 applied, using your code (with the following amendments: all asterisks > >and comments removed, exit perform cycle removed), compiled with no options > >other than the defaults (which includes "Optimize"), with the Fujitsu > >NetCOBOL version 6 compiler, compiled to .EXE: > > >Null test 1 > >Index 3 > >Subscript 25 > >Subscript comp-5 3 > >Index 1 3 > >Subscript 1 22 > >Subscript 1 comp-5 3 > > >As you can see, indexing is between 7 and 8 times more efficient than > >subscripting, unless you use optimized subscripts, in this environment. > > I read your results to say subscripting and indexing run at the same speed. > Comp-5 is the NORMAL type for subscripts in code I write. In the Old Style code I work on, > millions of lines, 'they' use either comp or comp-5. > > I think Fujitsu's slowness came not from subscript calculation but rather from truncation > checking. Is there a NOTRUNC option? With Fujitsu on Linux I recompiled with NOTRUNC and it fractionally improved all speeds leaving the same relative performance with index slightly faster. > >(I was surprised that the figures are 3 times faster than the z/OS mainframe > >figures posted by Charlie...:-) > > I'm not. :) A SPARC would show approx. 5. I think an Itanium would show 1. > Without exit perform cycle, my PA showed 14. > > > > >I've had this machine for around a year now, > >bought it at Fry's in L.A a few days after Core 2 became available in the > >marketplace, and have become blase about the speed of it. A few days ago I > >was running a test on a P4 notebook that had to create a couple of million > >rows on an ACCESS database. It ran for 20 minutes, then closed down due to a > >thermal cutoff. (If the CPU runs at or near 100% for an extended period, the > >machine closes down :-) It was made in Germany and I bought it in England. > >It is an annoying, although valuable feature of this machine, that it > >protects itself. Anyway, I transferred the job to the Vaio and tried again: > >It never even broke into a sweat; no fans came on and the job was done in 7 > >minutes...(It does NOT have a high speed disk, runs at 5400 RPM but is well > >buffered, and they claim it was the first disk drive for a notebook that had > >200GB)) > > >It is things like this that make me wonder why we even bother about > >performance and have heated discussions about things like indexes and > >subscripts, when the technology is advancing rapidly enough to simply take > >care of it. > > I've said the same, but no one listens. Cobol people like to optimize. What started this > discussion was Micro Focus' placement of speed tips as Chapter 1 of a programming manual. > > >More importantly, I hope Robert you will accept that generalizations about > >performance simply don't stack up. Sometimes the most unexpected results are > >obtained. The only reliable way to check performance is empirically (I give > >you credit for doing that, and publishing results even when they didn't tell > >you what you wanted to hear) and, outside of test results, everything else > >should be accorded the same degree of credibility that we accord glossy > >marketing brochures ("MIGHT be true...but the person presenting it has a > >definite axe to grind :-)) > > Few threads in CLC are based on empirical evidence. Most are based on opinion. |