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 21 Sep 2007 23:21 On Fri, 21 Sep 2007 11:09:16 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >"Robert" <no(a)e.mail> wrote in message >news:i3j6f3pa7ucignv34t4oklno0ht8jh2c5p(a)4ax.com... >> On Fri, 21 Sep 2007 04:21:35 GMT, "William M. Klein" >> <wmklein(a)nospam.netcom.com> wrote: >> ><snip> >> I and Richard posted facts showing speed is the same. We have not seen facts >> from >> mainframe-land,except a five year old study. Just post some facts and skip the >> ad homina. > >I do NOT have personal access to an Enterprise V3.4 COBOL compiler - and I do >believe what IBM says about its performance (and don't believe that you know how >they implement all their syntax -> machine code). HOWEVER, > >If you create a source program that you think tests subscripts vs indexes >(whether it is comprehensive or not), then I think some CLC person might compile >and run it for you. > >Therefore, please create and post a sample program that cleanly compiles with >the Micro Focus directives: > NOMF DIALECT(ENTCOBOL) FLAGAS(S) > >If you are not using a current-enough version of Server Express to include >support for the DIALECT directive, then use: > NOMF ENTCOBOL FLAG(ENTCOBOL) FLAGAS(S) ARITHMETIC(ENTCOBOL) >PERFORM-TYPE(ENTCOBOL) That's not necessary. The code I posted is Standard-compliant except for comp-5, which we all know IBM can handle. >If you post such a program and no one else in CLC compiles and runs it (and >posts the results) I will find someone who can and will. Any volunteers? >As I have previously, stated, I don't think any of your tests are comprehensive >(as I *do* think those of the IBM Performance paper were). However, this will >(I believe) give you an answer as to what happens today with Enterprise COBOL. The IBM report contains a single sentence saying indexes are 30% faster than subscripts. We don't know whether that came from a cursory or comprehensive test. We don't even know the data type of the subscript they used.
From: Richard on 22 Sep 2007 00:19 On Sep 22, 3:15 pm, Robert <n...(a)e.mail> wrote: > On Thu, 20 Sep 2007 18:27:53 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > > >Robert wrote: > >> On Thu, 20 Sep 2007 16:53:29 -0600, LX-i <lxi0...(a)netscape.net> wrote: > > >> >You've shown that what used to be significant overhead with subscripts > >> >is now gone in one particular environment. > > >> It's gone on all platforms, or soon will be. > > >Geez, Robert, is this some magic that will replace everyone's > >compilers with brand new ones. Are you walking the streets crying "New > >compilers for old" ? > > Multiplication speed is a function of CPUs, not compilers. A timing test program could > show different relative speeds, even though it was not recompiled. The only reason that on your system the subscripts are as fast as indexes is that the _optimizer_ in the compiler has removed the recalculation of the address, just as it does with indexes. Putting in a faster processor will improve the speed of all operations and will not, by itself, have subscripts catch up to indexes. If a compiler does not optimizes the reuse of subscripts then they will still be slower. > >> > But, the completeness of > >> >being able to define an array with (an) index(es) of its' very own > >> >appeals to some people, who will continue to do it. Using an index > >> >isn't 1970's COBOL. > > >> That's true. Indexes were introduced 'recently' in the '74 Standard ... > > >To replace subscripts. > > >You want to revert to 1960s style. > > >> I SAID most Cobol programmers will continue using indexes. > > >Just because subscripts have sometimes 'caught up' (or maybe will do) > >does not make subscripts better, or even as good as indexes. > > >Subscripts may be miscoded with inadequate size or poor usage. > >Indexes cannot be. > > >Subscripts can be slow. Indexes are always as fast as can be. > > Valid points. So then, you will agree that there are reasons for using indexes that include speed and safety. > >Subscripts can be corrupted by using the wrong one, there is no check. > >Indexes are 'local', they are tied to a table, in fact tied to an > >occurs level, the compiler will tell the programmer when they are > >wrongly used. > > Unless the compiler has been 'liberalized' to permit that misuse. I just learned here it's > a common extension. I never thought to try it. It may be an extension in some compilers, notably IBM ones. MF may allow that extension if the appropriate flags are on, or can be off for safety. Fujitsu does not have that extension. > >Indexes are required for SEARCH. > > Only the binary version. One can say VARYING on a serial SEARCH. > > >So why are you trying to persuade people to revert to 1960s > >techniques ? Why do you think you are 'modern' when you are simply > >uninformed ? > > The modern feature of my argument is that multiply is no longer slow. Indexes would never > have been invented ifmultiply were as fast as load in the Good Old Days. No, Robert, the reason that subscripts are, on _some_ systems, at best, as fast as indexes is because of the optimizer. Multiply is still not as fast as load.
From: William M. Klein on 22 Sep 2007 00:26 "Robert" <no(a)e.mail> wrote in message news:te19f3ll4e7s2qgmr651ru3vfj356879ac(a)4ax.com... > On Thu, 20 Sep 2007 18:27:53 -0700, Richard <riplin(a)Azonic.co.nz> wrote: > >> >>Robert wrote: >>> On Thu, 20 Sep 2007 16:53:29 -0600, LX-i <lxi0007(a)netscape.net> wrote: >>> >>> >>> >You've shown that what used to be significant overhead with subscripts >>> >is now gone in one particular environment. >>> >>> It's gone on all platforms, or soon will be. >> >>Geez, Robert, is this some magic that will replace everyone's >>compilers with brand new ones. Are you walking the streets crying "New >>compilers for old" ? > > Multiplication speed is a function of CPUs, not compilers. A timing test > program could > show different relative speeds, even though it was not recompiled. > Robert, What you refuse to understand is that what "machine instructions" are CREATED by compilers is what (usually) impacts performance in this type of case (not all cases). It is not a matter of how fast a "load" vs a "multiply" is - it is what instructions that the COMPILER creates for specific source code constructs that leads to such performance recommendations. For example, the fact that IBM (and other) compilers DO allow an index-name to be used for tables other than the ones for which they are defined probably (I haven't tested it) impacts the code sequences that they need for such references. Similarly, when using subscripts, even when "bounds checking" is NOT turned on (as a compiler option/directive) there may be other code inserted (check for numeric? sign-checking? etc) that MAY be inserted by a compiler. As far as comparative speeds of single "machine instructions" (hardware, software, microcode, whatever) there may also be "compatibility" issues that prevent a vendor from optimizing "old" instructions and to create "new ones" instead. -- Bill Klein wmklein <at> ix.netcom.com
From: William M. Klein on 22 Sep 2007 00:31 "Robert" <no(a)e.mail> wrote in message news:j629f39red8n9ov4j9cqsidpc3ugmichbj(a)4ax.com... > On Fri, 21 Sep 2007 11:09:16 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > >>"Robert" <no(a)e.mail> wrote in message >>news:i3j6f3pa7ucignv34t4oklno0ht8jh2c5p(a)4ax.com... >>> On Fri, 21 Sep 2007 04:21:35 GMT, "William M. Klein" >>> <wmklein(a)nospam.netcom.com> wrote: >>> >><snip> >>> I and Richard posted facts showing speed is the same. We have not seen facts >>> from >>> mainframe-land,except a five year old study. Just post some facts and skip >>> the >>> ad homina. >> >>I do NOT have personal access to an Enterprise V3.4 COBOL compiler - and I do >>believe what IBM says about its performance (and don't believe that you know >>how >>they implement all their syntax -> machine code). HOWEVER, >> >>If you create a source program that you think tests subscripts vs indexes >>(whether it is comprehensive or not), then I think some CLC person might >>compile >>and run it for you. >> >>Therefore, please create and post a sample program that cleanly compiles with >>the Micro Focus directives: >> NOMF DIALECT(ENTCOBOL) FLAGAS(S) >> >>If you are not using a current-enough version of Server Express to include >>support for the DIALECT directive, then use: >> NOMF ENTCOBOL FLAG(ENTCOBOL) FLAGAS(S) ARITHMETIC(ENTCOBOL) >>PERFORM-TYPE(ENTCOBOL) > > That's not necessary. The code I posted is Standard-compliant except for > comp-5, which we > all know IBM can handle. > Robert, Are you talking about the code with "EXIT PERFORM CYCLE" in it - or did you poas a later sample? If that is the one that you are talking about, please do try compiling it with the directives listed above and see what happens. If there was a later version that conforms to the '85 Standard (not parts of the '02 Standard), then can you re-post it - as I don't seem to have it in my "saved" notes. -- Bill Klein wmklein <at> ix.netcom.com
From: William M. Klein on 22 Sep 2007 00:36
"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message news:wU0Ji.181376$gR1.2091(a)fe03.news.easynews.com... > > "Robert" <no(a)e.mail> wrote in message > news:j629f39red8n9ov4j9cqsidpc3ugmichbj(a)4ax.com... >> On Fri, 21 Sep 2007 11:09:16 GMT, "William M. Klein" >> <wmklein(a)nospam.netcom.com> wrote: >> >>>"Robert" <no(a)e.mail> wrote in message >>>news:i3j6f3pa7ucignv34t4oklno0ht8jh2c5p(a)4ax.com... >>>> On Fri, 21 Sep 2007 04:21:35 GMT, "William M. Klein" >>>> <wmklein(a)nospam.netcom.com> wrote: >>>> >>><snip> >>>> I and Richard posted facts showing speed is the same. We have not seen >>>> facts >>>> from >>>> mainframe-land,except a five year old study. Just post some facts and skip >>>> the >>>> ad homina. >>> >>>I do NOT have personal access to an Enterprise V3.4 COBOL compiler - and I do >>>believe what IBM says about its performance (and don't believe that you know >>>how >>>they implement all their syntax -> machine code). HOWEVER, >>> >>>If you create a source program that you think tests subscripts vs indexes >>>(whether it is comprehensive or not), then I think some CLC person might >>>compile >>>and run it for you. >>> >>>Therefore, please create and post a sample program that cleanly compiles with >>>the Micro Focus directives: >>> NOMF DIALECT(ENTCOBOL) FLAGAS(S) >>> >>>If you are not using a current-enough version of Server Express to include >>>support for the DIALECT directive, then use: >>> NOMF ENTCOBOL FLAG(ENTCOBOL) FLAGAS(S) ARITHMETIC(ENTCOBOL) >>>PERFORM-TYPE(ENTCOBOL) >> >> That's not necessary. The code I posted is Standard-compliant except for >> comp-5, which we >> all know IBM can handle. >> > > Robert, > Are you talking about the code with "EXIT PERFORM CYCLE" in it - or did you > poas a later sample? If that is the one that you are talking about, please do > try compiling it with the directives listed above and see what happens. > > If there was a later version that conforms to the '85 Standard (not parts of > the '02 Standard), then can you re-post it - as I don't seem to have it in my > "saved" notes. I also just noticed that you were using MF's free-form reference format directive, which won't work with IBM mainframe compilers either (unless you used the directive - but not the format. Your code would also fail with any '85 Standard flagging for LOTS of reasons - such as apostrophe rather than quotation marks, GOBACK, etc. This are, however, both part of the '02 Standard and IBM extensions to the '85. Therefore, as I say, once you produce code that compiles cleanly with ENTCOBOL directives, then a mainframe can run a test for you. -- Bill Klein wmklein <at> ix.netcom.com |