X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,TW_CP,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
Message-ID:	<4FC21033.4030405@aol.com>
Date:	Sun, 27 May 2012 07:29:55 -0400
From:	Tim Prince <n8tm AT aol DOT com>
Reply-To:	tprince AT computer DOT org
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
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> <4FC1D815 DOT 40306 AT tlinx DOT org>
In-Reply-To:	<4FC1D815.40306@tlinx.org>
x-aol-global-disposition:	G
X-AOL-SCOLL-SCORE:	0:2:407602304:93952408
X-AOL-SCOLL-URL_COUNT:	0
x-aol-sid:	3039ac1d29424fc210352fa3
X-AOL-IP:	134.134.139.76
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

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

- Raw text -