Message-Id: <200506130215.j5D2FDeE017175@delorie.com> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Gary R. Van Sickle" To: Subject: RE: Making /bin/sh == bash. Has the time come? Date: Sun, 12 Jun 2005 21:15:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-IsSubscribed: yes Ok, I reran the wxWidgets configure test, taking Thorsten's CONFIG_SHELL tip into account this time: /bin/sh = ash ============= export CONFIG_SHELL=/bin/bash; time ./transfigure real 3m21.888s user 5m2.357s sys 1m38.022s export CONFIG_SHELL=/bin/sh; time ./transfigure real 3m3.738s user 5m1.330s sys 1m28.028s time ./transfigure (I.e., default CONFIG_SHELL, which is empty) real 3m35.674s user 5m5.728s sys 1m51.104s /bin/sh = bash ============= export CONFIG_SHELL=/bin/bash; time ./transfigure real 3m35.286s user 5m6.974s sys 1m50.462s export CONFIG_SHELL=/bin/sh; time ./transfigure real 3m35.206s user 5m5.343s sys 1m48.977s So: - "transfigure" is a dead-simple shell script that just calls ./configure with a slew of config options. - Everything's faster today (real anyway), probably due to the following: - I'm probably using a different snapshot. - I cvs updated my wxWidgets source just before running the tests. - In the previous tests I wasn't particularly careful to leave the machine alone (did some web browsing, email etc). This time I made sure to do nothing during the tests. - Percentage differences between configuring with bash vs. ash: real: ~+17% user: ~+1% system: ~+25% - Apparently the only way to get ash used at all is by explicitly "export CONFIG_SHELL=/bin/sh"ing. In particular note the third ash test, where /bin/sh is ash, and yet the configure times appear to indicate that bash is in fact being used. Ergo: - Yes, sh is still faster than bash. - It's not a large enough difference that I would care about it. Others' mileage may perhaps vary. - It's unclear to me that it matters in any case, since apparently configures have been using bash anyway. - It's unclear to me then where the "sh is ash not bash" issues are actually coming from, if not from run-of-the-mill configures. - If it isn't configures, does anybody actually care about the semi-minor slowdown since it would eliminate "ash != bash" issues? Hence: - I still say /bin/sh == bash is the way to go. QED. -- Gary R. Van Sickle > -----Original Message----- > From: cygwin-owner AT cygwin DOT com > [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Gary R. Van Sickle > Sent: Friday, June 10, 2005 6:14 PM > To: cygwin AT cygwin DOT com > Subject: RE: Making /bin/sh == bash. Has the time come? > > Configuring wxWindows from cvs, on a 3.4GHz P4: > > Sh = Ash: > real 3m55.351s > user 5m8.610s > sys 1m53.240s > > Sh = Bash: > real 3m41.850s > user 5m6.220s > sys 1m53.426s > > Looks like the time has come. > > -- > Gary R. Van Sickle > > > > -----Original Message----- > > From: cygwin-owner AT cygwin DOT com > > [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Christopher Faylor > > Sent: Friday, June 10, 2005 10:07 AM > > To: cygwin AT cygwin DOT com > > Subject: Making /bin/sh == bash. Has the time come? > > > > A long time ago, in a Cygwin release prior to B20.1, someone > > made the decision to use "ash" as the standard /bin/sh for > > Cygwin. The sole reason for doing this was that ash was > > faster than bash. > > > > Later, at one point, I implemented a sorta-wannabe version of > > vfork, and commissioned one of the people who worked for me > > to modify ash to use vfork. This made ash even faster than > > it was before. > > > > Recently, after too many hours hacking at vfork corner cases, > > I came to the conclusion that getting vfork working correctly > > was too difficult so, I turned off vfork in cygwin and asked > > Corinna to modify ash to use /bin/sh again. > > > > So, that leaves us with an ash which is still faster. For example: > > > > e:\>time ash -c "i=0; while [ $i -lt 1000 ]; do i=$(expr $i > > + 1); done" > > 32.24user 9.72system 0:12.85elapsed 326%CPU > > (0avgtext+0avgdata 11677696maxresident)k > > 0inputs+0outputs (730699major+0minor)pagefaults 0swaps > > > > e:\>time bash -c "i=0; while [ $i -lt 1000 ]; do i=$(expr > > $i + 1); done" > > 49.86user 16.51system 0:23.04elapsed 288%CPU > > (0avgtext+0avgdata 20525056maxresident)k > > 0inputs+0outputs (1284873major+0minor)pagefaults 0swaps > > > > i.e., bash is twice as slow as ash. However: > > > > e:\>time bash -c "i=0; while [ $i -lt 1000 ]; do i=$(($i + > > 1)); done" > > 0.14user 0.01system 0:00.15elapsed 101%CPU > > (0avgtext+0avgdata 15712maxresident)k > > 0inputs+0outputs (982major+0minor)pagefaults 0swaps > > > > So, there are some constructs available in bash which, if you > > assume that bash == /bin/sh, will result in much faster shell > > script execution. > > > > And, anyone who reads this list regularly will know that we > > get a lot of complaints about the differences between bash > > and ash, which cause people to eventually copy bash to /bin/sh. > > > > So, in conversation with Corinna, I think that we're starting > > to lean towards making /bin/sh == bash sometime soon. We > > won't get rid of ash and will point to it when people send > > the inevitable "Cygwin is slow!" > > message here. > > > > I was thinking that we should have something like linux's > > "alternatives" > > command which would allow us to set up /bin/sh to whatever a > > user decides is best for them, defaulting to /bin/bash. This > > is, of course, trickier to do right on cygwin since you can't > > use a cygwin symbolic link to do a 'ln -s /bin/bash /bin/sh' > > but you could still do something with a copy, recording > > preferences in a file. > > > > Anyway, I wanted to get people's feelings on making this > > change. Is anyone actually relying on ash for some reason? > > > > cgf > > > > -- > > 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/ > > > > > -- > 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/ > -- 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/