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 16 Sep 2007 18:33 On Sun, 16 Sep 2007 00:26:57 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq(a)4ax.com>, >Robert <no(a)e.mail> wrote: >>On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >> >>>On Sep 15, 6:50 pm, Robert <n...(a)e.mail> wrote: >>>> On Fri, 14 Sep 2007 22:51:45 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >[snip] > >>>> >Just why is 'index is faster than subscript' a myth, again ? >>>> >>>> 1. Because a timing test showed indexes are slower. >>> >>>And you have done a timing test on every machine in the universe. >> >>If humans were unable to generalize, there wouldn't be any machines. >>We'd be living in >>shacks and tents. > >What Mr Plinston puts forward, Mr Wagner, may demonstrate why there is a >season to things and a time to every purpose. The above might be phrased >otherwise and yet still retain some original flavor, eg: > >A: Just why is 'index is faster than subscript' a myth, again ? > >B: Because a timing test showed indexes are slower. > >A: '*A* timing test' (emphasis added) shows that under *a* set of >conditions one might not be better than the other; it is possible that >under other sets of conditions the other might be better than the one. I tried to make the tests represent typical usage AND I posted source code. If you think the test is unfair, say so or write your own test. Thanks to Richard's complaints, I saw the subscript test did NOT represent typical usage, so I'll fix it and rerun. >>The Micro Focus page is generalized advice. Write and tell them >>generalization is BAD. > >Leaving aside the Brooklyn Bridge nature of this argument - 'Micro Focus >jumps off the Brooklyn Bridge, you will, too?' - one might believe that >when Micro Focus (or an appropriate representative thereof) comes >a-posting here the responses might be the same. I have no problem with generalizations, nor do I fault Micro Focus for making them. I think a few of the SPECIFIC points are erroneous, because they're based on commonly held belief (myth). >>They shouldn't give advice until they test on every machine. > >It has been advised that one should tend to their own garden first, Mr >Wagner, before one tends to Micro Focus'... or something like that. We all plant our crops in the soil plowed by Micro Focus .. or something like that. >>>> 2. Because multiplication is now as fast as loading an index. >>> >>>I didn't notice the elves coming in and doing that to my machine. >> >>You need to upgrade that '386. > >Only 486 and above are elf-compatible, sure! The elf is superscalar, which means multiple instructions per clock. Itanium (formerly IA-64) is a radical change in CPU design. Many don't know its basic design originated in HP, where it was named EPIC, not in Intel. It has been an underperformer in sales and missed deadlines, but in execution speed it is noticably faster than others. No chip maker has attempted to copy it. Surprisingly, Intel does not make the companion "chipset" required to use the Itanium on a motherboard. Today, most chipsets are made by HP. Silicon Graphics (SGI) is another big supporter. If Itanium is unsuccessful, CPUs are close to hitting the wall in terms of speed. We can't make them much more complex (required to avoid instruction collisions) because we can't make traces much smaller. We're approaching the size of atoms.
From: William M. Klein on 16 Sep 2007 21:15 Robert, For what compiler? What operating systems? And your evidence is ...? Of course, we all KNOW that there is no such thing as a "guaranteed" BINARY search. (SEARCH ALL is not guaranteed to be "binary"). -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:hvrqe394mgcejqa6bgfvu4ge141tmqtima(a)4ax.com... > On Mon, 17 Sep 2007 01:17:37 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > > >>(BTW, the reason I use indexes is not for any of the reasons you described; >>I simply like INDEXED BY and SEARCH. Having gone to the trouble of defining >>an index for a table it seems impolite to then use a subscript... :-)) >>Couldn't care less whether they're faster or slower; on modern hardware it >>makes very little difference, and even if it did, I'd still do it. Because I >>can.:-)) > > I hope you use ODO on 'high speed' SEARCHes. If not, they're taking twice as > long as they > should for serial, 10% longer for binary. >
From: William M. Klein on 16 Sep 2007 21:23 "Robert" <no(a)e.mail> wrote in message news:k27re3tjim0q8bsqadfn1ehagf4ko407pj(a)4ax.com... > On Sun, 16 Sep 2007 06:01:20 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > >> >>"Robert" <no(a)e.mail> wrote in message >>news:rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq(a)4ax.com... >>> On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >><snip> >>> >>> The Micro Focus page is generalized advice. Write and tell them >>> generalization >>> is BAD. >>> They shouldn't give advice until they test on every machine. >> >>Robert, >> You didn't originally CLAIM this(use index not subscript) was in any Micro >>Focus documentation. Do you now claim it is in the Micro Focus documentation >>and if so where? > > Micro Focus does not say indexes are faster, in the efficiency tips nor > elsewhere. Many > Cobol programmers still believe it, because it was true in the Old Days. > >>(Some - but not all - of your original comments WERE about MF documentation - >>and I would certainly say that some customer who has the relevant >>documentation >>and compiler should send in a comment complaining about it. It is worth >>noting >>that NONE of the "efficiency" recommendations from your original note were in >>the Net Express documentation. It - as far as I can tell - never comments on >>this topic.) > > Most of the recommendations are valid, at least on most platforms. I tested > the ones that > didn't sound right to me. > >>P.S. IBM has some interesting documentation for their z/OS COBOL compiler. >>For >>example, >> >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/8.1.3.1 >> >>talks about some of the table reference optimizaiton that the compiler does do >>(and therefore what types of code/structures they recommend using for optimal >>performancer). >> >> while >> >>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/8.1.3 >> >>does recommend the use of indexing over subscripts >> >>However, they also "back this up" with the performance statistics that support >>this, i.e. >> >> "using binary data items (COMP) to address a table is 30% slower than using >>indexes" > > Relative speeds are changing. Subscripting was about 500% slower in the Old > Days. I don't > doubt it WAS 30% slower when the above was written. My point is that > subscripts are not > slower on modern machines. You are trying to claim that the zSeries is NOT a "modern machine". Your statement, "Many Cobol programmers still believe it, because it was true in the Old Days." It is still true on the environment where the recommendation is still documented, i.e. IBM mainframe compilers. (If you haven't researched it, although the pointed to "Performance Guide" is for Enterprise COBOL V3.1 and the compiler is now on V3.4, IBM is on record as indicating that there have been few "performance" enhancements between these releases. As you have acknowledged elsewhere, your guess is that somewhere ABOUT 70% of all COBOL code that is running today is on IBM mainframes (and I would guess that it is certainly OVER 50^) then it is true that for majority of COBOL code, the use of indices is to be preferred (for performance purposes) than subscripts. And of course, even your own test showed that indices are MINIMALLY faster than subscripts, so the real question should be WHY would you ever use subscripts where you could use indices?
From: Robert on 16 Sep 2007 21:39 On Mon, 17 Sep 2007 01:15:35 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >Robert, > For what compiler? What operating systems? And your evidence is ...? It's true for every compiler and operating system. Telling Cobol to search 1,000 rows when half of them are filled with high values will take log2 1,000 / log2 500 times as long. Roughly 10% longer. No timing test is necessary, although I'm tempted to write one just for fun. Deductive logic OR common sense should tell you that. >Of course, we all KNOW that there is no such thing as a "guaranteed" BINARY >search. (SEARCH ALL is not guaranteed to be "binary"). That's true in Standard-land. In Reality-land, every compiler does a binary search. I spent years trying to prove that 2 is not the optimal division factor. Based on calculus, I really believed it was e - 1, which is approximately 1.7. I almost 'proved' it with tests. Years later I saw that 2 really IS the optimal division factor. On well, I tried.
From: William M. Klein on 16 Sep 2007 21:43
An ODO is ONLY faster if the number of "filled in" table entries varies. If the number of entries is stable AND all entries are filled in (which is the most common situation in the SEARCH ALL programs that I have seen). For serial SEARCHes where the "empty" entries are at the end, I can't see how or why an ODO would ever be faster. P.S. If you search the records of this group, there ARE compilers that have used non-Binary searches for SEARCH ALL. However, I do agree that no one has been able to point out any that are still sold/distributed that do so today. -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:7jlre31oq6blvdmk49jl2974tctunhkr43(a)4ax.com... > On Mon, 17 Sep 2007 01:15:35 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > >>Robert, >> For what compiler? What operating systems? And your evidence is ...? > > It's true for every compiler and operating system. Telling Cobol to search > 1,000 rows when > half of them are filled with high values will take log2 1,000 / log2 500 times > as long. > Roughly 10% longer. > > No timing test is necessary, although I'm tempted to write one just for fun. > Deductive > logic OR common sense should tell you that. > >>Of course, we all KNOW that there is no such thing as a "guaranteed" BINARY >>search. (SEARCH ALL is not guaranteed to be "binary"). > > That's true in Standard-land. In Reality-land, every compiler does a binary > search. > > I spent years trying to prove that 2 is not the optimal division factor. Based > on > calculus, I really believed it was e - 1, which is approximately 1.7. I almost > 'proved' > it with tests. Years later I saw that 2 really IS the optimal division factor. > On well, I > tried. |