THE FEEDBACK DIRECTED PROGRAM RESTRUCTURING TOOL

What happens when you're maintaining an AIX system running a very old application that has no vendor support? And for some time, that application has been performing very poorly? You've done all the right things from an administrative standpoint insofar as keeping your operating system up to date, having the latest system and device firmware installed in your P series box, and have tried every appropriate tuning option (VMO, IOO, etc.)? Your application vendor has gone out of business and you don't have the source code. To make matters worse, there are no appropriate substitutes for your app, and Management is screaming that bankruptcy is imminent if you don't get your environment performing better so all those backed up orders can be processed.

Sounds pretty bad, huh? I've worked with AIX for more than twenty years; you'd be surprised on how often I've run across this very scenario. Sometimes, there is absolutely nothing that can be done for the old application, and your Company simply has no choice but to hire a new vendor, have a replacement app written from the ground up, and business will just have to suffer until that happens. But sometimes, you can throw a Hail Mary and save the day. The name of that Hail Mary is the FDPR, which stands for the "Feedback Directed Program Restructuring Tool".

My feeling is that you should not use the FDPR on any code (application, database, middleware, whatever) where you have vendor support. Is that app running slow and your vendor is still in business? Call them and do a code review. Database dogging along? Call Oracle, IBM, or Sybase/SAP for a patch. Middleware or Utility? Same thing. I think the FDPR is a tool that is used as a last-ditch effort where you have nothing left to try and no-one to call.?Any vendor that finds their code has been run through the FDPR is well within their rights to refuse you support if somethings breaks because of it.... on the other hand, there may be cases where a vendor may welcome the FDPR's abilities; in these instances you want to be very clear with them that their code will be irrevocably altered by the utility, so make sure you're clear about this understanding and get your vendor’s same understanding in writing.

But if you are indeed in the situation where there is absolutely nothing left to try, prepare to be amazed!

The FDPR is part of the bos.perf.fdpr fileset and ships with every AIX distribution. It is a little known and seldom used utility, but -- in my opinion -- is the most powerful tool in the AIX arsenal. Its purpose is to optimize already-compiled programming code so that it performs well on the particular version of AIX you are running. So without re-compiling your code, in some cases you can breathe new life into an old application that has seen better days.

With that in mind, let's get to the basics of this extremely powerful tool. The FDPR program optimizes the executable image of a program by collecting information on the behavior of the program while it is used for some typical workload, and then creating a new version of the program that is optimized for that workload. The new program generated by the FDPR typically runs faster and uses less real memory. You take your compiled code and run it through the FDPR while it's doing whatever it is you want it to do, and end up with two things: The original program, and an optimized version of that program.

Some of the things the FDPR does in the optimization process are:

Branch Folding: If you're familiar with programming, you know that branch folding is a technique where a branch instruction is removed from the instruction stream that is presented to the pipeline. Branch folding can significantly improve the performance of programs. Code Reordering: are these lines or those sections of code scattered throughout the program in a way such that their invocation order impacts the overall performance of that program? The FDPR can reorder your code sequences to make them more efficient. Redundant NOOP instructions: the "No Operation" declarations. NOOPs are instructions that tell a CPU to move to the next sequential instruction. If you've ever done a code review, NOOPs tend to pop up like weeds and get to be a redundant pain; the FDPR can help in the removal of unnecessary and performance-impeding NOOPs.?Other FDPR functions include code alignment, csect analysis and inlining. These are only a few of the things the FDPR can do for you; these are only a few examples of the FDPR’s capabilities.

Insofar as a demonstration goes, I think the easiest thing to do would be for me to give you an example of how the FDPR works that you can test out for yourself. Let's use a tool called the " lsc " that ships with the PerfPMR diagnostic package. lsc is a great tool in itself when you want to look at details about your system's caches, CPU clock speeds and a mess of other stuff. lsc also contains enough code sections such that you'll be able to see a lot of what the FDPR is doing while it works. Since the lsc is a self-contained utility, all we need to do to return it to its original form is to back it up, and then restore it after our experiment with the FDPR is done. (The original file is preserved during the FDPR run, but let’s err on the side of caution). On the off-chance you do not have PerfPMR installed in your environment, here's a link from which you can download it:

https://www.ibm.com/docs/en/aix/7.2?topic=performance-restructuring-executable-programs-fdpr-program

...navigate to the folder that contains the version of PerfPMR appropriate for the version of AIX you're running. Once downloaded, follow the README that explains the very brief installation instructions.

Once you have PerfPMR installed, set up your test of the FDPR:

On a Test or a Sandbox machine ONLY:

1) Make sure you have the PerfPMR utility installed

2) Create a directory (I usually name it " fdpr_test ") with several gigs of space, anywhere except / or /var.

3) Do a " cp -p " of the lsc executable from whatever directory it's installed in to your fdpr_test directory.

4) Run the lsc executable through the FDPR with this syntax:

fdpr?-O4?-o?lsc.fdpr?-p?./lsc?-x?./lsc

...this tells the FDPR to execute the version of lsc you have in your fdpr_test directory in its generic mode, and apply the most aggressive optimization flags ( " -O4 " ) to create the optimized version of lsc. You will see several screen-fulls of information about the steps the FDPR is taking to optimize lsc's code. After the process completes, you will be left with the original lsc program, and the optimized version called " lsc.fdpr "; note that they will be different sizes.

With this example, you get a feel for how the FDPR operates and what it does. There are dozens of flags to the FDPR used for as many purposes. There isn't much official IBM documentation on the FDPR -- what there is, is contained in the AIX 6.1 and 7.1 Performance Management Guides, and then only a few paragraphs -- so you're going to have to rely on the manpage and experimentation.

The FDPR is unique as a utility and powerful. Use common sense with it. Take my cautions and recommendations seriously; I’m probably being a bit over-cautious, but nobody’s environment was ever hurt by an over-abundance of care. Learn the FDPR thoroughly and document all of your activities. You may be pleased with the results. And that old, unsupported code might just get a new lease on life.