Re: reading a text file into a string

["Robert I. Eachus" <rieachus@comcast.net>]

Randy Brukardt wrote:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> news:nM-dnegXLbmdK2DdRVn-hQ@comcast.com...
> ...
> 
>>When the programmer can do something simple like this to improve program
>>performance, it should be supported by all compilers.  (Notice that this
>>is an error, not a warning.) I can see not supporting the subtype case
>>due to the (potential) requirement for either large stack frames or
>>varying size stack frames.  But for an object that can be allocated at
>>link time, I don't see why it shouldn't be supported.
> 
> 
> What's an object allocated at link time? I don't know of any such thing (you
> can allocate segments at link time, but the number of those is quite
> limited).

Um, a compiler can (but most Ada compilers don't) allocate objects in 
library packages on the heap, in static storage, or even in code 
segments.  But you are right that this is very definitely not the usual 
in x86 compilers and environments.

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

This is much more likely on an Intel CPU, and is potentially much more 
painful when it happens.  The 'exclusive' cache feature on AMD 
processors means that if the line gets replaced in L1, it will be copied 
back to L2.  So it takes two cache line replacements to push the line 
out of cache entirely.  With Intel the line can get moved to the much 
smaller L1 cache, then overwritten in L2 cache.  When it is overwritten 
in L1, then it will have to be pulled in from main memory next time around.

We may only be talking say, a 2 or 3% slowdown from such a misaligned 
text buffer.  Not really worth going to all the trouble to align buffers 
for casual programming.  But when I am working on a linear algebra code, 
I do go to the effort where it does pay off.  (For example, if you 
represent the basis in a linear programming subroutine as a matrix and a 
series of pivots, it makes for a significant improvement in performance 
to start the pivot rows on the correct cache line boundary.)

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821