|
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 mailing list archive is Copyright 1997-2025 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 copyright@midrange.com.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.