Is the Latest Release of Cygwin supported on Windows Server 8/2012

Tim Prince
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.

Tim Prince

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list