e i g h t - c u b e d . c o m 

AEST and performance

Over the last month, we have been testing the application after it has been ported to IA64. The application is rather large (over 2 million lines of COBOL) and as most of it is interactive, and there are no test harnesses to do automated input and output comparison, the going has been slow.

While the developers and the business have been testing the interactive side of the app, the technical team have been running some overnight batch processing. It quickly became apparent that overnight processing was running much more slowly than on the Alpha.

The first thing I thought of was alignment faults. The system clocks quite a few of them, and I couldn't immediately rule them out as the root cause of the performance slowdown. So, I asked a programmer to align all the data and record structures in one of the worst performing reports and re-ran it. Unfortunately, this didn't significantly improve things.

So, I resorted to doing PC sampling to find out where the code was spending its time. I was reluctant to do this, because I don't have access to a good performance and coverage tool here, and was forced to use the PCS SDA extension (which is fodder for another article here, but to use a Hoff-ism, I digress). I was not looking forward to poring through map and listing files to find the routines matching the PCs. But to my surprise, I found that SDA was pointing to the Translated Image Environment sharable image.

Then the lightbulb went on. The app was acquired from a third party software house in the remote past, and part of the code that was never obtained was a module that performs standardized I/O. Because the source code was not available, the decision was made to binary translate the image from Alpha to IA64 using AEST. This translated module was being called for nearly every I/O the system issued!

To correct the problem, I reverse engineered the module in C, natively compiled it, and bingo, 1000% performance improvement.

This clearly demonstrates the dangers of binary translation. While it's good for code not on a critical performance path (for example, this company also has an interactive screen handling package that is binary translated), it really sucks when it comes to code that has to perform.