RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012

["James Johnston" <JamesJ@motionview3d.com>]

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

I don't know; I'm a C/C++ programmer, not an x86 assembly programmer.  Ask Intel; they made the compiler that is spitting out 64-bit code that is smaller/faster than the equivalent 32-bit code...  (The opposite example where 32-bit was smaller was compiled with VC++).  At any rate, the differences in image size is not interesting to pursue further...  And there is not a single user who will notice or care that the second example has a larger 64-bit image by a few hundred KB larger.

64-bit Intel architecture instructions aren't necessarily twice the width as 32-bit architecture instructions.  The instruction widths are highly variable, depending on the instruction.  They are certainly not going to be 2x the width every time.  Read the Intel Architecture Software Developer's Manual...
	
> > 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.

64-bit virtual memory space isn't a concern for now; it's quite large so of course even the largest images fit without issue.  So it's just a question of physical memory usage and disk activity.

If I'm not mistaken, Windows doesn't completely load an image into physical memory when you run it; the program file is memory-mapped into virtual memory and it will only swap in memory pages from disk when you actually need to run the code (directly from the EXE file).  And the pagefile isn't needed, unless the program is self-modifying.

(Of course, if one writes a program to be bloated and require lots of code loaded in memory simultaneously to run well, then nobody can save it from inefficiencies on either 32-bit or 64-bit...)

> Small is beautiful.

In general I agree; controlling the bloat is a worthwhile (and needed) activity for some apps.  But for me, bloat due to 64-bit compilation is worth it.  I have enough RAM that I can fit images into physical memory, and then the runtime improvements of 64-bit can kick in (faster, more address space).  I would not mind it at all if every image on my Windows PC could be 64-bit!  App crashing due to address space exhaustion in 32-bit apps is not something I enjoy dealing with. 

I've got 6 GB RAM on my work computer, and that's usually plenty; the only time it understandably slows down is when using multiple virtual machines. 

> All of this is irrelevant to the request to make say /bin/ls 64 bit.

I very much doubt ls would experience any improvement at all to going 64-bit.  It probably never will.  If that's all the OP cares about, then he/she doesn't need it.  The only reason I see for moving that particular tool to 64-bit is to make it fit in better to a larger 64-bit platform, so that you aren't mixing 32-bit/64-bit code together.

Obviously that was enough justification for Microsoft, given that even simple, mundane tools like "calc.exe" are 64-bit.

> I don't understand why 64 bit Cygwin is an issue for you. Are you trying to
> build Cygwin executables?

No.  And for us, we don't use any Cygwin EXEs needing lots of memory.  We don't really have an immediate need for 64-bit Cygwin at this time.  The statements I made earlier were in relation to other non-Cygwin projects that do have higher memory requirements.

But I can easily see why other people might need 64-bit Cygwin.  So, sweeping statements like all Cygwin executables don't need 64-bit are too broad; that's why I made the 640k memory limit comment.

Some examples of why someone else might be needing 64-bit Cygwin:
 * Some Windows Server versions don’t even have the 32-bit subsystem any more, or it's optional.
 * Maybe you're loading a large dataset into Octave, a Cygwin package, and need the address space.
 * Loading large datasets into other Cygwin software, and needing the address space.
 * Interfacing with other 64-bit software.

Sooner or later (probably much later), the 32-bit subsystem is going to go away (as already evidenced by Windows Server), much like the 16-bit subsystem already has.  For consumer Windows versions, this is years away since 32-bit software still ships brand new...  Doesn't mean it will never happen, though.  A big reason for removal of the 16-bit subsystem in 64-bit Windows was that you simply cannot run that code when the processor is running a 64-bit operating system.  The processor architecture does not allow for it, so Microsoft would have had to write an emulator, which they did not do.  Who knows - maybe this same fate will befall 32-bit software years in the future...

> If not then isn't your question about building your
> 64 bit app better posed to Microsoft Visual Studio guys?

My discussion was about why 64-bit can be beneficial for some types of applications, based on my experience outside of Cygwin.  And I think it is possible that some Cygwin applications when used by some people could benefit.


--
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