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: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
