Is the Latest Release of Cygwin supported on Windows Server 8/2012
Sun May 27 17:37:00 GMT 2012
On 5/27/2012 3:30 AM, Linda Walsh wrote:
> 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
> a 100%
> increase in 32-bit instructions for something that has been measured
> to dominate
> many programs. Maybe there could be callouts to convert those calls
> to native
> 8-byte moves,
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.
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
More information about the Cygwin