Is #pragma alloc_text useful in 32-bit apps? - OS2

This is a discussion on Is #pragma alloc_text useful in 32-bit apps? - OS2 ; Hi, I've got an app that was originally 16-bit code and has been ported to 32-bit code. Since it was 16-bit code, there was heavy use of #pragma alloc_text to optimize performance by minimizing segment register reloads. I'm considering removing ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Is #pragma alloc_text useful in 32-bit apps?

  1. Is #pragma alloc_text useful in 32-bit apps?

    Hi,

    I've got an app that was originally 16-bit code and has been ported to
    32-bit code. Since it was 16-bit code, there was heavy use of #pragma
    alloc_text to optimize performance by minimizing segment register reloads.

    I'm considering removing these #pragmas because, it's my belief that in
    the flat model there's little or no benefit to attempting to group related
    functions in this way.

    Regards,

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 08pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  2. Re: Is #pragma alloc_text useful in 32-bit apps?

    On Sun, 29 Jul 2007 23:39:15 UTC, Steven Levine
    wrote:

    > Hi,
    >
    > I've got an app that was originally 16-bit code and has been ported to
    > 32-bit code. Since it was 16-bit code, there was heavy use of #pragma
    > alloc_text to optimize performance by minimizing segment register reloads.
    >
    > I'm considering removing these #pragmas because, it's my belief that in
    > the flat model there's little or no benefit to attempting to group related
    > functions in this way.


    If you group related functions, you'll reduce the working set of the
    program (hopefully).

    I tend to use the pragma in all of my programs; one area for init code,
    one for error handling, and one or more for the rest.


  3. Re: Is #pragma alloc_text useful in 32-bit apps?

    On a pleasant day while strolling in
    comp.os.os2.programmer.misc, a person by the name of Bob
    Eager exclaimed:
    > I tend to use the pragma in all of my programs; one area for init code,
    > one for error handling, and one or more for the rest.


    Hm. Is the effect even detectable these days?
    --
    aaronl at consultant dot com
    For every expert, there is an equal and
    opposite expert. - Arthur C. Clarke

  4. Re: Is #pragma alloc_text useful in 32-bit apps?

    On Mon, 30 Jul 2007 18:07:10 UTC, Aaron Lawrence
    wrote:

    > On a pleasant day while strolling in
    > comp.os.os2.programmer.misc, a person by the name of Bob
    > Eager exclaimed:
    > > I tend to use the pragma in all of my programs; one area for init code,
    > > one for error handling, and one or more for the rest.

    >
    > Hm. Is the effect even detectable these days?


    Dunno...some of my programs are big!

    There's my pride, though...


  5. Re: Is #pragma alloc_text useful in 32-bit apps?

    In <176uZD2KcidF-pn2-WhrK0wBetmdO@rikki.tavi.co.uk>, on 07/30/2007
    at 06:07 AM, "Bob Eager" said:

    Hi,

    >If you group related functions, you'll reduce the working set of the
    >program (hopefully).


    My thought on this is that the OS will do this for you in flat model via
    the paging mechanisms.

    I guess, if you are really good at laying things out by hand, you could
    avoid a few page misses.

    Regards,

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 08pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  6. Re: Is #pragma alloc_text useful in 32-bit apps?

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Steven Levine
    ], who wrote in article <46ae4e1d$1$fgrir53$mr2ice@news.west.earthlink.net>:
    > >If you group related functions, you'll reduce the working set of the
    > >program (hopefully).

    >
    > My thought on this is that the OS will do this for you in flat model via
    > the paging mechanisms.


    Nope. The question is about *using the paging mechanism(s) in the
    most efficient way*. If you working set for the tightest long loop is
    20 functions (total about 12KB), then in the worst scenario they would
    hit about 25 pages; in the best scenario, about 3-4 pages.

    > I guess, if you are really good at laying things out by hand, you could
    > avoid a few page misses.


    Nope. With the current computer architecture, the *quickiest* memory
    is always a scarce resource. Compacting reduces the "touched memory"
    footprint on all the levels of caching.

    Hope this helps,
    Ilya

  7. Re: Is #pragma alloc_text useful in 32-bit apps?

    On Mon, 30 Jul 2007 20:46:20 UTC, Steven Levine
    wrote:

    > In <176uZD2KcidF-pn2-WhrK0wBetmdO@rikki.tavi.co.uk>, on 07/30/2007
    > at 06:07 AM, "Bob Eager" said:


    > >If you group related functions, you'll reduce the working set of the
    > >program (hopefully).

    >
    > My thought on this is that the OS will do this for you in flat model via
    > the paging mechanisms.


    Well, the working set is determined by the program, not the OS. That's
    what a working set is. No OS algorithm can change that.

    > I guess, if you are really good at laying things out by hand, you could
    > avoid a few page misses.


    Exactly. Not have to be very good, but simply group. Very similar to
    what you did in 16 bit, but for a slightly different reason. Init code
    runs, pages come in. Main program runs, init pages go out, others come
    in. If init code and main code are scattered and mixed across pages,
    more pages are required and there is more likely to be paging. Hardware
    caching will also suffer.



  8. Re: Is #pragma alloc_text useful in 32-bit apps?

    In <176uZD2KcidF-pn2-brzH3Used2yZ@rikki.tavi.co.uk>, on 07/30/2007
    at 09:35 PM, "Bob Eager" said:

    >> My thought on this is that the OS will do this for you in flat model via
    >> the paging mechanisms.


    >Well, the working set is determined by the program, not the OS. That's
    >what a working set is. No OS algorithm can change that.


    True. I really did not write what I meant. I was thinking that the OS
    will find the working set and these pages will tend to stay in memory.

    >> I guess, if you are really good at laying things out by hand, you could
    >> avoid a few page misses.


    >runs, pages come in. Main program runs, init pages go out, others come
    >in. If init code and main code are scattered and mixed across pages,
    >more pages are required and there is more likely to be paging. Hardware
    >caching will also suffer.


    All true, but in the case of the code I'm working where the related
    functions tend to be grouped by source file and so are the #pragmas. A
    lot of what the #pragmas are trying to do is already accomplished pretty
    much automatically by the source code organization.

    For now the #pragmas will stay. I'm not all that convinced that they are
    really helping, but I doubt they are making things worse. At some point, I
    might give the profiler a try a see if there are any useful adjustments to
    be made.

    Regards,

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 08pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


+ Reply to Thread