This is the mail archive of the
mailing list for the Cygwin project.
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/27/2012 3:30 AM, Linda Walsh wrote:
This has little to do with choice between 32- and 64-bit OS, unless you
write programs which spend their time moving data blocks which are too
big for cygwin. gcc -m32 defaults to generation of in-line memcpy code
optimized for short strings, while gcc -m64 uses glibc functions (too
big to inline), but that's only indirectly a consequence of the OS.
CPUs have been adding microcode continually for better optimization of
the gcc -m32 string moves, even though new CPUs are designed primarily
for 64-bit OS. The same data move instructions are present in either
OS. It took years for glibc to implement efficient string moves for
x86_64, and those still bump up against the question whether they always
use code which runs on the CPUs of a decade ago.
It Could be if it is done in a way that removes all the 32-bit
speed probs (alignment issues being only 1), but ALOT of what
computers do is
move data around -- large amounts -- strings, buffers, etc.
64-bit archs can move a native 8-bytes/cycle, 32-bits only 4... that's
increase in 32-bit instructions for something that has been measured
many programs. Maybe there could be callouts to convert those calls
CPU designers spend lots of cycles simulating runs of future CPUs on
instruction traces of current applications. There's a lot more
quantitative analysis there then in any assertions I've seen about the
future of cygwin.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple