Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
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
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
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. Yupyou 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On Tue, May 22, 2012 at 01:15:24PM -0700, Matt Seitz (matseitz) wrote: From: Cygwin-L: On Behalf Of marco atzeri Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit cygwin program is pure academic and not very useful. If you want to propose patches for 64 bit cygwin cygwin-developers is the right mailing list. Sorry if I wasn't clear. That's exactly what I was trying to suggest: if someone wants a 64-bit Cygwin package, they should start by building such a package themselves, including any necessary changes to cygwin1.dll. Once you've got a working example, bring your results and patches to the maintainers. No, sorry. Please don't do this. Something this major requires serious coordination, not a 10,000 line patch. So, if someone seriously wants to do this then join the cygwin-developers list to discuss it. Don't start a discussion unless you want to actually do some work though. We're not keenly interested in your ideas unless you are thoroughly versed in how Cygwin works now and are willing to work to getting things working with a 64-bit compiler. cgf -- 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) wrote: Andrew DeFaria and...@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
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/ signature.asc Description: OpenPGP digital signature
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
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
64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
From: Cygwin-L On Behalf Of Warren Young 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. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits.
Re: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 22/05/2012 20:06, Matt Seitz (matseitz) wrote: From: Cygwin-L On Behalf Of Warren Young 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. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits. Hear hear. Well said. Perhaps we can drop this tedious thread now, or else TITTTL. IMHO it has shown rather lamentable knowledge of both compiler technology and RISC/CISC architecture from at least one responder. -- Cliff -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 5/22/2012 9:06 PM, Matt Seitz (matseitz) wrote: From: Cygwin-L On Behalf Of Warren Young 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. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits. Could you please stop this discussion ? Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit cygwin program is pure academic and not very useful. If you want to propose patches for 64 bit cygwin cygwin-developers is the right mailing list. Regards Marco -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
From: Cygwin-L: On Behalf Of marco atzeri Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit cygwin program is pure academic and not very useful. If you want to propose patches for 64 bit cygwin cygwin-developers is the right mailing list. Sorry if I wasn't clear. That's exactly what I was trying to suggest: if someone wants a 64-bit Cygwin package, they should start by building such a package themselves, including any necessary changes to cygwin1.dll. Once you've got a working example, bring your results and patches to the maintainers.
RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
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
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
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
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
Andrew DeFaria and...@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
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
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
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
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
Is the Latest Release of Cygwin supported on Windows Server 8/2012
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 carydcono...@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
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
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 -
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
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? signature.asc Description: OpenPGP digital signature
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
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
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. signature.asc Description: OpenPGP digital signature
