Re: reading a text file into a string

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

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opsbl1vsgsp4pfvb@bram-2...
> On Thu, 22 Jul 2004 19:49:34 -0500, Randy Brukardt <randy@rrsoftware.com>
> wrote:
>
> > ...
> > That could only be done at run-time, as you couldn't insure anything
> > about the alignment of the stack at compile-time. (That's probably
> > why GNAT will support only 4 byte alignment, which is about all you
> > can guarentee.) So you're asking to make subprogram linkage more
> > expensive, to make heap allocation more expensive, and probably to
> > use indirect access to statically allocated objects (in order to align
> > the starting address). I don't doubt that there are cases where you
> > might gain a tiny bit of performance from doing so, but it seems a
> > large burden on all of the users to insist on it.
>
> Randy, this is weird. It is a well established technique for highly
> optimising compilers to align things for cache efficiency. Good grief
> there are whole books on the subject. Not only do they advocate the
> possibility of aligning both basic blocks (code) and data objects on
> cache-line boundaries, but they advocate that the compiler do it
> automatically wherever possible.

Well, first of all, books don't necessarily equal practice. 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. (And if you think
that everything is always in main memory, you forget one of the primary
rules of computing: programs and data always expand to fill - and overfill -
available resources).

Anyway, I wasn't arguing that alignment per-se is a bad idea. We do it on
integers, for instance, and I think that virtually all compilers do that. I
was arguing that on the x86, stack alignments beyond 4 can only be done at
run-time. (Unless *all* software in the system in under your control, and
there are no interrupts/signals on your stack -- never true in practice.)
That's a distributed penalty that gets paid everywhere. 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. In both
cases, the penalty might very well cost more than the time savings possible.

Given there is a penalty, doing alignments automatically is a bad idea.

> If you think having big 'gaps' is an efficiency concern, I think the
> idea is that you fill in the gaps with smaller objects (or basic
> blocks).

Last time I checked, Intel was recommending that labels in code not be
aligned further than 4 byte boundaries. I don't know precisely why they
recommended that, but I don't claim to know better than Intel!

> If you are worried about the fact that all stacks and heaps/
> pools must be cache-line aligned (32, 64 bytes?), you have missed the
> RAM revolution that has been going on for the last two decades ;-)

That's only possible if you build a new OS from the ground up. Stacks aren't
aligned in Windows or Linux. So you have a pay a penalty to make them so;
and because of interrupt handlers and the like, you can't even trust your
own stack. Heap allocations aren't aligned in Windows, either. (Although you
could build you own heap on top of the page management in Windows -- but you
better be prepared to allocate 64K at a time.) Again, you can fix this with
run-time overhead. But if you're willing to spend run-time overhead, an
address clause does the same thing without any work.

                  Randy.