Yes, the performance of cygwin-compiled code using 64-bit data (C double, Fortran
double precision,..) is abysmal with the standard 32-bit or 4 byte alignment. I have
been running for some time with binutils rebuilt for 64-bit alignment. The results
with gcc and g77 are excellent (doesn't even interfere with rebuilding gcc), but it
breaks important parts of the existing g++ and objc run-time support binaries. I
suppose that I have introduced struct/class padding mis-match. I'm hoping to try
rebuilding the libraries to see if that will cure this.
The .p2align code and long double data alignments used by the gcc aren't fully
effective without 128-bit alignment, which doesn't appear to be possible with cygwin.
Going from 32-bit to 64-bit alignment does, I believe, greatly reduce the number of
incidents where .p2align hurts rather than helping.
With the change to 64-bit alignment, cygwin/gcc out-performs some big name Windows C++
and linux gcc compilers on certain tests of the effect of alignment on memory
bandwidth. And the big name Windows compilers cheat a bit with their 8-byte long
doubles.
Yes, binutils, combined with the cygwin run-time, keep the stack aligned to the
selected boundaries. The stack is supposed to be 128-bit aligned in linux with the
current glibc. In principle, you could make a function which would set the stack up
to your selected alignment each time you call it. Not a good practice in general.
This alignment thing has been around at least 30 years, and it's not going away, with
the greater use of 64-bit architectures.
McNulty Junior Bobby <[EMAIL PROTECTED]> wrote:
> Have you guys thought of compiling the code with 8 bit
alignments? This will bring Cygwin to 64 bits.
I know. I did this with Csound, and it is acting
better.
I read how to optimize the programs that I use and the
alignment was one of them.
Actually, i think it was the stack boundary.
--
Want to unsubscribe from this list?
Send a message to [EMAIL PROTECTED]
