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.

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

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...

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)
--------------------------------------------------------------------------------------------

[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

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.

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)
--------------------------------------------------------------------------------------------