Possible explaination why large_real_kind_form_io_2.f90 is failing on PPC/OSX

[Tim Prince]

Dominique Dhumieres wrote:
>> the compiler will assure that real(10) doesn't straddle cache line boundaries,
>>     
>
> This assumes that you are using mostly data from the cache, when you have codes
> like mines that sweep large arrays at each iteration, they have to read and wrote
> at each iteration so going from 10 bytes to 16 almost double the memory bandwith
> which is the main bottleneck for my codes (not enough FP per node).  
No, you can't avoid mapping via read combine buffers and cache.  Your 
attempt to save bandwidth by storing real(10) without padding will be 
more than destroyed each time you reach a cache line boundary.
> So it is quite
> unlikely that I'll use real(110) (or 16) in my applications, only for tests
> (when I really need high precision, it happened once in my life, I use Mathematica).
>
>   
Agreed, that real(10) will run at least twice as long as real(8), when 
parallel floating point units are taken into account.  The only 
disagreement is on your assertion that this is caused by what you call 
"inappropriate" padding.  The scarcity of satisfactory  Fortran 
implementations of real(10), and avoidance of use of extra precision 
registers, since the advent of SSE, attests to the general lack of 
popularity and success of the concept.