× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: "MI" of ILE programs
  • From: "Hans Boldt" <hboldt@xxxxxxxxxxxx>
  • Date: Tue, 30 Sep 97 12:52:50 EDT

Wiesmayr Rudolf <Rudolf.Wiesmayr@mag.linz.at> wrote:
>My background was the question if a certain C code segment
>would materialize as
>- a sequence of MI instructions or
>- as a single MI instruction or
>- as a call to a library routine.
>I wanted to get a feeling if there was
>a chance for algorithm optimization or if I had reached the
>limit for an AS/400.
>
>I did not get an answer yet.
>It seems that the ILE people don't want us to see the code
>(p or MI or whatever) generated by the ILE compilers.
>But what could be the reason for this?

I think the main reason is that it's just not very useful to see the
intermediate language.  First, our intermediate language (W-Code,
which corresponds roughly to MI in OPM) is not easy to read.  Secondly,
the optimizer in the back-end is fairly robust, even at low optimization
levels.  So the W-Code may not fairly represent the final machine code.
The optimizations performed by the ILE back-end are rather good.  Using
C, you should see good improvements just by compiling with the highest
optimizations.  (These days, optimizers can often produce better code
than an experienced assembler programmer.)

Also:  What algorithms are you using?  For example, when sorting, do you
use a bubble sort, a shell sort, or a binary sort?  Depending on your
data, the lowly bubble sort can can sometimes be the best choice!  Choice
of algorithm generally can be the most effective way to speed up your
program.

Another consideration is time:  Is it worth spending a week to get a 5%
improvement in program performance?

Ultimately, the only proper way to see what works is with performance
testing.  Even if you make a change that you *know* must give better
performance, test it to be sure.  For example, when doing some tuning
of the RPG compiler, I doubled the size of the hash table, which I knew
should provide better performance.  But the compile time doubled!  The
change had repercussions elsewhere, which I then had to address.

The bottom line is simply that these days there are better ways of
addressing performance concerns than looking at the compiler generated
code.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, hboldt@vnet.ibm.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.