About performance on Initialize, we demanded not to use this instruction and replace it by MOVE group of items.
But I have just tested the two solutions and I'm very surprised do find out this result :
for 1 000 000 000 iterations :
1- Initialize of a group of 40 items : 76,5 s CPU
2- MOVE into the same group of values identical group but with values (spaces or zeros) : 160 s CPU
3- MOVE item by item (40) : 176 s CPU
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Interesting. . .
It would be informative to see what code the compiler generated for each case. My guess is that the "initialize" generated a set of data and instructions that executes using less cpu than the "single" group move - moving a group actually moves one character at a time internally and some arithmetic instructions are faster than a move. How much of the data was comp-3 or comp?
Just curious, but how long is the group field? Are there 3 programs or is this all in one program?
For each test I ran the same program (same loop), putting in commentary the previous code.
I also tested COMPUTE A = A -1 with ADD -1 TO A, but it was exactly the same CPU time, although I was told COMPUTE is less performant than "native" arithmetic operations.
Dick, I'll give you tomorrow the details of the group zone : there are two types of PIC : numeric comp items, 9(18), and alphanumeric items X(05) or X(10).
Now, I wonder if my sample is representative, so I'd like to have your opinion or suggestions before generalizing...
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
Searchman wrote:
William, what is "OPT", a parameter of compiler?
COBOL has a compile option referred to as "Optimization", it can do some VERY strange things. Insure that OPT is off (it can be seen at the beginning of the compile listing) and run your interesting numbers again....
the loop : "MOVE A-VALUE TO A", where A-VALUE is identical to A but with values : SPACE for X( and ZERO for 9(18) (there ara no COMP, as I said by error in my previous post)
Length of A :
24 x 9(18) = 432 bytes
8 x X(10) = 80 "
7 x X(5) = 35 "
total = 547 bytes
For the option "OPT" after compiling, I found this in the sysout :
I guess the option OPT is active...
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
Yes Dick, I've been a bit busy, but I'm planning to get some PMAPs too.
I have seen OPT do some really radical things....Works a whole heck of a lot better than the old days...grin....
Sorry, but I can't run again my first tests, so my conclusion is that I was wrong.
In fact the result is (I hope this time !) :
for 1 000 000 000 iterations and group to initialize = 10 items = 168 bytes
Initialize :
23 s CPU
MOVE item group :
6 s CPU
MOVE item by item
23 s CPU
Note, for 90 items in the item group I found out respectively :
211, 103 and 205 s CPU
Conclusion :
For 10 items = 134 bytes
Initialize is 3.8 times lower than MOVE item group
For 90 items = 1186 bytes
Initialize is 2 times lower than MOVE item group
The more the item group is large the more the initialize is "performant", but even with 1186 bytes, Initialize has bad performance (2 times less fast)
Other conclusion :
coste of 1 MOVE = betwwen 2,3 and 2,56 nano second !
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Your new stats look like what i'd expect (not the actual count, but the ratio). The initialize should generate a series of moves much like the ones coded individually.
Thanks for showing your tests and posting the new results
and ZERO for 9(18) (there ara no COMP, as I said by error in my previous post)
