Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Speed comparison of numeric data formats in COBOL

Status
Not open for further replies.

RICHINMINN

Programmer
Dec 31, 2001
138
Has anyone done any comparisons between the assortment of numeric data formats in COBOL? Yea, the ones like
- display numeric -- PIC 9(x)
- COMP -- PIC 9(x) COMP
- COMP SYNC -- PIC 9(x) COMP SYNC
- COMP-1 -- PIC 9(x) COMP-1
- COMP-2 -- PIC 9(x) COMP-2
- COMP-3 -- PIC 9(x) COMP-3
- COMP-4 -- PIC 9(x) COMP-4
- BINARY -- PIC 9(x) BINARY
- PACKED-DECIMAL -- PIC 9(x) PACKED-DECIMAL

I've done some testing with them, and the results have surprised some people around here.

I started out writing a simple COBOL program that performs a simple addition 1,000,000 times, with the number being added in one of the above 9 data formats, and the accumulator in one of the 9 data formats, as well. (Yes, that gives a total of 81 possible combinations, but my main interest was in the same-data-type combinations, such adding a packed-decimal integer to a packed-decimal accumulator, or a COMP-1 to a COMP-1.) I ran all the tests on the same system, as a DB/2 program so I could use the DB/2 time with its accuracy to 6 decimal places, rather than the regular system time with accuracy to 2 decimal places. (Note that each format's speed is relative to that of display numeric.)

The results:
DATA FORMAT E.T.(sec) Ops/Sec Speed (disp num=1)
----------- --------- ------- -------------
COMP-1 0.020814 48,044.585 3.033055
COMP-2 0.027581 36,256,843 2.288895
PACKED-DECIMAL 0.055864 17,900,616 1.130066
**display numeric 0.063130 15,840,329 1.000000 **
COMP-3 0.095595 10,460,798 0.660390
COMP 0.742182 1,347,378 0.085060
COMP-4 0.829014 1,206,252 0.076151
BINARY 0.846406 1,181,466 0.074586
COMP SYNC 0.876523 1.140,611 0.072007

Interesting, eh?

So when someone tells you to use binary values for all accumulators, you can tell them that plain ol' display numeric will perform the same calculations 14 as fast! (Well, 13.4073418604 times as fast...)

I've got similar test results for the other three primary arithmetic functions, and the results are pretty much in line with the above numbers. If anyone's interested, I can post those results as well.

Has anyone out there done any similar tests? I'd love to hear what other people have found.

Rich (in Minn.)
 
Rich,

It depends on compiler implementation and processor architecture.
I only know of Micro Focus Net Express and Fujitsu Cobol on Intel (compatible) Win32 platform.
In Micro Focus and Fujitsu COMP-5 format is available, which is in Intel format (1 = 01 00 00 00, 256 = 00 01 00 00), which is the opposite order of the COMP format (1 = 00 00 00 01, 256 = 00 00 01 00). The fastest is a 32 bit COMP-5 number (PIC 9(9) COMP-5), which also must start at a 4-byte boundary.
Both compilers align all 01-levels on a 4-byte boundary.

01 GROUPFIELD.
03 NUMERIC1 PIC 9(09) COMP-5.
03 FILLER PIC X.
03 NUMERIC2 PIC 9(09) COMP-5.

In the above, NUMERIC1 is 4-byte aligned, and NUMERIC2 is not, NUMERIC1 is about 1.5 times faster than NUMERIC2.

I have measured a 4-byte aligned 9(9) COMP-5 being 13 times faster than 9(9) (display) on Net Express and 45 times faster on Fujitsu. Apparantly Micro Focus has more efficient DISPLAY routines built in.
Marcel
 
Rich -

Can you please describe your environment (hardware, OS, compiler, compiler flags (e.g. TRUNC, OPT), multi/single-user system)?

AFAIK, packed decimal arithmetic on IBM mainframes requires time proportional to the number of digits involved, so exact description of the PIC is necessary to properly evaluate your results on some platforms.

What is the difference between PACKED-DECIMAL and COMP-3 on your architecture?

Did you include a sign on your PICs as the time required to do unsigned arithmetic needs to be accounted for as well.

Any chance the compiler optimized out your number being added (since it was constant and presumably your loop control variable was as well)?

My own experience on IBM mainframes, AIX (RS-6000), HP-3000, and IBM PCs with a variety of compilers would be that efficiency of arithmetic operations is mostly the opposite of your results so I'm very curious to see how they were arrived at.

Glenn
Brainbench MVP for COBOL II
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top