Re: reading a text file into a string

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

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opsbspb4bep4pfvb@bram-2...
...
> >> > 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.

For the record, I was most upset about the first part, not the second. I
have no problem believing that the recommendations have changed - and you
quoted some that are different (they seem rather old, but that's another
story). But to say "I don't think that they ever did" recommend what I
originally reported says that they *never* recommended what I remember and
essentially that I was trying to mislead the conversation by saying that.
Not good.

Anyway, I accept your apology, and I'll try to be less sensitive next time.


...
> > 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 realize that we're weird here, but EBP points at the bottom of the stack
frame in Janus/Ada; that gives us positive stack offsets. We had a lot of
trouble with negative ones in the early days, and I just gave up on that.

In any case, we spend quite a bit of effort trying to avoid setting EBP at
all. For small leaf subprograms, the overhead of writing then restoring EBP
can be a significant percentage of the cost of the whole routine. Thus, we
get rid of the stack frame with an Add, and that leaves us with no obvious
way to do an alignment. (Alignment is not reflected in our intermediate
code, as that is supposed to be done by the data layout earlier in the
compiler. So it's either all or nothing - it has to be done for all stack
frames or not supported; I suspect many other compilers are similar.)

Anyway, my opinion these days is that spending a lot of effort making
something run 2% faster is wasted effort. You're always better off changing
to a different way of solving the problem. The most recent instance was in
my web log analyzer. It was running too slow on the AdaIC site's logs, and I
wasted a lot of time trying to improve it. But replacing the binary lookups
(log N, N being around 200,000) by a hashed lookup (very similar to
switching from Sorted _Sets to Hashed_Maps in the Containers library)
improved the speed by a factor of 5 (a result I didn't expect, because I had
to use an expensive hash function -- all of the cheap ones I tried didn't
work well on the actual data -- and log N wasn't that large -- between 12
and 19 on the data I tested with). Moral: make sure you've exhausted
algorithmic improvements before even thinking about squeezing a few extra
percent out of the code. And when you think you've exhaused algorithmic
improvements, try again, because sometimes non-obvious things work! (We
hadn't originally used a hash because of the need to write sorted reports.
But it turned out that using a hash and a quicksort on the report was faster
than keeping the data sorted.)

               Randy.



> 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