Is the Latest Release of Cygwin supported on Windows Server 8/2012
Sun May 27 11:30:00 GMT 2012
Daniel Colascione wrote:
> On 5/26/12 4:40 PM, Linda Walsh wrote:
>> Compiling for 64-bit is about memory alignment and native instruction
>> set/word size execution. The alignment will likely cause runtime
>> memory usage
>> to grow somewhat, but it shouldn't be significant in most case
> So the x32 ABI  should be better yet, right?
>  https://lwn.net/Articles/456731/
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, but many will argue it's not worth the complexity -- hoping that
the next gen of processors will make up the speed -- but that has stopped
happening about 10 years ago when we hit the peak of single thread performance
and had to scale down speed to go for breath.
If a 32 bit process ran on a chip tuned for 32-bit and got back a 25% faster
clock, it might have a prayer of a chance of competing, but there isn't much
that will negate one of the largest time users -- Mem-to-mem copies *able* to be
done in half the instructions on x64.
Also, not of small consideration -- you can do alot more numeric applications
with 27.8 digits of precision than with 13.9 digits before having
to revert to floating point. Integer ops are orders of magnitude faster than
So how well a 'hypothetical' execution set would run...can be predicted
about as well as the stock market..
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin