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

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

[Matt Seitz (matseitz)]

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

I don't think Warren's note said there was a 4GB 32-bit executable.  I
think it said a 4GB 32-bit executable would be the worst case scenario
for 64-bit executable size bloat.

> Well have you considered the following: "Anyway I think I'm 
> done with this topic"? I didn't think so.

Are you saying Warren should not post a response to the mailing list,
just because you personally are no longer interested in the discussion?

As a subscriber, I've found reading both sides interesting and
informative.




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

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

[Andrew DeFaria]

On 5/21/2012 3:15 PM, Matt Seitz (matseitz) wrote:
> I don't think Warren's note said there was a 4GB 32-bit executable.  I think it said a 4GB 32-bit executable would be the worst case scenario for 64-bit executable size bloat.
It might be. What I was saying was if it doesn't exist (and probably 
isn't likely to exist anytime soon) then I don't personally worry about 
it. YMMV.
>> Well have you considered the following: "Anyway I think I'm
>> done with this topic"? I didn't think so.
> Are you saying Warren should not post a response to the mailing list,
> just because you personally are no longer interested in the discussion?
No I'm saying he should response my post, citing me as if to expect and 
answer from me when I am no longer interested in the topic.
-- 
Andrew DeFaria <http://defaria.com>
Why do women wear evening gowns to nightclubs? Shouldn't they be wearing 
night gowns?


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

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

[Andrew DeFaria]

On 5/21/2012 3:43 PM, Andrew DeFaria wrote:
> On 5/21/2012 3:15 PM, Matt Seitz (matseitz) wrote:
>> I don't think Warren's note said there was a 4GB 32-bit executable.  
>> I think it said a 4GB 32-bit executable would be the worst case 
>> scenario for 64-bit executable size bloat.
> It might be. What I was saying was if it doesn't exist (and probably 
> isn't likely to exist anytime soon) then I don't personally worry 
> about it. YMMV.
>>> Well have you considered the following: "Anyway I think I'm
>>> done with this topic"? I didn't think so.
>> Are you saying Warren should not post a response to the mailing list,
>> just because you personally are no longer interested in the discussion?
> No I'm saying he should response my post, citing me as if to expect 
> and answer from me when I am no longer interested in the topic.
I mean: He should *not* response to my post...
-- 
Andrew DeFaria <http://defaria.com>
Oops. My brain just hit a bad sector.


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

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

[Matt Seitz (matseitz)]

Ah, I didn't realize some people interpret quoting a post as expecting a
response from the author of the post.

When I quote from someone else's post, I do it for the purpose of giving
the context of my response.  I'm not necessarily expecting a response
from the author of the previous post.


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

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

[Andrew DeFaria]

On 5/21/2012 4:03 PM, Matt Seitz (matseitz) wrote:
> Ah, I didn't realize some people interpret quoting a post as expecting a response from the author of the post.
>
> When I quote from someone else's post, I do it for the purpose of giving the context of my response.  I'm not necessarily expecting a response from the author of the previous post.
It is common from Usenet and, come to think of it, most forums and other 
places that I've seen, that if you specifically quote somebody it's as 
if you are responding directly to them.

BTW: I read the Cygwin mailing list as a Usenet like newsfeed via gmane.org.
-- 
Andrew DeFaria <http://defaria.com>
In any conflict the boundaries of behavior are defined by the party 
which cares least about morality. - Randy Wayne White


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

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

[Matt Seitz (matseitz)]

What is a better way I can give context (and credit) when I am
responding to a message, without implying that I expect a reply from the
original author?

I've been a Usenet user since 1988, and I've never heard of the
convention of "quoting implies request for reply".  Replies from the
original author are always welcome, but I don't necessarily expect them.
Maybe I just missed the memo....

On the receiving side, if I didn't want to respond to a Usenet message,
I just didn't.  If I wasn't interested in a thread anymore, I just
stopped reading it, or put it in my "kill" file.

I read the Cygwin mailing list using the gmane.org newsfeed, too.  But I
was told that replying via my newsreader (Outlook Newsreader) messes up
the e'mail threading.  So now I subscribe to the digest as well, so that
I can reply to the SMTP e'mail instead of replying to the gmane NNTP
post.


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

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

[Linda Walsh]

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

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On 5/26/12 4:40 PM, Linda Walsh wrote:
> 
>     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 case

So the x32 ABI [1] should be better yet, right?

[1] https://lwn.net/Articles/456731/



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

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

[Tim Prince]

On 05/26/2012 07:40 PM, Linda Walsh wrote:
>
>
>     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.
>
There have been compilers for 32-bit Windows for 20 years which gave 
8-byte alignments by default.  cygwin changed the default configure 
parameter in binutils so as to support alignment about 8 years ago.  It 
was tolerable to some before then as it matters only for 64-bit and 
larger objects (doubles, and SSE, after that was introduced).  The 
characteristics of the worst compiler (with respect to alignment) 
available outside of cygwin don't have a bearing on this list.
If the powers that be have decided that 64-bit mode should be supported 
on cygwin setup.exe only by mingw cross compilers, I'll accept that.

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

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

[Linda Walsh]

Daniel Colascione wrote:

> On 5/26/12 4:40 PM, Linda Walsh wrote:
>>     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 case
> 
> So the x32 ABI [1] should be better yet, right?
> 
> [1] https://lwn.net/Articles/456731/
----

	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, but many will argue it's not worth the complexity -- hoping that 
the next gen of processors will make up the speed -- but that has stopped 
happening about 10 years ago when we hit the peak of single thread performance 
and had to scale down speed to go for breath.

	If a 32 bit process ran on a chip tuned for 32-bit and got back a 25% faster 
clock, it might have a prayer of a chance of competing, but there isn't much 
that will negate one of the largest time users -- Mem-to-mem copies *able* to be 
done in half the instructions on x64.

	Also, not of small consideration -- you can do alot more numeric applications 
with 27.8 digits of precision than with 13.9 digits before having
to revert to floating point.  Integer ops are orders of magnitude faster than
floating point.

	So how well a 'hypothetical' execution set would run...can be predicted
about as well as the stock market..



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

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

[Tim Prince]

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

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

[Linda Walsh]

Tim Prince wrote:

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

-----
	It's not the OS, machine and the width of the data path.
If you are operating in 32 bit mode, you are using 32 bit registers,
16 bit mode used AX, BX, CX  -- 16 bit registers.  32 bit mode went
to Double-words and used a D prefix for registers, 64 bit mode went
to Quad-words with Q prefixes.   a 32 bit compiler doesn't generate
the operands for Qword moves.

	These are HW issues, independent of the OS.

 The same data move instructions are present in either 
> OS.  It took years for glibc to implement efficient string moves for 
> x86_64, ...

	Yeah, and?   It's there now.

 and those still bump up against the question whether they always 
> use code which runs on the CPUs of a decade ago.

	Yup....you can compile a program for 32 bit mode and get code
that will run on old cpu's -- it won't be as efficient -- which is
the entire point of this discussion.


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

====
	Of course... But we are not just talking about cygwin.  We are
talking about whether or not there is a benefit in compiling and using
64-bit technology over current 32 bit technology.  That benefit IS there.
Whether or not cygwin is in a position to leverage that -- or when cygwin
will be in a position to leverage that is independent of the benefit that
is there.  Cygwin-64 will happen when it happens.  But to try to justify
it not happening because some claim there would be no benefit is the
fallacious argument.


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

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

[Christopher Faylor]

This discussion went off-topic quite some time ago.

Please let this die.

cgf

On Sat, May 26, 2012 at 08:51:22PM -0400, Tim Prince wrote:
>On 05/26/2012 07:40 PM, Linda Walsh wrote:
>>
>>
>>     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.
>>
>There have been compilers for 32-bit Windows for 20 years which gave 
>8-byte alignments by default.  cygwin changed the default configure 
>parameter in binutils so as to support alignment about 8 years ago.  It 
>was tolerable to some before then as it matters only for 64-bit and 
>larger objects (doubles, and SSE, after that was introduced).  The 
>characteristics of the worst compiler (with respect to alignment) 
>available outside of cygwin don't have a bearing on this list.
>If the powers that be have decided that 64-bit mode should be supported 
>on cygwin setup.exe only by mingw cross compilers, I'll accept that.
>
>-- 
>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
>
>

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

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

[Andrew DeFaria]

On 5/21/2012 1:48 PM, Warren Young wrote:
> On 5/21/2012 11:34 AM, Andrew DeFaria wrote:
>> IMHO it's the thinking of "Well hell we have tons of
>> memory/disk/whatever. Why don't we waste it?"
>
> I assure you, the move to 64-bit executables is not the reason Chrome 
> and your 3 JVMs are running you out of RAM.
>
> 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. What about 2 GB or 1 GB? Oh so it's not really 
relevant. Well have you considered the following: "Anyway I think I'm 
done with this topic"? I didn't think so.
> I've had 6-16 GB in all my desktop machines for years now.
Wonderful...ly also irrelevant.
-- 
Andrew DeFaria <http://defaria.com>
Ask people why they have deer heads on their walls and they tell you 
it's because they're such beautiful animals.I think my wife is 
beautiful, but I only have photographs of her on the wall.


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

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

[Warren Young]

On 5/21/2012 11:34 AM, Andrew DeFaria wrote:
> IMHO it's the thinking of "Well hell we have tons of
> memory/disk/whatever. Why don't we waste it?"

I assure you, the move to 64-bit executables is not the reason Chrome 
and your 3 JVMs are running you out of RAM.

Consider a 32-bit executable that is 4 GB in size.  It can't even run 
under an operating system, or do anything with data; it takes the entire 
32-bit address space just to load.  JonY has already correctly shown 
that the average bloat due to a 64-bit recompile is in the 20% 
neighborhood.  That means you swamp this worst-case 64-bit bloat with 
4.8 GB of RAM in the machine.

I've had 6-16 GB in all my desktop machines for years now.

There are reasons not to move to 64-bit.  Executable size is not one of 
those reasons.  Inertia is a much better reason.

> I remain unconvinced that a 64 bit Cygwin is required or
> necessary or even worth it at this time.

I would say that the vast majority of the packages in the Cygwin 
distribution could not reasonably make use of 64-bit data spaces.

However, one of your arguments in this thread cuts both ways: the fact 
that there are a few packages that reasonably can do so means you cannot 
say "we don't need it".

The easiest place to see the need for 64-bitness is in the programming 
language compilers and interpreters.

With the dynamic language interpreters (Perl, Python, etc.) the  bitness 
of the interpreter affects the address space available for program data.

Big Data is a Big Thing right now, and one of the things driving it is 
commodity 64-bit CPUs and cheap RAM.  One of the biggest languages in 
this space is R, and one of its historical limitations is that it has to 
load all data entirely in RAM to operate on them.  Moving to 64-bit 
directly affects the data set size you can analyze.

You see some pressure here in the static language compilers, too.  (C, 
C++, etc.)  A few months ago there was a furor in the blogosphere over 
the fact that Firefox can't even build any more with full optimization 
under a 32-bit OS.  Even when making 32-bit builds, they have to do it 
on a 64-bit system just so the optimizer can keep all the balls in the 
air.  (See http://goo.gl/oYvhE for the story.)

There are sketchier examples to be found in the Cygwin package repo, 
like Apache and MySQL.  I'd argue that you should move to the native 
versions before you send the Cygwin ports up against a big enough load 
that they can start making use of more than 4 GB of RAM, though, since 
the I/O overhead would probably be a bigger problem than RAM before that 
point.

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

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

[Andrew DeFaria]

On 5/21/2012 10:36 AM, James Johnston wrote:
> Hey, why isn't "ls" a 16-bit program?
That's a real good question!

Meantime have you seen that I posted this: "Anyway I think I'm done with 
this topic"?

That is all.
-- 
Andrew DeFaria <http://defaria.com>
The box said to install Windows XP/Vista or better - so I installed Linux!


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

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

[James Johnston]

> On 5/18/2012 4:37 PM, JonY wrote:
> >> 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.
> If so then they were wrong.

Hey, why isn't "ls" a 16-bit program?  Realistically, it does not need anything offered by 32-bit architectures to do its job...

> > Those are just pointers, instructions do not necessary double in size,
> I was under the impression that the instruction size matches the natural
> word size of the machine. Therefore they would be 64 bit instructions.
> > 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.
> I believe my AMD64 is considered a RISC computer. According to
> http://www.tek-tips.com/faqs.cfm?fid=788 "The K5 and K6 series are
> internally a highly parallel RISC processor using an x86 decoding front-end".

The key word is **internally** - also known as "hidden implementation detail."  Those processors still present a CISC-type instruction set, as it says "x86 decoding front-end".  The core, proprietary architecture is not accessible to you or Cygwin.  You still have to pretend you are targeting the CISC environment, even if the underlying implementation isn't.  Maybe the underlying implementation does use fixed 64-bit wide instructions, but you don't get to write for it.

64-bit Intel Architecture didn't magically/radically change the instruction set to be a new one.  They had to preserve backwards-compatibility, so they kept the CISC instruction set.  64-bit is just an additional set of extensions thrown on top of the already-bloated x86 architecture.  (Which happens to be detrimental to the hardware, since they have to create special decoders to translate the crufty old instruction set known as x86). 

If you want to reduce bloat, go use a newer architecture like ARM.  One need only look at the first alphabetically-listed x86 instruction to see how bad it is!

Example:  "AAA	ASCII adjust AL after addition	used with unpacked binary coded decimal"

Really...?

> And according to
> https://en.wikipedia.org/wiki/Instruction_set: "In some architectures,
> notably most reduced instruction set computers (RISC), instructions are a
> fixed length, typically corresponding with that architecture's word size".

And this would probably be true if you weren't working with an x86 decoder front-end that forces use to use variable-width instructions instead. 

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

Because your arguments about reduced performance seemed to imply that you thought this was the case, when it is not.

A bloated EXE in and of itself does not create system memory pressure.  It is only when large portions of that EXE are used and must be loaded into physical memory.

For example, create an EXE with a large (e.g. 500 MB) resource in it.  It will load instantly and create no major memory pressure.  Only when the resource is accessed will there be memory pressure. 

> > Even if the rest of the system has transitioned to 64bit?
> Even if the rest transitioned what? Your question doesn't make sense again.

I think he means, if other parts of Cygwin move to 64-bit to address real problems (e.g. due to reduced address space, or the need to run on a 64-bit only environment), would you still keep "ls" as 32-bit and run it in a mixed 32/64-bit environment?  Or move the entire platform to 64-bit, just to keep things consistent?  (See my snarky "16-bit" comment at the top...)


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

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

[Andrew DeFaria]

On 5/21/2012 10:18 AM, James Johnston wrote:
> 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. 
I'm not sure how you can say this. There are people who do care and do 
notice. So instead of using absolutes (there is not a single user) 
implying without exception you should use something like "Most users 
will not notice or care".
>> 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.
And for others...?
> 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.
In my line of work I (unfortunately) often have to run up to 3 JVMs at a 
time. Thunderbird takes a chunk (I think Lightning leaks memory) as does 
Chrome. Hell Chrome takes most of it. I often get to the point of 
addressing exceptions and even crashes of apps and protestations of "Out 
of memory". I have 4 gig of memory.

IMHO it's the thinking of "Well hell we have tons of 
memory/disk/whatever. Why don't we waste it?" which eventually causes 
the mentality of "don't worry about it" that leads to bloating.

In any event, I remain unconvinced that a 64 bit Cygwin is required or 
necessary or even worth it at this time. The only argument even 1/2 way 
compelling is your statement that there are some Windows server editions 
that lack the 32-bit subsystem. I was unaware that that was even 
happening and it is the first time I've heard of it.

Anyway I think I'm done with this topic.

-- 
Andrew DeFaria <http://defaria.com>
Is it true that cannibals don't eat clowns because they taste funny?


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

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

[James Johnston]

> 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

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

On 5/19/2012 11:25, Andrew DeFaria wrote:
> On 05/18/2012 07:39 PM, JonY wrote:
>>> I was under the impression that the instruction size matches the natural
>>> word size of the machine. Therefore they would be 64 bit instructions.
>> No, we are talking about x86, not MIPS/ARM type RISC.
> Really? OK - Show me! Because the first mention of even CISC was *your*
> posting two posts ago. Just because you were talking about x86 does not
> mean that I was talking about x86.
>> Which do not apply to CISC CPUs, whatever implementation underneath is
>> tangent to the user code ISA, the opcodes did not double in size. Please
>> at least look at the x86 opcode, they are known to have variable lengths.
> I was not talking about your x86 - you were.

Cygwin runs only on x86 Windows, which is on a CISC CPU, with variable
length instructions.

You maintained that instruction sizes are doubled. This is not true of
CISC, especially the entire x86 line. You veered into AMD64 having a
RISC implementation underneath, which is of little consequence since it
is at the microcode level. This technique is in use since the Pentium
Pro days.

>>> I still don't understand what having a 64 bit version of ls or grep will
>>> do for ya...
>> Since 64-bit mode cannot be avoided,
> Excuse me but it seems to me that right now it is being avoided quite
> successfully. Cannot be avoided? Really?
>> there is simply no reason to keep
>> legacy mode applications and all that baggage if you can easily rebuild
>> and move to 64-bit mode.
> If a 32 bit executable will run on a 64 bit machine, but a 64 bit
> executable will not run on a 32 bit machine, there's no good
> justification to have to maintain two different builds and sets of bits.

This is no reason to hold back on transitioning to 64bit though. Once
you do, there is little reason to keep the baggage if all your programs
don't need it. This was what OP was concerned about.

>> You don't keep 16-bit programs lying about when there are 32-bit
>> programs doing the same thing right?
> When 32 bit just came around, you betcha I did - and so did you.
> 
> All that said, I'd like to see it all move to 64 bit and I know it will,
> eventually. But I can understand the rational for not doing it at this
> time.

You have to start somewhere somehow, perhaps with a tiny step, how it
goes depends on the Cygwin development committee.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

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

[Andrew DeFaria]

On 05/18/2012 07:39 PM, JonY wrote:
>> I was under the impression that the instruction size matches the natural
>> word size of the machine. Therefore they would be 64 bit instructions.
> No, we are talking about x86, not MIPS/ARM type RISC.
Really? OK - Show me! Because the first mention of even CISC was *your* 
posting two posts ago. Just because you were talking about x86 does not 
mean that I was talking about x86.
> Which do not apply to CISC CPUs, whatever implementation underneath is
> tangent to the user code ISA, the opcodes did not double in size. Please
> at least look at the x86 opcode, they are known to have variable lengths.
I was not talking about your x86 - you were.
>> I still don't understand what having a 64 bit version of ls or grep will
>> do for ya...
> Since 64-bit mode cannot be avoided,
Excuse me but it seems to me that right now it is being avoided quite 
successfully. Cannot be avoided? Really?
> there is simply no reason to keep
> legacy mode applications and all that baggage if you can easily rebuild
> and move to 64-bit mode.
If a 32 bit executable will run on a 64 bit machine, but a 64 bit 
executable will not run on a 32 bit machine, there's no good 
justification to have to maintain two different builds and sets of bits.
> You don't keep 16-bit programs lying about when there are 32-bit
> programs doing the same thing right?
When 32 bit just came around, you betcha I did - and so did you.

All that said, I'd like to see it all move to 64 bit and I know it will, 
eventually. But I can understand the rational for not doing it at this time.
-- 
Andrew DeFaria <http://defaria.com>
I'm not into working out. My philosophy is no pain, no pain.


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

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

On 5/19/2012 09:15, Andrew DeFaria wrote:
> On 5/18/2012 4:37 PM, JonY wrote:
>>> 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.
> If so then they were wrong.
>> Those are just pointers, instructions do not necessary double in size,
> I was under the impression that the instruction size matches the natural
> word size of the machine. Therefore they would be 64 bit instructions.

No, we are talking about x86, not MIPS/ARM type RISC.

>> 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.
> I believe my AMD64 is considered a RISC computer. According to
> http://www.tek-tips.com/faqs.cfm?fid=788 "The K5 and K6 series are
> internally a highly parallel RISC processor using an x86 decoding
> front-end". And according to
> https://en.wikipedia.org/wiki/Instruction_set: "In some architectures,
> notably most reduced instruction set computers (RISC), instructions are
> a fixed length, typically corresponding with that architecture's word
> size". Things might be different now. I really don't keep up with
> processors anymore.

Which do not apply to CISC CPUs, whatever implementation underneath is
tangent to the user code ISA, the opcodes did not double in size. Please
at least look at the x86 opcode, they are known to have variable lengths.

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

Binary sizes do not correspond to memory usage, not anymore.

>>> All of this is irrelevant to the request to make say /bin/ls 64 bit.
>> And why not?
> And why not what? Your question doesn't make sense.
>> Even if the rest of the system has transitioned to 64bit?
> Even if the rest transitioned what? Your question doesn't make sense again.
>> 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.
> I still don't understand what having a 64 bit version of ls or grep will
> do for ya...

Since 64-bit mode cannot be avoided, there is simply no reason to keep
legacy mode applications and all that baggage if you can easily rebuild
and move to 64-bit mode.

You don't keep 16-bit programs lying about when there are 32-bit
programs doing the same thing right?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

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

[Andrew DeFaria]

On 5/18/2012 4:37 PM, JonY wrote:
>> 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.
If so then they were wrong.
> Those are just pointers, instructions do not necessary double in size,
I was under the impression that the instruction size matches the natural 
word size of the machine. Therefore they would be 64 bit instructions.
> 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.
I believe my AMD64 is considered a RISC computer. According to 
http://www.tek-tips.com/faqs.cfm?fid=788 "The K5 and K6 series are 
internally a highly parallel RISC processor using an x86 decoding 
front-end". And according to 
https://en.wikipedia.org/wiki/Instruction_set: "In some architectures, 
notably most reduced instruction set computers (RISC), instructions are 
a fixed length, typically corresponding with that architecture's word 
size". Things might be different now. I really don't keep up with 
processors anymore.
>>> 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.
So what.
>> All of this is irrelevant to the request to make say /bin/ls 64 bit.
> And why not?
And why not what? Your question doesn't make sense.
> Even if the rest of the system has transitioned to 64bit?
Even if the rest transitioned what? Your question doesn't make sense again.
> 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.
I still don't understand what having a 64 bit version of ls or grep will 
do for ya...
-- 
Andrew DeFaria <http://defaria.com>
I've taken a vow of poverty -- to annoy me, send money


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

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 7312 bytes --]

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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

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

[Andrew DeFaria]

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).
>> 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.
> 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.
>> 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.  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.  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.  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.  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.
> 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?
> To the OP:  there has been lots of discussion about 64-bit on the Cygwin developer list; you may want to read up on the conversations there...
-- 
Andrew DeFaria <http://defaria.com>
An error? Impossible! My modem is error correcting.


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

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

[James Johnston]

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

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

Besides, who cares that much about the image size these days?  We don't, within reason.

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

You say you get 4 GB but for many applications that is only a dream:

 * Most applications are not compiled to be large address aware, which means that they only get 2 GB of address space - not 4 GB.  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.

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

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.

To the OP:  there has been lots of discussion about 64-bit on the Cygwin developer list; you may want to read up on the conversations there...


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

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

[Andrew DeFaria]

On 05/18/2012 07:46 AM, Cary Conover wrote:
> Was wondering with major changes to the base distro of Windows Server
> 8/2012 is anyone running compatibility tests on the platform and if so
> what observed results were? Will or Does Cygwin run on Windows Server
> 8/2012?  I have seen some comments about difficulties with Cygwin on
> Windows 8 desktop but have not heard much about Server Edition.
> Trying to determine if Cygwin latest release is an option to run
> Unix/Posix Products on Windows Server 8/2012
Don't know about Windows 8 Server. Is anybody running that? Is it even 
released?
> Are there any efforts to make 64bit Releases under consideration?
>
> The reason for the question is it does not make sense to have a 64 bit
> Server with a 32 bit emulator for POSIX running any major products on
> any Server Operating System Product.
>
> This is like having Porsche running with a small VW Engine under the
> hood.  Yes it is hopped up and can run fast.  But it is not going to
> run like the turbo charged Porsche.  So why pay the price of a Porsche
> when you really are running a VW?
64-bit does not make things go any faster than 32-bit. 64-bit is 
wasteful as programs grow to double in size. 64-bit is only 
required/useful/etc if you have memory requirements > 4 gig. I don't 
think any Cygwin executable has such requirements...
-- 
Andrew DeFaria <http://defaria.com>
Why is it called Alcoholics Anonymous when the first thing you do is 
stand up and say, "My name is Bob, and I am an alcoholic"?


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

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

[Cary Conover]

Was wondering with major changes to the base distro of Windows Server
8/2012 is anyone running compatibility tests on the platform and if so
what observed results were? Will or Does Cygwin run on Windows Server
8/2012?  I have seen some comments about difficulties with Cygwin on
Windows 8 desktop but have not heard much about Server Edition.
Trying to determine if Cygwin latest release is an option to run
Unix/Posix Products on Windows Server 8/2012

Are there any efforts to make 64bit Releases under consideration?

The reason for the question is it does not make sense to have a 64 bit
Server with a 32 bit emulator for POSIX running any major products on
any Server Operating System Product.

This is like having Porsche running with a small VW Engine under the
hood.  Yes it is hopped up and can run fast.  But it is not going to
run like the turbo charged Porsche.  So why pay the price of a Porsche
when you really are running a VW?

Regards,
Cary

Cary D. Conover
Phone 309-929-4918 Google Voice
gmail carydconover@gmail.com
Calls Follow Me!

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