Home > Archive > Cobol > October 2007 > COBOL myth busted, index versus subscript (MF on HP)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
COBOL myth busted, index versus subscript (MF on HP)
|
|
| Robert 2007-09-17, 6:55 pm |
|
* ------ Speed of subscript v. index
------------------------------------------------------
* Findings
* Index 23
* Subscript 23
* Subscript comp-5 23
* Index 1 23
* Subscript 1 18
* Subscript 1 comp-5 18
* The last two are faster because the optimizer figured out
* it didn't need to Store the subscript on every iteration.
* It could have done that on the first four, as well.
$SET SOURCEFORMAT"FREE"
$SET NOBOUND
$SET OPT"2"
$SET NOTRUNC
$SET IBMCOMP
$SET NOCHECK
$SET ALIGN"8"
identification division.
program-id. Speed2.
author. Robert Wxagner.
data division.
working-storage section.
01 test-data.
05 comp5-number comp-5 pic s9(09) sync.
05 binary-number binary pic s9(09) sync.
05 display-number pic 9(09).
05 packed-number comp-3 pic s9(09).
05 s-subscript binary pic s9(09) sync.
05 test-byte pic x(01).
01 misaligned-area.
05 array-element occurs 4096 indexed x-index.
10 misaligned-number comp-5 pic s9(09).
10 to-cause-misalignment pic x(01).
05 byte-element occurs 4096 indexed x-index-1 pic x.
01 timer-variables.
05 test-name pic x(30).
05 repeat-factor value 100000000 binary pic s9(09).
05 current-date-structure.
10 pic x(08).
10 time-now-hhmmsshh.
15 hours pic 9(02).
15 minutes pic 9(02).
15 secs pic 9(02).
15 hundredths pic v9(02).
10 pic x(05).
05 time-now pic 9(06)v99.
05 time-start pic 9(06)v99.
05 timer-overhead value zero pic 9(06)v99.
05 elapsed-time pic s9(06)v99.
05 elapsed-time-display.
10 elapsed-time-edited pic z(05).
procedure division.
initialize test-data, misaligned-area
move 'Null test' to test-name
perform timer-on
perform timer-on
perform repeat-factor times
exit perform cycle
end-perform
perform timer-off
compute timer-overhead = (time-now - time-start)
move 'Index' to test-name
set x-index to 1000
perform timer-on
perform repeat-factor times
if x-index = 1000
set x-index up by 1
else
set x-index down by 1
end-if
move array-element (x-index) to test-byte
exit perform cycle
end-perform
perform timer-off
move 'Subscript' to test-name
move 1000 to s-subscript
perform timer-on
perform repeat-factor times
if s-subscript = 1000
add 1 to s-subscript
else
subtract 1 from s-subscript
end-if
move array-element (s-subscript) to test-byte
exit perform cycle
end-perform
perform timer-off
move 'Subscript comp-5' to test-name
move 1000 to comp5-number
perform timer-on
perform repeat-factor times
if comp5-number = 1000
add 1 to comp5-number
else
subtract 1 from comp5-number
end-if
move array-element (comp5-number) to test-byte
exit perform cycle
end-perform
perform timer-off
move 'Index 1' to test-name
set x-index-1 to 1000
perform timer-on
perform repeat-factor times
if x-index-1 = 1000
set x-index-1 up by 1
else
set x-index-1 down by 1
end-if
move byte-element (x-index-1) to test-byte
exit perform cycle
end-perform
perform timer-off
move 'Subscript 1' to test-name
move 1000 to s-subscript
perform timer-on
perform repeat-factor times
if s-subscript = 1000
add 1 to s-subscript
else
subtract 1 from s-subscript
end-if
move byte-element (s-subscript) to test-byte
exit perform cycle
end-perform
perform timer-off
move 'Subscript 1 comp-5' to test-name
move 1000 to comp5-number
perform timer-on
perform repeat-factor times
if comp5-number = 1000
add 1 to comp5-number
else
subtract 1 from comp5-number
end-if
move byte-element (comp5-number) to test-byte
exit perform cycle
end-perform
perform timer-off
goback
. timer-on.
perform read-the-time
move time-now to time-start
. timer-off.
perform read-the-time
compute elapsed-time rounded = ((time-now - time-start)
* 100000000 / repeat-factor) - timer-overhead
if elapsed-time not greater than zero
move 'error' to elapsed-time-display
else
compute elapsed-time-edited rounded = elapsed-time * 10
end-if
display test-name elapsed-time-display
. read-the-time.
accept time-now-hhmmsshh from time
*> move function current-date to current-date-structure
compute time-now =
((((hours * 60) +
minutes) * 60) +
secs) +
hundredths
| |
| Richard 2007-09-17, 9:55 pm |
| On Sep 18, 11:43 am, Robert <n...@e.mail> wrote:
> * ------ Speed of subscript v. index
> ------------------------------------------------------
> * Findings
>
> * Index 23
> * Subscript 23
> * Subscript comp-5 23
> * Index 1 23
> * Subscript 1 18
> * Subscript 1 comp-5 18
>
> * The last two are faster because the optimizer figured out
> * it didn't need to Store the subscript on every iteration.
So, how many iterations of rewriting code that does nothing useful did
you need to find something that your compiler could optimize away ?
Once again you prove that if you want to waste time then subscript
does it better, but only on your system.
| |
| Doug Miller 2007-09-18, 7:55 am |
| In article <vn3ue39t5tjeauiv8pnsfsd6asks2mdlc6@4ax.com>, Robert <no@e.mail> wrote:
>
>* ------ Speed of subscript v. index
>------------------------------------------------------
>* Findings
[invalid findings snipped]
You *still* haven't fixed the problem in this test which I pointed out to you
w s ago: by using the *same* array for both indexed and subscripted access,
you have failed to eliminate the possibility that the presence of the INDEXED
BY clause in the definition of the array causes the compiler to emit the same
code for both indexed and subscripted access.
You *cannot* have a valid comparison of the speeds of indexed and subscripted
accesses unless you use two *separate* arrays, identically defined except for
the presence of an INDEXED BY clause in one, and its absence in the other.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Robert 2007-09-18, 9:55 pm |
| On Tue, 18 Sep 2007 12:14:57 GMT, spambait@milmac.com (Doug Miller) wrote:
>In article <vn3ue39t5tjeauiv8pnsfsd6asks2mdlc6@4ax.com>, Robert <no@e.mail> wrote:
>
>[invalid findings snipped]
>
>You *still* haven't fixed the problem in this test which I pointed out to you
>ws ago: by using the *same* array for both indexed and subscripted access,
>you have failed to eliminate the possibility that the presence of the INDEXED
>BY clause in the definition of the array causes the compiler to emit the same
>code for both indexed and subscripted access.
>
>You *cannot* have a valid comparison of the speeds of indexed and subscripted
>accesses unless you use two *separate* arrays, identically defined except for
>the presence of an INDEXED BY clause in one, and its absence in the other.
You are wrong. Common sense tells me an INDEXED clause on a table accessed by subscript
does not cause the compiler to "emit the same code". If your delusion persists, it's easy
though to add another array to the test and post the results here. I'm confident the
resulting speed will be the same.
| |
| Charles Hottel 2007-09-18, 9:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:b5r0f3tcgt8lrjp54f98vmus9c06q6d7pl@
4ax.com...
> On Tue, 18 Sep 2007 12:14:57 GMT, spambait@milmac.com (Doug Miller) wrote:
>
>
> You are wrong. Common sense tells me an INDEXED clause on a table accessed
> by subscript
> does not cause the compiler to "emit the same code". If your delusion
> persists, it's easy
> though to add another array to the test and post the results here. I'm
> confident the
> resulting speed will be the same.
It made very little difference when I tried it.
| |
| Doug Miller 2007-09-19, 3:55 am |
| In article <b5r0f3tcgt8lrjp54f98vmus9c06q6d7pl@4ax.com>, Robert <no@e.mail> wrote:
>On Tue, 18 Sep 2007 12:14:57 GMT, spambait@milmac.com (Doug Miller) wrote:
>
> wrote:
>
>You are wrong.
You are arrogant. And with so little reason to be.
My statement that your testing has failed to eliminate that possibility is
absolutely 100% correct.
> Common sense tells me an INDEXED clause on a table accessed by subscript
>does not cause the compiler to "emit the same code".
You don't know that. You might be right, and you might not be.
Your arrogance has deluded you into confusing what you suppose reality to be,
with what reality actually is, and deceived you into believing that they are
the same. They may well be the same in this case, but, until you actually test
to see if that is so, you're just guessing.
Particularly considering your track record of staggeringly slipshod
construction of test cases, and even more slipshod interpretation of the
results, I think I can be pardoned for my unwillingness to accept your
conjectures as fact until supported by actual evidence.
>If your delusion persists,
> it's easy though to add another array to the test and post the results here.
It's been about two ws since I first pointed out that flaw in your testing.
What's taking you so long?
> I'm confident the resulting speed will be the same.
Maybe it will. But until you actually test it, you don't know -- which has
been my point all along: you have no basis for drawing the conclusion you've
drawn, because you have not eliminated alternative explanations.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Robert 2007-09-19, 7:55 am |
| On Wed, 19 Sep 2007 02:59:50 GMT, spambait@milmac.com (Doug Miller) wrote:
>In article <b5r0f3tcgt8lrjp54f98vmus9c06q6d7pl@4ax.com>, Robert <no@e.mail> wrote:
>
>You are arrogant. And with so little reason to be.
>
>My statement that your testing has failed to eliminate that possibility is
>absolutely 100% correct.
Absolutely 100%? That kind of rhetoric is a tip off you're full of shit. I'm receptive to
reasonable scepticism, but if you come on like a jerk, you're on your own.
>
>You don't know that. You might be right, and you might not be.
>
>Your arrogance has deluded you into confusing what you suppose reality to be,
>with what reality actually is, and deceived you into believing that they are
>the same. They may well be the same in this case, but, until you actually test
>to see if that is so, you're just guessing.
>
>Particularly considering your track record of staggeringly slipshod
>construction of test cases, and even more slipshod interpretation of the
>results, I think I can be pardoned for my unwillingness to accept your
>conjectures as fact until supported by actual evidence.
Oh my god. Not just slipshod but STAGGERNGLY shipshod, as though the adjective makes your
claim more credble.
>
>
>It's been about two ws since I first pointed out that flaw in your testing.
>What's taking you so long?
What's taking YOU so long?
| |
| Doug Miller 2007-09-19, 7:55 am |
| In article <bot1f31vdj27eetrfek904rdnhtbeloo66@4ax.com>, Robert <no@e.mail> wrote:
>On Wed, 19 Sep 2007 02:59:50 GMT, spambait@milmac.com (Doug Miller) wrote:
>
> wrote:
> you
> access,
> INDEXED
> same
> subscripted
> for
>
>Absolutely 100%? That kind of rhetoric is a tip off you're full of shit.
Please explain in what respect that statement is incorrect. You *did* fail to
exclude the possibility.
> I'm receptive to
>reasonable scepticism,
No, you're not. If you were, you'd fix the problems in your test protocols,
instead of arguing with the people who point out the flaws in their
construction.
> but if you come on like a jerk, you're on your own.
Quoting you:
"You are wrong."
"... you're full of shit."
And *you* accuse *me* of coming on like a jerk?
>
>
>Oh my god. Not just slipshod but STAGGERNGLY shipshod, as though the adjective
> makes your claim more credble.
Your arrogant attitude might be forgivable if it were justified.
My claim that your test construction is slipshod is more than simply
"credible". It's thoroughly established. I've already described, in some
detail, the serious flaws in your construction of your test cases, and in your
misinterpretation of the results.
>
>What's taking YOU so long?
Since when did it become *my* responsibility to remedy the flaws in *your*
testing protocols?
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
|
| In article <bot1f31vdj27eetrfek904rdnhtbeloo66@4ax.com>,
Robert <no@e.mail> wrote:
>On Wed, 19 Sep 2007 02:59:50 GMT, spambait@milmac.com (Doug Miller) wrote:
[snip]
>
>Absolutely 100%? That kind of rhetoric is a tip off you're full of shit.
>I'm receptive to
>reasonable scepticism, but if you come on like a jerk, you're on your own.
Oh, I *cannot* resist...
.... really, Mr Wagner, seeing how readily you, yourself, were accomodated
you might readily conclude that there's more than enough room for a
couple-three more folks who 'come on like a jerk'.
[snip]
>
>What's taking YOU so long?
Answering a question with a question, Mr Wagner, is no answer at all.
DD
| |
| Vivian 2007-10-17, 6:55 pm |
| Very interesting test. For comparison purposes, I ran Robert's code
on our ancient mainframe (it's a very old slow box). Since I too was
curious about an array without an index defined, I created another
iteration of the test, to do the same 2 tests with an non-indexed
array. Here's my results:
NULL TEST 77
INDEX 93
SUBSCRIPT 150
SUBSCRIPT COMP-5 184
INDEX 1 52
SUBSCRIPT 1 118
SUBSCRIPT 1 COMP-5 154
NON-INDX 1 108
NON-INDEXED COMP-5 149
So it would appear on my box that an aligned index is fastest. But
interestingly, simply defining an index slows you down if you intend
to use a subscript. At least that's what happens on an MP3000.
So, Question, what is exit perform cycle? It gave me a compiler error
so I commented it out. Would that effect the results?
| |
| HeyBub 2007-10-17, 6:55 pm |
| Vivian wrote:
> So, Question, what is exit perform cycle? It gave me a compiler error
> so I commented it out. Would that effect the results?
EXIT PERFORM is just what it says: Immediately exit the perform loop. It's
roughly equivalent to:
PERFORM VARYING MYINDX FROM 1 BY TO UNTIL MYINDX > 1000
(some processing here)
IF (some condition)
MOVE 1000 TO MYINDX
END-IF
END-PERFORM.
| |
| Robert 2007-10-17, 6:55 pm |
| On Wed, 17 Oct 2007 17:54:03 -0500, "HeyBub" <heybubNOSPAM@gmail.com> wrote:
>Vivian wrote:
>
>EXIT PERFORM is just what it says: Immediately exit the perform loop. It's
>roughly equivalent to:
>
>
> PERFORM VARYING MYINDX FROM 1 BY TO UNTIL MYINDX > 1000
> (some processing here)
> IF (some condition)
> MOVE 1000 TO MYINDX
> END-IF
> END-PERFORM.
EXIT PERFORM does that. EXIT PERFORM CYCLE exits the iteration; PERFORM will go on to the
next iteration.
PERFORM VARYING MYINDX FROM 1 BY TO UNTIL MYINDX > 1000
IF DELETED-ENTRY (MYINDX)
EXIT PERFORM CYCLE
END-IF
(some processing)
END-PERFORM.
| |
| Robert 2007-10-17, 6:55 pm |
| On Wed, 17 Oct 2007 12:24:09 -0700, Vivian <vsaegesser@infogix.com> wrote:
>Very interesting test. For comparison purposes, I ran Robert's code
>on our ancient mainframe (it's a very old slow box). Since I too was
>curious about an array without an index defined, I created another
>iteration of the test, to do the same 2 tests with an non-indexed
>array. Here's my results:
>
>NULL TEST 77
>INDEX 93
>SUBSCRIPT 150
>SUBSCRIPT COMP-5 184
>INDEX 1 52
>SUBSCRIPT 1 118
>SUBSCRIPT 1 COMP-5 154
>NON-INDX 1 108
>NON-INDEXED COMP-5 149
>
>So it would appear on my box that an aligned index is fastest. But
>interestingly, simply defining an index slows you down if you intend
>to use a subscript. At least that's what happens on an MP3000.
>
>So, Question, what is exit perform cycle? It gave me a compiler error
>so I commented it out. Would that effect the results?
When I first ran the test, the null loop was empty. Micro Focus' optimizer was smart
enough to optimize it down to zero time. As a result, I had no measurement of loop
overhead to subtract. Exit perform cycle was added to make it go around the null loop
repeat-factor times. Since it was in the null loop's time, I had to add it to all the
other loops.
In your case, exit perform cycle was not necessary, so deleting it did not affect the
results.
I don't understand how defining an unused index could affect the speed of a subscripted
access. Can you compare generated code to see what the extra instruction does? What is
comp-5 and why is it slower?
| |
| Vivian 2007-10-26, 6:55 pm |
| On Oct 17, 6:55 pm, Robert <n...@e.mail> wrote:
> On Wed, 17 Oct 2007 12:24:09 -0700, Vivian <vsaeges...@infogix.com> wrote:
>
>
>
>
> When I first ran the test, the null loop was empty. Micro Focus' optimizer was smart
> enough to optimize it down to zero time. As a result, I had no measurement of loop
> overhead to subtract. Exit perform cycle was added to make it go around the null loop
> repeat-factor times. Since it was in the null loop's time, I had to add it to all the
> other loops.
>
> In your case, exit perform cycle was not necessary, so deleting it did not affect the
> results.
>
> I don't understand how defining an unused index could affect the speed of a subscripted
> access. Can you compare generated code to see what the extra instruction does? What is
> comp-5 and why is it slower?- Hide quoted text -
>
> - Show quoted text -
Comp-5 is native binary. I failed to mention earlier I'm in
Enterprise Cobol 3.3 (on an MP3000 box running z/OS 1.4). Comp-5 is
like "normal" comp, but it can store up to the max that fits in the
native binary representation, rather than being limited to the value
implied in the picture clause.
I would guess, and it's just my guess, that the index is actually
being set everytime you reference the table entry, whether you use the
index or not. But, I don't know for sure, that's all I can think of
that could be happening to produce the results I got. I could post
the generated code, but what do you want to see? A pmap? that's like
reading assembler. I don't "speak" assembler. If you really want it,
I'll recompile and post it next w.
Vivian
| |
| Robert 2007-10-26, 9:55 pm |
| On Fri, 26 Oct 2007 14:01:09 -0700, Vivian <vsaegesser@infogix.com> wrote:
>On Oct 17, 6:55 pm, Robert <n...@e.mail> wrote:
>
>Comp-5 is native binary. I failed to mention earlier I'm in
>Enterprise Cobol 3.3 (on an MP3000 box running z/OS 1.4). Comp-5 is
>like "normal" comp, but it can store up to the max that fits in the
>native binary representation, rather than being limited to the value
>implied in the picture clause.
I asked because comp-5 is unexpectedly SLOWER than 'normal' COMP or BINARY. It should be
faster. Something is wrong with this picture, or you found a big inefficiency in IBM's
compiler.
Comp-5 is native binary on Micro Focus and Fujitsu, as well. There it runs the same or
slightly faster, depending on compiler options.
>I would guess, and it's just my guess, that the index is actually
>being set everytime you reference the table entry, whether you use the
>index or not. But, I don't know for sure, that's all I can think of
>that could be happening to produce the results I got.
If it changed the index, code that used the index wouldn't work right. That cannot be the
explanation.
> I could post
>the generated code, but what do you want to see? A pmap? that's like
>reading assembler. I don't "speak" assembler. If you really want it,
>I'll recompile and post it next w.
The whole pmap would be too big. The speed difference is so small, it's probably one or
two additional instructions. If you want to compare the two and post the difference plus a
few instructions before and after, it's likely assembly language experts here can figure
out why they were generated.
| |
| William M. Klein 2007-10-27, 6:55 pm |
| "Robert" <no@e.mail> wrote in message
news:ru25i3l71kth1cplg1k1f8cb1d5uqqd9gc@
4ax.com...
> On Fri, 26 Oct 2007 14:01:09 -0700, Vivian <vsaegesser@infogix.com> wrote:
<snip>
> I asked because comp-5 is unexpectedly SLOWER than 'normal' COMP or BINARY. It
> should be
> faster. Something is wrong with this picture, or you found a big inefficiency
> in IBM's
> compiler.
ABSOLUTELY NOT TRUE for IBM (mainframe).
IBM documents that COMP (with TRUNC(OPT) compiler option) is USUALLY faster than
COMP-5. COMP-5 is faster than COMP with TRUNC(BIN) - at least in some cases.
The code that IBM generates for COBOL is based on the assumption that people
actually MEAN what they code in the PICTURE clause. They have to do
"additional" object code to handle cases where the field MIGHT include data
larger than the PICTURE specifies.
I am certain that I have pointed you (RW) to the IBM performancer paper that
talks about all of this. See the section on COMP-5 where it says it is treated
like COMP with TRUNC(BIN) and then read the section that starts,
"When using the TRUNC(BIN) compiler option, all binary (COMP) sending fields are
treated as either halfword, fullword, or doubleword values, depending on the
PICTURE clause, and code is generated to truncate all binary receiving fields
to the corresponding halfword, fullword, or doubleword boundary (base 2
truncation). The full content of the field is significant. This can add a
significant amount of degradation since typically some data conversions must be
done, which may require the use of some library subroutines. BIN is usually the
slowest of the three sub options for TRUNC."
I know that this differs from COMP-5 on other platforms, but this IS how IBM has
implemented (and doucmented it).
If you (RW) need to get the IBM performanc paper again, I can give you the URL.
The fact that COMP-5 and TRUNC(BIN) are slowest - is also documented elsewhere
within the IBM documentation (and I can provide references for that as well).
--
Bill Klein
wmklein <at> ix.netcom.com
|
|
|
|
|