> 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
