This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
Matt Seitz (matseitz) wrote:
"Andrew DeFaria" <Andrew@DeFaria.com> wrote in message
news:<jpec46$b4v$1@dough.gmane.org>...
On 5/21/2012 1:48 PM, Warren Young wrote:
On 5/21/2012 11:34 AM, Andrew DeFaria wrote:
Consider a 32-bit executable that is 4 GB in size.
Do you know of one 32-bit executable that is 4 GB in size? Just one?
OK,
how about 3 GB? No.
---
The benefits of a 64-bit built are trivial to understand.
I've yet to see a program that has not improved by *at least* 10-15%,
up to as much as 20% in execution speed, simply by recompiled for the x64
instruction set.
Memory has nothing to do with it.
Every time you fetch a word or instruction that is not 8-byte aligned,
you force a fatal (but caught by the processor and/or OS) signal for unaligned
data. That forces execution out of the pipeline (though not likely out of
cache, sadly, due to frequency of occurrence). That's not counting the extra
cycles to fetch the rest of the data. On some machines that can easily amount
to several dozen instructions worth.
So please don't go on about size of memory being important -- though it can be
on a few progs. Only ones using > 3G user mem on my linux system are
multiple copies of squid (likely much of that shared, but caches alot in
memory), and console-kit.
On windows -- maybe long or large browsing sessions (with scores of
windows/tabs open)...
Compiling for 64-bit is about memory alignment and native instruction
set/word size execution. The alignment will likely cause runtime memory usage
to grow somewhat, but it shouldn't be significant in most cases.
--
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