This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]