From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2134 invoked by alias); 27 May 2012 11:30:14 -0000 Received: (qmail 2122 invoked by uid 22791); 27 May 2012 11:30:13 -0000 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 Received: from imr-da06.mx.aol.com (HELO imr-da06.mx.aol.com) (205.188.169.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 May 2012 11:30:01 +0000 Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-da06.mx.aol.com (8.14.1/8.14.1) with ESMTP id q4RBTwxR011220 for ; Sun, 27 May 2012 07:29:58 -0400 Received: from [134.134.139.76] (unknown [134.134.139.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 110EFE0000A1 for ; Sun, 27 May 2012 07:29:57 -0400 (EDT) Message-ID: <4FC21033.4030405@aol.com> Date: Sun, 27 May 2012 17:37:00 -0000 From: Tim Prince Reply-To: tprince@computer.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@cygwin.com Subject: Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012 References: <70952A932255A2489522275A628B97C31348C437@xmb-sjc-233.amer.cisco.com> <4FC169D9.6090107@tlinx.org> <4FC16A97.8020309@dancol.org> <4FC1D815.40306@tlinx.org> In-Reply-To: <4FC1D815.40306@tlinx.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-05/txt/msg00593.txt.bz2 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