Re: reading a text file into a string

["Randy Brukardt" <randy@rrsoftware.com>]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opsbndy0o1p4pfvb@bram-2...
> On Fri, 23 Jul 2004 20:42:53 -0500, Randy Brukardt <randy@rrsoftware.com>
> wrote:
>
> > ...
> > Well, first of all, books don't necessarily equal practice.
>
> In other words, you /are/ trying to say all those computer
> scientists got it wrong ;-)

No, they're just ignoring the realities of the target systems. Most articles
I see make that mistake. (Including this one. :-)

> > If aligning things causes a program to use more pages, it
> > can make it run slower, because it makes it load code from
> > disk more frequently.
>
> But we (Robert and I) are talking about using alignments
> sparingly, to improve the efficiency of the speed-critical
> parts of a program. Surely you've heard of the 80-20 rule?
> (Which is, of course, silly, being the 99-1 rule in reality.)

The largest alignment that you allow impacts the design of your stack and of
your storage pool, at least if you intend to do it at compile-time. That's a
distributed overhead - it's small, but certainly not zero.

...
> In any event, all the compiler has to do to align the stack
> to 2^n bytes just prior to (parameter pushing and) subroutine
> call is to emit:
>
>     and esp, -2^n
>
> et voila!

How do you undo this when you leave the scope? You have to save the ESP
value somewhere and restore it to do that, and *that* is an extra overhead.

...
> > Similarly, existing Windows linkers don't support alignments
> > beyond 16 to my knowledge -- so again you would have to do
> > something at runtime with a penalty.
>
> But then the point is that the linkers /should/ support other
> alignments. It's no good saying "Oh, we can't do that because
> the linker doesn't support it!" Obviously, you need to change
> the linker. It's called not letting the tail wag the dog :-)

You know as well I as do that you don't get to change your target system to
your whim. You have to use the tools that users want to use, such as the
Microsoft linker.

But even if you wrote your own linker, I don't think that there is any
guarentee of alignment in the loading of the parts of an .EXE file. So I
don't know if any alignment that you have in your linker would actually be
preserved.

...
> > Last time I checked, Intel was recommending that labels in
> > code not be aligned further than 4 byte boundaries.
>
> The latest advice is:
>
>     Loop entry labels should be 16-byte-aligned when less than
>     eight bytes away from a 16-byte boundary.
>
>     Labels that follow a conditional branch need not be aligned.
>
>     Labels that follow an unconditional branch or function call
>     should be 16-byte-aligned when less than eight bytes away
>     from a 16-byte boundary.
>
>     Use a compiler that will assure these rules are met for the
>     generated code.
>
> [Section 2, Intel Architecture Optimization Reference Manual,
> Copyright (c) 1998, 1999 Intel Corporation All Rights Reserved
> Issued in U.S.A., Order Number: 245127-001]
>
> > I don't know precisely why they recommended that, but I don't
> > claim to know better than Intel!
>
> Well, I don't think they ever did; maybe you need to do some
> re-reading.

That's it. That's the third time in the last few months that you've
essentially called me a liar - or senile - and I'm done taking it without
comment. Either we're going to talk without personal attacks, or we're not
going to talk at all. OK?

For the record, my knowledge of Intel's recommendations primarily comes from
an Intel seminar I attended some years ago. Since it was covered by an NDA
(non-disclosure agreement), I can't even show you - or tell you for that
matter - much more than that.

In any case, the rules that you gave above are weaker in most areas than the
ones I remember (labels at 4, subprograms at 16), and certainly give no
indication of the value of cache-line sized optimizations -- which is what I
think we were talking about. I see nothing above recommending alignments
greater than 16 for anything.

                   Randy.