This is the mail archive of the
mailing list for the GCC project.
Re: 64 bit fortran unformatted on Opteron -- incompatible with32unformatted
- From: Kyon <kyon at verizon dot net>
- To: gcc-help at gcc dot gnu dot org
- Date: Wed, 16 Jun 2004 09:50:18 -0700
- Subject: Re: 64 bit fortran unformatted on Opteron -- incompatible with32unformatted
- Organization: K 9 Bone Admiration Society
- Reply-to: tunaboy2 at verizon dot net
No x86 is not the whole world, but Sun, SGI, etc. all have files which use a
32 bit record for this field. I move back and forth between these universes
all the time, and with byteswapping i/o it works quite nicely.
It would seem to me that being incompatible with other systems is not a good
place to be, especially when the reasons for doing so are not compelling.
with a 100MB/sec transfer rate, a 4GB record will take 41 seconds to read,
assuming there is no other contention for the I/O channel, and DMA is working
flawlessly. This also means that you've set aside 4GB of actual memory to
hold this monster and have memory besides this to have your program in. And
when you read the 2nd 4BG record...
Are the Itaniums following this path? I can see for them, since they are more
a clean break with the 32 bit world, but even there, being able to re-use
grids that have taken in some cases months to create (yes, although a complex
grid i s now more down to a matter of weeks) would be a real benefit.
Especially when you find yourself in the situation of not being able to
re-create the grid, or wanting to run exactly the same grid on the new
This was one of the failings of the Cray, with it's proprietary format, all
the grids I've generated are now toast(which are not that complex but still
represent bonehead-months of work)...