Re: reading a text file into a string

["Nick Roberts" <nick.roberts@acm.org>]

[I've put my replies out of order, because I think there's a bit
in the middle that needs to be said first.]

On Mon, 26 Jul 2004 18:48:04 -0500, Randy Brukardt
<randy@rrsoftware.com> wrote:

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

Well, that comes as a bolt out of the blue, Randy.

Let me first assure you that neither this time nor at any time in
the past have I intended to imply that were lying or to make any
personal slight against you.

On consideration, I feel that I should not have made the remark
"maybe you need to do some re-reading", and I do truly apologise
for it. It was intended to be lighthearted and to be taken in a
friendly manner. Usenet is a medium given to stripping away all
the extra cues that a different medium (such as a telephone call)
would convey that help to disambiguate communications. It is easy,
sometimes, to forget this, but I should have known better.

In fact, I'm very unhappy that this seems to be the impression
that you have got of me Randy, because the truth is -- though
sadly you may not believe it now -- I have the greatest respect for
you, and I honestly admire you: for what you have done and continue
to do for the ARG and Ada standards and to champion the use of Ada;
for your contributions to the Ada community (as I know it, in terms
of Usenet and other Internet venues), and the friendly and helpful
manner of those contributions.

We may have had disagreements about lots of things during the
course of discussions between us, but there is big, big difference,
as far as I am concerned, between disagreeing with someone and
having less respect for them.

I do really hope that I have not permanently destroyed any faith
you may have had in me, and I regret anything I may have said in
the past to this effect. I often have a clumsy and hasty style of
writing on Usenet, and I'm sure that often what I say comes across
with a different meaning or emphasis to what I intended.

That said, I hope my remaining replies will be taken in good part.

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

I think I once read a magazine article that said Intel were no
longer recommending cache-line (or half-line) alignments for code,
for their (as it was then) upcoming Pentium model. I have read
this sort of thing before, and dismissed it as hype or gossip,
since the official (published) Intel recommendations never changed
in the event. So I have tended to assume that repetitions of the
idea have simply been repetitions of gossip.

Obviously, since your information in fact comes from direct from
Intel, I was wrong, and I was wrong to have doubted you.

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

According to the manual, the 16-byte alignments are to do with
the way the instruction pre-decoding unit loads code, which is
16-bytes (a cache 'half-line') at a time. But is the manual
correct?

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

Well, that's true and I cannot argue with it per se.

However, based on the presumption that typical software does
spend something like 99% of the time in 1% of the code (and
that 1% tends to be fairly 'tight' loops), I am not convinced
that the extra memory space that a program will take up (both
code and data) due to cache-line alignments is more likely to
cause the program to slow down more than it will cause it to
speed up (in that critical 1% of the code).

This will be dependent on how big the working set is during
the execution of that speed-critical code, in particular
whether the working set is caused to exceed available RAM; if
it is, then the program will indeed be slowed down. But, of
course, I am saying that even cheap computers have a lot of
RAM these days, so I think that eventuality is unlikely.

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

Well, I don't think so. The usual thing is to do is to save
ESP in the EBP register at stack frame creation, and restore it
 from EBP just prior to return. There is, I grant, a need for a
little care, in that one would (I guess) need to do the stack
alignment I suggested before pushing anything onto the stack
that you might want to pop off it afterwards. Otherwise, I
think the 'and' instruction is the only extra thing required.

I vaguely remember that I have actually used this technique,
but a long time ago.

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

I can't quickly find information on the subject, but I rather
suspect that an .EXE or .DLL is likely to be loaded page
aligned. That would mean alignments up to the page size would
be safe.

Also, I think possibly we're arguing at crossed purposes on
this point. I'm only arging that linkers and execution
environments /should/ support cache-line alignments. I accept
that many do not, in practice, and I accept that a compiler
targetting such a linker or environment cannot be expected
to so so either. I think this is how Robert's original comment
can be construed, also.

-- 
Nick Roberts