X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
Message-ID:	<4FC1D815.40306@tlinx.org>
Date:	Sun, 27 May 2012 00:30:29 -0700
From:	Linda Walsh <cygwin AT tlinx DOT org>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
References:	<70952A932255A2489522275A628B97C31348C437 AT xmb-sjc-233 DOT amer DOT cisco DOT com> <4FC169D9 DOT 6090107 AT tlinx DOT org> <4FC16A97 DOT 8020309 AT dancol DOT org>
In-Reply-To:	<4FC16A97.8020309@dancol.org>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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?
> 
> [1] 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
floating point.

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

- Raw text -