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: Richard on 14 Sep 2007 00:51 On Sep 14, 4:02 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > And one final note, Robert never claimed that Micro Focus documented Indices as > faster than Subscripts (for their product). He only included this as a "legacy" > belief. It may well be that on particular machines with particular implementations the indexes _are_ faster. Users of those systems, whether they be 'legacy' or not are not 'believing in a myth'. For the rest, Robert never established that it is actually "widely believed" and certainly not 'wrongly believed', merely asserting it to be so in order to denigrate the "Cobol community" by implying that they are too stupid to test it. Of course it is possible to make subscripts slower by, for example, having them as display, or indeed other than comp-5. It may well be that in 'legacy' versions of MF, such as Level II which had index but not comp-5 the so-called "myth" was completely true.
From: Richard on 15 Sep 2007 01:51 On Sep 15, 2:56 pm, Robert <n...(a)e.mail> wrote: > The basic difference is that subscript requires multiplication > whereas index does not. SETTING an index does a multiplication, same as USING a subscript. > I'm not surprised times are the same. So, if for example, several array items were accessed for each SET then with indexes there would be one multiply and several accesses but with subscripts there would be several multiplys. Just why is 'index is faster than subscript' a myth, again ? Actually it is likely that a compiler could optimize the use of subscripts by noticing that the value hadn't changed. So _if_ the compiler optimizes well then they may be same speed, if not, or if some other code interferes with the optimizer, index will be at worst the same and may be faster. So not only did you not establish adequately that it was a myth you still haven't identified anyone who _wrongly_ believes it.
From: Robert on 15 Sep 2007 02:50 On Fri, 14 Sep 2007 22:51:45 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >On Sep 15, 2:56 pm, Robert <n...(a)e.mail> wrote: > >> The basic difference is that subscript requires multiplication >> whereas index does not. SETTING an index does a multiplication, same as USING a subscript. >> I'm not surprised times are the same. > >So, if for example, several array items were accessed for each SET >then with indexes there would be one multiply and several accesses but >with subscripts there would be several multiplys. There would probably be one multiply on the subscript because the optimizer would use that value on subsequent accesses. (I wrote that before reading your paragraph below sayig the same thing.) >Just why is 'index is faster than subscript' a myth, again ? 1. Because a timing test showed indexes are slower. 2. Because multiplication is now as fast as loading an index. >Actually it is likely that a compiler could optimize the use of >subscripts by noticing that the value hadn't changed. So _if_ the >compiler optimizes well then they may be same speed, if not, or if >some other code interferes with the optimizer, index will be at worst >the same and may be faster. Subscript was faster in my test because the subscript was optimized but the index apparently was not. It appears the code was reloading the index on every iteration. >So not only did you not establish adequately that it was a myth you >still haven't identified anyone who _wrongly_ believes it. Most people who use indexes believe it. Why else would they use indexes?
From: Robert Jones on 15 Sep 2007 05:53 On Sep 15, 7:50 am, Robert <n...(a)e.mail> wrote: > On Fri, 14 Sep 2007 22:51:45 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >On Sep 15, 2:56 pm, Robert <n...(a)e.mail> wrote: > > >> The basic difference is that subscript requires multiplication > >> whereas index does not. SETTING an index does a multiplication, same as USING a subscript. > >> I'm not surprised times are the same. > > >So, if for example, several array items were accessed for each SET > >then with indexes there would be one multiply and several accesses but > >with subscripts there would be several multiplys. > > There would probably be one multiply on the subscript because the optimizer would use that > value on subsequent accesses. (I wrote that before reading your paragraph below sayig the > same thing.) > > >Just why is 'index is faster than subscript' a myth, again ? > > 1. Because a timing test showed indexes are slower. > 2. Because multiplication is now as fast as loading an index. > > >Actually it is likely that a compiler could optimize the use of > >subscripts by noticing that the value hadn't changed. So _if_ the > >compiler optimizes well then they may be same speed, if not, or if > >some other code interferes with the optimizer, index will be at worst > >the same and may be faster. > > Subscript was faster in my test because the subscript was optimized but the index > apparently was not. It appears the code was reloading the index on every iteration. > > >So not only did you not establish adequately that it was a myth you > >still haven't identified anyone who _wrongly_ believes it. > > Most people who use indexes believe it. Why else would they use indexes? I think many programmers read the programmer's guide for the compiler and not unnaturally tend to believe its recommendations without the need to test them unless there are obvious reasons to do so.
From: Anonymous on 15 Sep 2007 20:26
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. > >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. >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. > >>> 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! DD |