COB$5644 and COBOL performance in general

[John Reagan]

OK, I've answered several emails lately on these topics so to reduce the size of my inbox, I'll write my COBOL performance manifesto for today.

1) Several of you have heard the magic phrase "COB$5644" whispered like it was akin to "xyzzy" or "plugh". You've heard it related to "bad" performance but no real details to figure it out. Here's the scoop:

In many situations, a COBOL paragraph needs to know if it was "called" by some other routine (usually from another language) or if it was just "fallen" into from the paragraph above. There is a routine in the COBRTL named COB$CALLED that is very small that returns a "true"/"false" to the generated code. For V8.2 (Alpha and I64), we fixed a bug in COB$CALLED. During testing, the developer inserted a 'getenv("COB$5644")' function so he could dynamically turn on/off the bug fix for exhaustive testing. Unfortunately, he did not remember to remove it for the final checkin. This means that the previously small and quick COB$CALLED routine now included a call to getenv() which resulted in a logical name translation. Result: not so quick. That getenv() has been removed and ECOs for the COBRTL for Alpha V8.2 and V8.3; and I64 V8.2; V8.2-1; and V8.3 have been approved for release anyday now. (I haven't jumped over to the patch database to verify their presence.) The upcoming I64 V8.3-1H1 contains the fix.

2) Compilation speed. The compiler itself contained many alignment faults. They went unnoticed on Alpha since the PAL code fixup was rather efficient when compared to the overall compilation speed. However, on I64, the faults were noticable. We fixed all of them for the COBOL V2.9 compiler that is now available. It should make a good sized difference for I64 and even might be noticable for Alpha customers.

3) Compilation memory usage. As many of you have noticed, I64 requires larger object files mostly as the result of additional instructions. The compiler needs additional memory to hold, analyze, bundle, etc. these instructions. There are some COBOL modules that compile on Alpha (just barely) that do not compile on I64 due to exhausted 32-bit address space. The COBOL front-end and the GEM back-end on both Alpha and I64 are 32-bit images. Given the legacy of the code and the multiple front-ends involved, it is too risky and too complicated to turn them into 64-images. The only solution for such large modules is to cut them into smaller modules or perhaps turn off routine inlining in an effort to reduce the number of instructions.

4) Performance of generated code. Prior to COBOL V2.9 (both Alpha and I64), the COBOL front-end lied to the GEM back-end about the alignment of some (most?) group members. For instance, the front-end might tell GEM that there is a longword field at 13 bytes from the beginning of a group that is on a quadword boundary. Due to how COBOL interfaces with GEM (COBOL is "different"), GEM did not detect such lunacy. Instead, it blindly used that wrong information when generating code. This could result in longword or quadword instructions touching "known" unaligned data. We have fixed all of these for COBOL V2.9. You have to recompile to generate the better code of course.

5) Performance of COBOL RTL on I64. Besides the alignment faults found in the compiler, there were some alignment faults (a VERY few) found in the I64 RTL as well. While we tested the compiler, we figured we'd check everything else. Due to the modules involved, the changes are only available in the ECO for I64 V8.3 (and are available in V8.3-1H1 as well).

[John Gillings]

Thanks John for a detailed explanation. Interesting insight into the kinds of simple pitfalls that can cause performance issues (note to self - always conditionalize debugging code! ;-).

When you say you've eliminated "all" alignment faults, can you expand on how you did it, and how you're confident you got them all? From the outside this looks like a mammoth effort for code as complex as a compiler. Since many of us face a similar effort for Alpha-Integrity ports, any insights, tricks or warnings would be very welcome.

[John Reagan]

OK, "all" is hard to prove. What we did was turn on alignment fault reporting via the SYS$PERM_ALIGN_FAULT_REPORT (or whatever the heck the spelling is - I've just spent 4 days with a 102F fever so cut me some slack :-) ).

We ran the test system first without changes and watched thousands of alignment faults come flying out. We kept finding/fixing places in the compiler and rerunning the tests. Repeat until zero alignment faults. Besides watching faults during the compilation phase, we turned on fault reporting for each test's execution as well.

I had done the same thing to the Pascal compiler and RTL several years ago prior to I64.