Cobol Compiler generated Code is very slow on IA64

[Phil.Howell]

using an alphastation and 2.2 cobol
see attachment
there are no floats so I didn't use that qualifier and my compiler doesn't have /ARITH

I am surprised that your axp opt didn't improve things much - were your elapsed and cpu times nearly the same?
Phil

[Malcolm Wade]

Beat,

Having looked at your code it looks like something found and reported to hp late last year. It is still being worked on.

The issue is to do with "ELF object format used on Integrity does not allow for "sparse" initialization".

Looking at your code it will probably be the statment

01 I02-IND-MAX PIC 9(08) VALUE 5000000.

that is causing your issue. Reduce the value to prove it to yourself.

You'll probably notice a reduction on the object size too.

I'm not a COBOL expert but the advice from hp was to change the source code to alleviate this effect by moving the initialization of (in your case) I02-IND-MAX from the WSS to somewhere in the code at run-time.

"Mr Cobol" is still looking into making improvements but I've heard nothing recently so this is a timely reminder for me to chase hp up!

Hope this helps,
Malcolm

[Burkart Beat]

Hello all

Thank you very much for your time - reading and answering my post.

The Tip with the declaration using COMP as datatype really did the job! After applying the change to the "REAL" program ist went thru within normal expected runtime. Reduced the consumed CPU time from 25Min to 5Min.

My job is now to find and change all bad declared loop variables within the 3000 sources and to son deep testing. Im sure we will find also other things, but this will be another story.

I close this topic and assign some points to you...

Again many thanks!
Beat

[Burkart Beat]

case closed !

[John Reagan]

malcolm, this is different than your problem. The statement

01 I02-IND-MAX PIC 9(08) VALUE 5000000.

is only initializing a small packed decimal string to 5000000.

Your situation is having a LARGE data structure with a few non-zero fields scattered around. Something that can be represented in Alpha OBJ format easily but ELF format forces us to write the whole section into the OBJ file.

For those of you still reading, our compilers (except for C++) are inefficient in writing OBJ files. Since ELF files are RMS "undefined" files, the code in GEM went down a path that caused it to be paranoid. It current writes OBJ files in ONE block increments with no multi-buffering, etc. (ie, it uses SYS$WRITE). There are places where the compiler must to back and rewrite various blocks (like the ELF header) so it isn't just a sequential stream file.

For regular sized OBJs, the extra I/Os haven't been noticed before (we didn't even realize it until Malcolm submitted the bug). However for LARGE OBJs (like those with large data structures with a few non-zero fields scattered around), the overhead of the poor choice in RMS calls is very noticable.

On the side, I've been rewriting that portion of GEM to use a larger buffer and more buffers. As I mentioned above, it is complicated by the fact that sometimes the compiler wants to backup and rewrite bytes in the ELF file (not simply rewrite a BLOCK, but the interface in GEM allows rewriting of arbitrary bytes in the file). My rewrite needs to handle that case.

My status? I'm about 2/3rds finished with the rewrite, but other pressing items have prevented me from finishing. I do get ping'd at least once a week from the ambassador in Sydney as well as my local support chain.

[Richard J Maher]

Hi John,

[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).]

Delightful!

Just curious whether this decision is from John Reagan Zeit or circa Don Braffit?

Hi Burkart,

[My job is now to find and change all bad declared loop variables within the 3000 sources and to son deep testing. Im sure we will find also other things, but this will be another story.]

Yep, compile-and-go nothin' beats it. Any on-disk packed-decimal data? Good luck with the regression testing!

Still who'd be using comp-3 with COBOL anyway? (Or COBOL for that matter)

Have you thought of taking the opportunity to convert to Java or C++? You'd get a much bigger bang for your support buck from HP/VMS!

Cheers Richard Maher

[Dennis Handly]

>Bob: check if the machine is processing alignment faults during the test run.

Why would the compiler generate code that accesses misaligned data?
My COBOII compiler on MPE would simply do byte or short loads. (Especially since the OS would just abort on an alignment fault. :-)

Perhaps the VMS compiler is spoiled. :-)

>Malcolm: The issue is to do with "ELF object format used on Integrity does not allow for "sparse" initialization".

Yes, we have the same problem with ELF on HP-UX. Our PA-RISC SOM format allows sparse inits in object files but not ELF.

[Robert Gezelter]

Dennis,

When I made my second comment about alignment faults, I was concerned that something in the call path used by the program was generating faults.

There are two ways that you can get alignment faults on programs that appear to be innocuous: 1) a "lie" about the alignment of a structure that is within a structure; or
2) somewhere in the path of calls within calls underlying the program, there is an alignment issue.

While I do not do it in every situation, it is often useful to EXCLUDE such a problem at the beginning, rather than to march onward for an extended time. Exclusion of a potential diagnosis allows one to remove many possibilities from consideration at the outset.

I found this a useful intellectual technique for which I must give credit to non-computer diagnosis fields, such as traditional engineering and medicine.

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

[John Reagan]

Dennis: [Why would the compiler generate code that accesses misaligned data?]

Besides the siutations that Bob mentioned where a non-COBOL caller might have 'lied' by passing something that wasn't aligned properly, I'll mention that COBOL V2.8 and earlier contains a bug where it would generate code that assumed alignment eventhough it could clearly tell from the source that it was not aligned. That bug has been corrected for V2.9.

For pure COBOL applications, I don't expect any alignment faults if compiled with the V2.9 compiler.