Cobol Compiler generated Code is very slow on IA64

[Burkart Beat]

Hi all
We face the migration from OpenVMS Alpha to OpenVMS Itanium. Our application is 99% written in Cobol.

old HW ES47, OpenVMS V8.3 AXP, Cobol V2.8
new HW rx7640, OpenVMS V8.3-1H1, Cobol V2.9

Now we experience a very bad performance on the new HW and wrote a small program to experiment and test where the performance is lost... (see Attachment)

Compiling and Linking
With /NoOptimize
$ COB /ANSI_FORMAT /ARITHMETIC=STANDARD /FLOAT=IEEE /nooptimize XXTEST.COB
$ link XXTEST

With /optimize
$ COB /ANSI_FORMAT /ARITHMETIC=STANDARD /FLOAT=IEEE /optimize XXTEST.COB
$ link XXTEST

Results:
/noopt, AXP,
Loop1 00:00:00.49
Loop2 00:00:00.55
Loop3 00:00:00.52
Loop4 00:00:00.18

/noopt, I64,
Loop1 00:00:02.46
Loop2 00:00:02.46
Loop3 00:00:02.48
Loop4 00:00:00.79

/opt, AXP,
Loop1 00:00:00.44
Loop2 00:00:00.46
Loop3 00:00:00.43
Loop4 00:00:00.01

/opt, I64,
Loop1 00:00:06.24
Loop2 00:00:06.15
Loop3 00:00:06.24
Loop4 00:00:03.02

You see, the Alpha is always faster than I64 and /optimize is only working for AXP as expected.

Any ideas to make the thing faster? Is it worth to make a call at HP?

Any ideas welcome!
Beat

[Burkart Beat]

Here the source

[Robert Gezelter]

Beat,

I will try to print out your code and take a quick look later, but I wanted to make a few comments to start.

First, thank you for specifying the compilers and processors in use. All too often, postings omit that information, which is vital.

Are there any other "interesting" things happening on the system while the programs are running, for example, alignment faults. Alignment faults are inefficient on VAX, far more expensive on Alpha, and absolutely ruinous on Itanium.

As I said, I will try to take a look later between meetings.

- Bob Gezelter, http://www.rlgsc.com

[Burkart Beat]

Ahh yes - good point

1. I was alone on all of these systems during the testrun
2. I was trying to find out anything about this alignment "feature", therefore I used /align=padding to aks the compiler doing my job ;-) but he is a gimp!

Regards
Beat

[Robert Gezelter]

Beat,

Two comments at this stage, for clarification.

First, check if the machine is processing alignment faults during the test run.

Second, generate a machine language listing from the COBOL compiler and review it.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel · Accepted solution]

This has nothing to do with aligment.

It's just the consequence of poor choice for a loop variable.

Make IND and IND-MAX 'comp' as they should be and the loops take 0 time.

Regards,
Hein van den Heuvel (at Gmail dot com)
HvdH Performance Consulting

[Robert Gezelter]

Hein,

Thank you for the correction. I did not have the compiler up on my rx2600 and therefore could not experiment with it.

- Bob Gezelter, http://www.rlgsc.com

[John Reagan]

I can't directly explain why /NOOPT is faster than /OPT. I'll have to look at that.

For artifical programs like this that seem to rely on lots of packed decimal operations, I'll point out that the routines in LIBOTS2 on Alpha (which perform such operations) is hand-crafted Alpha Macro-64 assembly code. On I64, we converted the algorithms into C (which hurts their performance).

[John Reagan]

> Is it worth to make a call at HP?

We certainly support COBOL on I64. Since you are having a problem, yes submit a problem report.

However, as Hein suggested, using COMP for "integer-like" variables is a better programming practice for both platforms.

[Phil.Howell]

have you read chapter 15 of the user guide?
your alignment is ok, you can use /LIST /MAP=DECLARED to check it in real life programs, but always use binary for arithmetic, COMP not COMP-3
Phil
http://h71000.www7.hp.com/doc/82final/6297/6297pro_102.html#op_prog_chap