Re: ILE performance considerations

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Buck,

You wrote:
>I haven't spent much time benchmarking applications that have been compiled
>OPTIMIZE(*FULL).  Do you know how much does the optimiser moves object code
>around?  I mean, if I carefully place the "read" and "parse" routines next
>to each other in the source code, is it a guarantee that the object code
>will be co-located?

I don't know exactly what the optimizer does to the code.  I know it does
the following sorts of things:
        o Common subexpression elimination (where the same operands are used
and the result of the first occurrence is still available)
        o Constant folding (where the same literal appears multiple times)
        o Redundant store elimination (where the asignment of a value to a
variable is not used prior to the next assignment to that variable)
        o Redundant load elimination (obverse of above)
        o Local register assignment
        o Dead code elimination (but I don't think it removes dead variable
definitions)

It tries to stucture the code so the RISC instructions can be pipelined
efficiently.  I also know that the AS/400 optimizer is not as aggressive as
on other platforms (where it is posible to optimize the code so much that it
no longer runs correctly).  The optimization is performed at the procedure
level rather than the program level (although global data items are
optimized) so I still think that grouping related functions helps with
paging but there is no guarantee that the optimizer won't decide to group
them differently.

>Are there any numbers for this?  I haven't got enough large service
>programs to benchmark and can't spare the time at the moment to create a
>test suite. I would have suspected that the cost to activate a single large
>service program would be marginally less than activating a dozen smaller
>ones, but I've had very satisfactory program startup times, even on an
>overloaded model 510.

I have seen one instance of an application ported from Unix with a single
_huge_ DLL.  The DLL was built as a service program and the main program
took minutes to start.  It was OK once started but the initialisation time
hurt.  Changing to a number of smaller service programs significantly
improved the start time.

>Given that, I put more weight on being able to manage the source and
>objects.

I think that is the correct approach.  I group my service programs by
function and don't really worry about their size.  Most of my service
programs are between .25MB and .5MB with a few over the 1MB mark after
optimization and removing debug data.

Paul Remtema is one person who knows how this stuff works.  I vaguely recall
he left IBM Rochester and went to that DH Andrews Group that started up in
Rochester.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»