Re: reading a text file into a string

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

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:OrednWv2_cdw3Z3cRVn-uQ@comcast.com...
> Randy Brukardt wrote:
...
> > Similarly, do you know of *any* compiler for *any* language that
supports
> > 256 byte alignment? I don't, at least on Windows.
>
> You are probably correct with regards to Windows.  I do know of
> compilers that do support such alignments, but only for supercomputers.
>   With the rate at which x86 chips are taking over the supercomputer
> market though, I'll have to check.
>
> But the real reason I posted all this is that Ada compilers for x86,
> including x86 Windows SHOULD support this alignment, even if it is
> relatively painful to do so. (Painful in terms of gaps in the stack, or
> doing the extra effort required when allocating space on the heap.)  The
> case of a String buffer when reading files is a perfect case in point.
> If the buffer is 128 (AMD) or 256 (Intel) byte aligned when reading from
> a memory-mapped file, you will reduce the number of cache line misses
> during the execution of the program.  (If the buffer is in a single
> cache line, then that line will stay resident in L1 cache.  If the
> buffer is distributed over two (Intel) or more (AMD) cache lines, the
> lines that are not referenced every line may get paged out.

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.

Indeed, it would make the most sense to allocate such objects from a storage
pool (with enough extra memory to support the alignment); align the
resulting address, and use an address clause to force the object to use that
memory. That would get the performance benefit in the rare case where it
would help without costing anything to implementors or to users of programs
that don't need the alignment.

                             Randy.