X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-8.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_PGP_SIGNED,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By:	sourceware.org
Message-ID:	<4FB6DD43.9080407@users.sourceforge.net>
Date:	Sat, 19 May 2012 07:37:39 +0800
From:	JonY <jon_y AT users DOT sourceforge DOT net>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0
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:	<CAHomkLT1PncaF4cd0ZMgm4sD1bFvza3DPSUnxLBQ4K5ZLNyu3A AT mail DOT gmail DOT com> <jp5o12$1fb$1 AT dough DOT gmane DOT org> <000601cd351f$da0e4900$8e2adb00$@motionview3d.com> <jp6jdu$nfo$1 AT dough DOT gmane DOT org>
In-Reply-To:	<jp6jdu$nfo$1@dough.gmane.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

--------------enigF0AE651F401F2CB8EBFD36EE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/19/2012 06:45, Andrew DeFaria wrote:
> On 5/18/2012 10:58 AM, James Johnston wrote:
>>> 64-bit does not make things go any faster than 32-bit.
>> Not true for some applications.  For one of our applications that uses
>> very large in-memory trees and is therefore heavy on the recursion,
>> simply switching the compiler to 64-bit provided a 10% performance
>> boost.  Other commonly used compilers and configurations provided an
>> even bigger boost - e.g. 15% to 20%.  Seems like I recall reading
>> somewhere that x64 has more registers available for parameter passing,
>> so recursive algorithms get a boost like this.
>>
>> Other applications aren't affected so much by the change.  For
>> example, I would expect a simple math intensive app that doesn't use
>> much memory or recursion to run at about the same speed.  And other
>> applications are detrimentally affected.  For example, the 2x larger
>> pointer size can negatively affect algorithms that store many
>> pointers, which means that not as much data can be stored in the fast
>> CPU cache.
> OK, OK. Tack on "for most applications" to my statement (I thought it
> was assumed).

I believe the same was said when transitioning from 16bit to 32bit.

>>> 64-bit is wasteful as
>>> programs grow to double in size.
>> Not true.  Some programs grow slightly and some might not grow so
>> severely.  Example: - comparing an otherwise identically-compiled
>> program, it is 583 KB for 64-bit and 613 KB for 32-bit.  So the 64-bit
>> version is actually smaller.  Another example program is 1364 KB for
>> 32-bit and 1956 KB for 64-bit.  In that case the 64-bit version is
>> larger, but not even close to 2x larger.
> How can 1000 machine instructions of 32 bit be larger than 1000 machine
> instructions twice that size! Unless vastly different code generation
> happens with 64 bit compilers the number of instructions emitted should
> be just about the same yet with 64 bit instructions are obviously twice
> as big as 32 bit instructions.

Those are just pointers, instructions do not necessary double in size,
we are talking about CISC CPUs after all, besides, nearly all registers
in 64bit long mode doubled in size, not to mention the number of them
increased, see AMD64 GPRs compared to x86 GPRs.

>> Besides, who cares that much about the image size these days?  We
>> don't, within reason.
> I, for one, do. These larger binary images need to fit in memory and
> reserve swap space and virtual memory. I see virtual memory foot prints
> in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly
> takes 1-2 gig of virtual memory and hundreds of megs of real memory. If
> you run many things like I do you quickly get to the point where your
> swapping and thrashing and waiting for the OS to manage many, many more
> fragments of memory. All my systems have 4 gig (XP at work, a couple of
> Ubuntu boxes at home) and they all come under memory pressure at times.
> Small is beautiful.

No modern OS actually loaded the entire executable into memory, not
since the MSDOS days, they are mapped, like pagefiles.

>>> 64-bit is only required/useful/etc if you
>>> have memory requirements>  4 gig. I don't think any Cygwin executable
>>> has
>>> such requirements...
>> And 640 KB of RAM will be enough for anybody.
> That's totally unfair as I didn't say that nor did I imply it at all. As
> such that was a stupid thing to say IMHO.
>> You say you get 4 GB but for many applications that is only a dream:
> I didn't say anything of the sort. Re-read it.
>>   * Most applications are not compiled to be large address aware,
>> which means that they only get 2 GB of address space - not 4 GB.=20
>> Windows gets the rest.  In order to be large address aware, you have
>> to be 100% sure that no code is storing pointers in signed integers
>> and then doing math/comparisons with it.  If you are large address
>> aware, you still only get a limited amount of memory on 32-bit
>> operating systems - not the full 4 GB.
> I didn't say that either. I said that 64 bit allows you to address more
> than 4 gig.
>>   * You could use Address Windowing Extensions to access more than 4
>> GB in 32-bit, but the application has to be specially coded for it
>> because you are swapping the pages in and out of the 32-bit address
>> space and there are other limitations (e.g. is not pagefile backed).
>>
>>   * So, assuming you only have 2 GB of user-mode address space.=20
>> Windows DLLs will gobble up a few hundred megabytes at the upper end
>> of the space to map its DLL images.
>>
>>   * Your program and dependencies also have to be mapped into memory.=20
>> If you're smart, you take the time to rebase them and/or turn on ASLR
>> so that they occupy a contiguous block of memory.  Otherwise, you
>> could badly fragment the address space further.
>>
>>   * Your program will fragment the address space as it runs.  How
>> badly will depend on the memory allocator and the pattern of memory
>> allocations you make.
>>
>>   * An external program outside of your control might load/inject a
>> hook DLL into your process, and load it smack in the middle of your
>> address space, fragmenting it.  Or maybe it's a 3rd-party DLL/driver
>> that you load, but it's beyond your control.
>>
>> When it's all said and done, for many applications if you properly
>> rebase, you might get 1.5 GB contiguous space on a clean install of
>> Windows.  But it's too easy for that to fragment.  Realistically, you
>> can't allocate blocks more than maybe a couple hundred MBs to be
>> safe.  And you should try to allocate much more than 1 GB total.  Fire
>> up VMMap and point it at the average process on your computer -
>> especially a more complicated one that's been running for a while.=20
>> You might be surprised how small the largest free space block there is
>> for some programs.
>>
>> Sure there's an argument that you should split your data into smaller
>> allocations, but big allocations are awfully convenient for some
>> pieces of data.  In our case, we use a 3rd-party library that requires
>> us to store our large data sets in contiguous memory, so fragmentation
>> is a big problem.
> All of this is irrelevant to the request to make say /bin/ls 64 bit.

And why not? Even if the rest of the system has transitioned to 64bit?
Even compilers do benefit from that, especially due to giant C++ code
projects. It's all good once upon a time, but time to move on.

The worst thing you could do is have a mishmash of different subsystems
running together, 32bit/64bit mode switching will have performance
penalties.

>> For us, supporting the limited 4 GB 32-bit address space has turned
>> into a big annoyance in some of our applications.  It's not a
>> theoretical discussion.
> I don't understand why 64 bit Cygwin is an issue for you. Are you trying
> to build Cygwin executables? If not then isn't your question about
> building your 64 bit app better posed to Microsoft Visual Studio guys?

If you didn't know, GCC does win64 applications fine. The hard part for
porting Cygwin to win64 is the LP64 vs LLP64 issue. The former is used
by newlib, it is not easy to transition to Win64 LLP64.




--------------enigF0AE651F401F2CB8EBFD36EE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAk+23UcACgkQp56AKe10wHdYzACaA3oRhNRCbzuRosxUQneuv1Dk
vK0AnjjOXA/EE+GTzaayqHqKlg0DYO73
=6wLr
-----END PGP SIGNATURE-----

--------------enigF0AE651F401F2CB8EBFD36EE--

- Raw text -