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 22 Sep 2007 02:33 On Fri, 21 Sep 2007 21:19:15 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >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 optimize the reuse of subscripts then they >will still be slower. That's easy to check, by compiling with optimization off. It's unrealistic, though, because optimization is on for real-world programs. >> >> > 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. Yes, if the programmer is dumb enough to use the wrong type for subscripts. >> >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. It appears to be on by default for MF. They mention the "OSVS standard", as though IBM were in the business of writing standards. >> >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 if multiply 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: Robert on 22 Sep 2007 02:50 On Sat, 22 Sep 2007 04:26:26 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: > >"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. Nah. They'll just load the index and use it. That's why the two 'reaches' must be the same. >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. I realize this is conjectural, but why would they create a 'fast multiply' to replace the old 'slow multiply'? There's only one way to multiply two binary numbers. Intel would be the prime suspect. They love to create new instructions that do the same thing as old ones.
From: Jeff Campbell on 22 Sep 2007 05:20 Robert wrote: > 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. No, it wasn't. Such things as mixed sectioned, non-sectioned code; exit section statements not in separate paragraphs; linkage section declared without a using clause in the procedure division. I could go on. > >> 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. 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 22 Sep 2007 06:51 "Robert" <no(a)e.mail> wrote in message news:ou49f351cj6a1o0rt5sh6v2o14pr6adb56(a)4ax.com... > On Sat, 22 Sep 2007 02:18:58 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >> >> >>"Robert" <no(a)e.mail> wrote in message >>news:0hg6f3p406f6alsph4s3c2ef5u478bvq2t(a)4ax.com... >>> On Wed, 19 Sep 2007 22:20:43 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >>> >><snip>> >>> I'm throwing schoolboy insults at mainframers because they destroyed the >>> programming >>> language I love. >>> >>> I could easily have become a C, C++, C# or Java programmer. I did it >>> full >>> time for a year. >>> I didn't love it like Cobol. >>> >>Could you explain how mainframe COBOL programmers destroyed COBOL, >>exactly? >> >>I am genuinely interested in your viewpoint, not looking for an argument. > > 1. Resistance to change. > > Applies to application code as well as language features. As a result, > simple changes take > too long and cost too much. > > 2. Substandard programming skill. > > In the mainframe/Cobol world, it is common to hear programmers say they > are confused by > complex conditionals and by NOT. That's not found in the culture of any > other programming > language. If a C# or Java contractor said that, he'd be fired for > unsuitability. Logic is > the foundation of programming. A programmer lacking logic skills is like > an accountant > lacking arithmetic skills. > > That's why in shops that do Real Programming, Cobol programmers are > regarded as deadheads. > Others mistakenly ascribe it to the language. They don't realize (or are > too polite to > say) it's really an attribute of the Cobol culture, most notably in > mainframe shops > > 3. Programming standards that institutionalize bad programming and > prohibit good > programming. > > That's how they enforce 1. and defend 2. > > 4. Methodology (waterfall) that obstructs change. Testing standards that > prevent reusable > code. > > None of these are inherent to the Cobol language, but they found root in > the > mainframe/Cobol culture. I've worked at and managed mainframe Cobol shops > that didn't have > these deficiencies. Nowadays, such shops are running Unix. Thanks for the response, Robert. I believe I have raised all of the above on various occasions in this forum, so I cannot totally disagree with you. Certainly, I have encountered all 4 of the points above in various places, and, on a few occasions, in the one place :-) I don't personally believe that these 4 things alone brought about the demise of COBOL (I still believe that was a number of factors, the primary one being missing the paradigm shift), but I do believe that none of them helped COBOL or COBOL credibility. I promised not to argue, so I won't, and I DO appreciate you honestly stating what you believe, whether I agree or not. :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 22 Sep 2007 07:20
"Robert" <no(a)e.mail> wrote in message news:1fs8f3pd7mmkhnnf1s26a01df4bprbdr4f(a)4ax.com... > On Fri, 21 Sep 2007 12:48:55 -0600, Howard Brazee <howard(a)brazee.net> > wrote: > >>On Thu, 20 Sep 2007 19:46:02 -0500, Robert <no(a)e.mail> wrote: >> >>>Unexpectedly, the demand and pay for PL/SQL is sky high. It's number two >>>after Java, ahead >>>of C++ and dot-net. Evidently there are shops that write everything in >>>PL/SQL and SQR. How >>>desperate and sad. >> >>Why desperate? >> >>Sure, I would have more power if there was greater demand for my >>skills, but I'm not selfish enough to wish the world would be designed >>around me. (Unlike certain politicians) > > Because SQL isn't generalized enough to 'do everything'. It has difficulty > doing things > that are easy in traditional programming languages. If the only tool you > have is a > database query language, every problem looks like a query problem. Have you looked at the latest standard for SQL? It is very hard to distinguish from a programming language. Pete. -- "I used to write COBOL...now I can do anything." |