This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is the Latest Release of Cygwin supported on Windows Server 8/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: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]