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

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 [1] should be better yet, right?


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
floating point.

	So how well a 'hypothetical' execution set would run...can be predicted
about as well as the stock market..

Problem reports:
Unsubscribe info:

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