Re: Updated: cygwin-1.5.25-5
I'm running cygwin-1.5.25-7 now and experiencing NO performance problems. I also upgraded to Vista SP1 (release candidate), but I don't know if that had anything to do with it. - Jim On 12/9/2007 10:49 AM, Jim Reisert AD1C wrote: I have a number of data processing programs written in C in the Cygwin environment. They read data files into linked lists, analyze the data and write results back out to disk. This new release of Cygwin is about 10x slower than 1.5.24-2, after recompiling the programs. I went back to the older Cygwin release and normal speed was restored. I am running Cygwin on a Intel Q6600 (2.4 GHz quad core) running Vista Ultimate 64. Any idea how to find out where the bottleneck(s) are? -- Jim Reisert AD1C/Ø, <[EMAIL PROTECTED]>, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: cygwin-1.5.25-5
> I don't understand what you mean. Using> on the command line or > opening the file by using some option of the tool has both nothing to do > with console output. In both cases a file is opened. The only I didn't give it a lot of additional thought, I just stopped using ">" ( when I have significant amounts of output ) a while ago and assumed it had something to do with buffering- I have no idea what is going on once I call "<<" and I never did a version by version test. Similarly, I essentially stopped using std::string since for most of what I did it was easier to do a block read anyway. I'm simply pointing out that the details appear to matter and, as you request, a test case would help but the gprof output could point to some surprising suspects. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only [EMAIL PROTECTED] Note: Hotmail is blocking my mom's entire ISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'T assume I am ignoring you and try me on [EMAIL PROTECTED] if no reply here. Thanks. > Date: Mon, 10 Dec 2007 15:03:34 +0100 > From: [EMAIL PROTECTED] > To: cygwin@cygwin.com > Subject: Re: Updated: cygwin-1.5.25-5 > > On Dec 10 08:40, Mike Marchywka wrote: >>> I can't reproduce worse I/O performance. I tested different scenarios >>> with lots of disc I/O and the performance was identical between 1.5.24 >>> and 1.5.25 within the bounds of a performance test. >>> >> >> >> One thing I found out, after originally blaming my inner computational loops, >> was that console IO is very slow. Using ">" on the command line makes a big >> difference compared to opening a destination file. This seemed to be the >> speed limit in many programs I thought were computationally limited. >> [...] >> Has the console buffering >> changed lately? > > I don't understand what you mean. Using> on the command line or > opening the file by using some option of the tool has both nothing to do > with console output. In both cases a file is opened. The only > difference in that in the> case the shell opens the file and the child > inherits the file descriptor, in the other case the child opens the file > by itself. However, I don't see how getting a file descriptor to a file > from the parent should be different than opening the file in the child, > at least as long as parent and child are both Cygwin processes. > > In fact, one of my tests was a loop using `cat < foo> bar', which got > much faster under 1.5.25 due to the new 64K buffering. > > Give me a really simple testcase which shows reproducibly worse > performance on 1.5.25 compared to 1.5.24 and I'll have another look. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > _ Connect and share in new ways with Windows Live. http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: cygwin-1.5.25-5
On Dec 10 08:40, Mike Marchywka wrote: > > I can't reproduce worse I/O performance. I tested different scenarios > > with lots of disc I/O and the performance was identical between 1.5.24 > > and 1.5.25 within the bounds of a performance test. > > > > > One thing I found out, after originally blaming my inner computational loops, > was that console IO is very slow. Using ">" on the command line makes a big > difference compared to opening a destination file. This seemed to be the > speed limit in many programs I thought were computationally limited. > [...] > Has the console buffering > changed lately? I don't understand what you mean. Using > on the command line or opening the file by using some option of the tool has both nothing to do with console output. In both cases a file is opened. The only difference in that in the > case the shell opens the file and the child inherits the file descriptor, in the other case the child opens the file by itself. However, I don't see how getting a file descriptor to a file from the parent should be different than opening the file in the child, at least as long as parent and child are both Cygwin processes. In fact, one of my tests was a loop using `cat < foo > bar', which got much faster under 1.5.25 due to the new 64K buffering. Give me a really simple testcase which shows reproducibly worse performance on 1.5.25 compared to 1.5.24 and I'll have another look. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: cygwin-1.5.25-5
> I can't reproduce worse I/O performance. I tested different scenarios > with lots of disc I/O and the performance was identical between 1.5.24 > and 1.5.25 within the bounds of a performance test. > One thing I found out, after originally blaming my inner computational loops, was that console IO is very slow. Using ">" on the command line makes a big difference compared to opening a destination file. This seemed to be the speed limit in many programs I thought were computationally limited. fwiw, I mentioned gprof to the OP earlier. I hadn't used this before but it should give you some idea where the time goes. It may be interesting to compare times with output sent to stdout versus a file. Obviously, you want to flush the console more often most of the time. Has the console buffering changed lately? Also, in the past, I think std::string operations were a problem but I saw this in a list of bugs specific to a compiler version. In fact, it looks like the gprof output is given as evidence here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15002 Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only [EMAIL PROTECTED] Note: Hotmail is blocking my mom's entire ISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'T assume I am ignoring you and try me on [EMAIL PROTECTED] if no reply here. Thanks. > Date: Mon, 10 Dec 2007 14:28:02 +0100 > From: [EMAIL PROTECTED] > To: cygwin@cygwin.com > Subject: Re: Updated: cygwin-1.5.25-5 > > On Dec 10 10:57, Corinna Vinschen wrote: >> On Dec 9 10:49, Jim Reisert AD1C wrote: >>> I have a number of data processing programs written in C in the Cygwin >>> environment. They read data files into linked lists, analyze the data >>> and write results back out to disk. >>> >>> This new release of Cygwin is about 10x slower than 1.5.24-2, after >>> recompiling the programs. I went back to the older Cygwin release and >>> normal speed was restored. >> >> Well, 10x sounds rather bad. > > I can't reproduce worse I/O performance. I tested different scenarios > with lots of disc I/O and the performance was identical between 1.5.24 > and 1.5.25 within the bounds of a performance test. > > In some cases applications are even getting faster under 1.5.25, for > instance cat(1) from coreutils. This is likely due to the fact that > the st_blksize member in struct stat now returns 65536 (apparently the > preferred I/O blocksize in Windows). This should also positively affect > the stdio functions like fread/fwrite. > > Given the above, we really need a simple, self-contained testcase, > as I asked for in my previous mail on the subject. > > > Corinna > > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > _ Your smile counts. The more smiles you share, the more we donate. Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: cygwin-1.5.25-5
On Dec 10 10:57, Corinna Vinschen wrote: > On Dec 9 10:49, Jim Reisert AD1C wrote: > > I have a number of data processing programs written in C in the Cygwin > > environment. They read data files into linked lists, analyze the data > > and write results back out to disk. > > > > This new release of Cygwin is about 10x slower than 1.5.24-2, after > > recompiling the programs. I went back to the older Cygwin release and > > normal speed was restored. > > Well, 10x sounds rather bad. I can't reproduce worse I/O performance. I tested different scenarios with lots of disc I/O and the performance was identical between 1.5.24 and 1.5.25 within the bounds of a performance test. In some cases applications are even getting faster under 1.5.25, for instance cat(1) from coreutils. This is likely due to the fact that the st_blksize member in struct stat now returns 65536 (apparently the preferred I/O blocksize in Windows). This should also positively affect the stdio functions like fread/fwrite. Given the above, we really need a simple, self-contained testcase, as I asked for in my previous mail on the subject. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: cygwin-1.5.25-5
On Dec 9 10:49, Jim Reisert AD1C wrote: > I have a number of data processing programs written in C in the Cygwin > environment. They read data files into linked lists, analyze the data > and write results back out to disk. > > This new release of Cygwin is about 10x slower than 1.5.24-2, after > recompiling the programs. I went back to the older Cygwin release and > normal speed was restored. Well, 10x sounds rather bad. What I don't understand is why you recompiled the applications in the first place. There's no really new functionality which would demand a recompilation. The question here is, was the original application alredy 10x slower or was it ok and only the recompiled version was slower? Or is the executable from the same build 10x slower on 1.5.25? > Any idea how to find out where the bottleneck(s) are? Debugging? You can try to find out which function got slower by stracing or you could use the good old printf debugging in your own code. Other than that, it would be helpful to create a minimal testcase in plain C, which only contains the absolute minimum of code to reproduce the problem, and send it to the list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: cygwin-1.5.25-5
I have a number of data processing programs written in C in the Cygwin environment. They read data files into linked lists, analyze the data and write results back out to disk. This new release of Cygwin is about 10x slower than 1.5.24-2, after recompiling the programs. I went back to the older Cygwin release and normal speed was restored. I am running Cygwin on a Intel Q6600 (2.4 GHz quad core) running Vista Ultimate 64. Any idea how to find out where the bottleneck(s) are? Thanks - Jim -- Jim Reisert AD1C/Ø, <[EMAIL PROTECTED]>, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: cygwin-1.5.25-5
I've made another version of the Cygwin DLL, 1.5.25-5, and associated utilities available. This is a bug fix release. Important changes since 1.5.24-2: - Fix a bug in memory allocation which results in an enormous waste of internal heap memory when using mmap(2) a lot. - Fix a bug in memory allocation which can result in unexpected SEGVs. - Always add LOCAL and INTERACTIVE groups to user tokens to fix some permission problems on Windows 2003 Server and later. - Set preferred IO blocksize to 64K for performance reasons. - Add missing baudrates for serial IO up to 3.000.000 baud. - Fix various race conditions in process exit, in dll initialization, when starting native Win32 processes, and in signal handling. - Fix a couple of buffer-related problems when accessing raw disk devices. - Fix bug in dlclose. - Don't set TZ environment variable in calls to tzset. - Don't follow symlinks in calls to open if O_EXCL is given. - Fix deadlock and reentrancy problems in stdio functions. Fix append mode handling in stdio functions. - Fix append mode bug when accessing files > 4 Gigs. - Various fixes to stat/fstat/lstat functions (wrong permission bits, timestamps, etc). - Fix a deadlock problem in fork, as well as a crash on fork after calling shmctl(IPC_RMID). - Add thread-safety to mmap and to XSI IPC calls. - Drop a non-sensical check in pthread_key_create. - Encode special characters in /proc/registry key and value names to avoid invalid character problems. - Assorted fixes to cygpath.exe, cygcheck.exe, dumper.exe and mkgroup.exe. - Add the ability to deal with 64 bit Windows registry keys to regtool.exe. - Various bugfixes to printf/scanf function families. Add support for j, t, and z modifiers to scanf functions. - Close security hole in tmpfile. - Fix potential crashes in argz functions. - Fix long-standing regression in rewind error handling. - Support NULL output buffer in wcstombs. - Solve a name clash problem between struct timezone and the timezone variable. - Disallow linking against the old timezone function. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions, then look for 'cygwin' in the 'Base' category (it should already be selected). If you have questions or comments, please send them to the Cygwin mailing list. See http://cygwin.com/lists.html for details. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Corinna Vinschen Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
