Re: Making /bin/sh == bash. Has the time come?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 6/11/2005 2:49 AM: Looks like the time has come. Wow. I never expected that bash would actually be faster. I would appreciate getting a few more benchmarks for other packages. If this holds out then moving to bash is a no-brainer. Looks like we're just waiting for Eric Blake to return from vacation. Well, I've just returned, but have several hundred emails to plow through to see what else happened while I was out. Have any of these benchmarks been run with the bash-3.0-2 experimental version? Currently, bash-3.0-2 dynamically links in libintl and libiconv (along with at least sed and coreutils, which is a good reason that these libraries should be made part of the base packages). Does dynamic linking affect the time for a fork() to take place, positively or negatively? Also, I am still waiting for an updated libreadline6 package before bash can dynamically link against libreadline as opposed to its own static version of readline. And it will take some time before I can audit the bash source code to see if there are any fork/exec pairs that can be rewritten with a spawn idiom, to see if that offers any speed improvements. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtr+/84KuGfSFAYARArZ3AJ0cu3kTDkEUFf7nVVvEEOKNwj+pSQCgqDqe oipNP9n7eKN1fVv5f02kZ7M= =ahck -END PGP SIGNATURE- -- 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: Making /bin/sh == bash. Has the time come?
On Fri, 10 Jun 2005, Shankar Unni wrote: Christopher Faylor wrote: So, in conversation with Corinna, I think that we're starting to lean towards making /bin/sh == bash sometime soon. Excellent idea. And it even seems to handle the automatic switch to POSIX mode correctly when called sh.exe. Talking of which, how good is pdksh these days? Using your exec-expr-in-a-loop microbenchmark (without the builtin), it seems to be nearly as fast as ash (within a few percent), and almost 1.5x as fast as bash (I got 20, 23 and 38 seconds for ash, pdksh and bash respectively). And for the builtin (using $((i+1))) loop, it's still nearly 4x as fast as bash (0.06 vs 0.23 seconds, or 0.25 vs 1.1 seconds for 1 iterations). Is it stable enough (and well-enough maintained) to be considered for being the shell? And just to clear up any confusion: pdksh *is* maintained (by me), and it's been so stable that I hadn't had to do much with it except repackage for the FHS change. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: Making /bin/sh == bash. Has the time come?
Krzysztof Duleba wrote: Christopher Faylor wrote: On Fri, Jun 10, 2005 at 06:13:31PM -0500, Gary R. Van Sickle wrote: Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. Wow. I never expected that bash would actually be faster. I would appreciate getting a few more benchmarks for other packages. If this holds out then moving to bash is a no-brainer. Similar results here. Configuring on Athlon 2200 gives 1. octave 2.1.57: sh = ash real2m48.347s user4m13.299s sys 1m25.203s sh = bash real2m38.129s user4m11.777s sys 1m23.915s 2. netcat 0.7.1 sh = ash real0m56.847s user1m29.808s sys 0m30.186s sh = bash real0m57.015s user1m28.878s sys 0m29.338s 3. mc 4.6.1-pre4 sh = ash real2m13.248s user3m31.685s sys 1m9.772s sh = bash real2m10.112s user3m30.198s sys 1m10.563s Are you sure you didn't actually measure bash's performance twice? If you simply run configure with ash, it will effectively do an exec /bin/bash $0 $@ at the beginning, unless you force it to stick with ash by setting CONFIG_SHELL=/bin/sh. FWIW, I did find that the configure scripts I tested ran faster under ash than under bash, but only by 4% to 8%. Regards Thorsten Dahlheimer -- 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: Making /bin/sh == bash. Has the time come?
Thorsten Dahlheimer wrote: Are you sure you didn't actually measure bash's performance twice? Yes, you're right. I didn't set CONFIG_SHELL. I feel really stupid about it :-( I only copied bash to /bin/sh. At the moment my CPU load is high, so it's not the best time to run benchmarks, but MC configure results are similar. I'll rerun the full tests later. Thanks for pointing that out. Regards Krzysztof Duleba -- 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: Making /bin/sh == bash. Has the time come?
Are you sure you didn't actually measure bash's performance twice? If you simply run configure with ash, it will effectively do an exec /bin/bash $0 $@ at the beginning, unless you force it to stick with ash by setting CONFIG_SHELL=/bin/sh. FWIW, I did find that the configure scripts I tested ran faster under ash than under bash, but only by 4% to 8%. Regards Thorsten Dahlheimer Wait... So everybody's *always* been using bash during configures? -- Gary R. Van Sickle -- 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: Making /bin/sh == bash. Has the time come?
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 real3m21.888s user5m2.357s sys 1m38.022s export CONFIG_SHELL=/bin/sh; time ./transfigure real3m3.738s user5m1.330s sys 1m28.028s time ./transfigure (I.e., default CONFIG_SHELL, which is empty) real3m35.674s user5m5.728s sys 1m51.104s /bin/sh = bash = export CONFIG_SHELL=/bin/bash; time ./transfigure real3m35.286s user5m6.974s sys 1m50.462s export CONFIG_SHELL=/bin/sh; time ./transfigure real3m35.206s user5m5.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/shing. 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary R. Van Sickle Sent: Friday, June 10, 2005 6:14 PM To: cygwin@cygwin.com Subject: RE: Making /bin/sh == bash. Has the time come? Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Friday, June 10, 2005 10:07 AM To: cygwin@cygwin.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
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: 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. I assume that should read modify ash to use fork() again. Can I just ask a basic question here? So if both ash and bash are using the same method of execution (fork), is the reason for bash's slowness due to it just being a larger program with more pages to copy during a fork()? And a related question: Would it make more sense to compile ash with all its builtins enabled, rather than switching to bash? It seems from the benchmarks that bash loses in speed due to its large size, but wins a lot back by having builtins that it can use for many features. If ash+builtins is still smaller than bash, wouldn't it solve both problems? (Of course if configure scripts choose bash automatically if present, then that sort of throws a wrench in that logic.) Final question: It seems to me that most of what a shell does for most common things is essentially fork(); ... exec(); ... wait();. I'm sure there's an obvious reason why the following is not feasible, but would it be possible to special case this in the shell to use something that maps closer to the win32 api like spawn() so as to avoid having to fork()? Brian -- 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: Making /bin/sh == bash. Has the time come?
On Sun, Jun 12, 2005 at 09:15:58PM -0500, Gary R. Van Sickle wrote: - 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/shing. 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. Now I'm confused, too. I thought the complaints were coming from people who used configure. Maybe they were coming from old configure scripts or possibly from makefiles. - 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. I agree. I hope that Eric Blake will also agree and eventually release a new version of bash where /bin/sh.exe is a hardlink (?) or copy (sigh). The only thing I'm not entirely sure about is whether we should just nuke ash from the distribution or not. It seems like if we didn't we would need a new release of ash with /bin/sh.exe replaced with /bin/ash.exe. 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/
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: Now I'm confused, too. I thought the complaints were coming from people who used configure. Maybe they were coming from old configure scripts or possibly from makefiles. I always got the impression that most of those type of complaints were people that had written a (non-configure) script themselves, under linux, with /bin/sh as the shebang, and then tried to run it under Cygwin. Brian -- 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: Making /bin/sh == bash. Has the time come?
Can I just ask a basic question here? So if both ash and bash are using the same method of execution (fork), is the reason for bash's slowness due to it just being a larger program with more pages to copy during a fork()? Fork() also has to dup any and all handles/descriptors/etc, which takes all kinds of time. And a related question: Would it make more sense to compile ash with all its builtins enabled, rather than switching to bash? It seems from the benchmarks that bash loses in speed due to its large size, but wins a lot back by having builtins that it can use for many features. If ash+builtins is still smaller than bash, wouldn't it solve both problems? (Of course if configure scripts choose bash automatically if present, then that sort of throws a wrench in that logic.) Final question: It seems to me that most of what a shell does for most common things is essentially fork(); ... exec(); ... wait();. I'm sure there's an obvious reason why the following is not feasible, but would it be possible to special case this in the shell to use something that maps closer to the win32 api like spawn() so as to avoid having to fork()? Something like this is on my Master Plan Of Things I'll Probably Never Get Around To. I can't for the life of me figure out why anybody ever thought that the entire fork() concept was a good idea, indeed how they ever even thought it up (Oh my, wouldn't it be nice if I could magically duplicate the entire state of my app in a new process, even though there has never been a reason to do so?), so my life's goal is to eliminate fork() entirely from computer science. First step would be a shell that never forks. -- Gary R. Van Sickle -- 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: Making /bin/sh == bash. Has the time come?
On Sun, Jun 12, 2005 at 07:37:56PM -0700, Brian Dessent wrote: Christopher Faylor wrote: 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. I assume that should read modify ash to use fork() again. Yes. Can I just ask a basic question here? So if both ash and bash are using the same method of execution (fork), is the reason for bash's slowness due to it just being a larger program with more pages to copy during a fork()? I think it's more than that. I think bash does a lot more stuff. It deals with job control and has more sophisticated handling of functions and variables. So, I think that every invocation of a new process ends up executing more code in bash itself. And a related question: Would it make more sense to compile ash with all its builtins enabled, rather than switching to bash? That still leaves us with an ash != bash situation although it does reduce the support burden for ash if we get rid of the localized streamlining hacks. I'm still inclined to say that we should go with bash, just for compatibility, since the speed differences don't seem to be that great. It seems from the benchmarks that bash loses in speed due to its large size, but wins a lot back by having builtins that it can use for many features. If ash+builtins is still smaller than bash, wouldn't it solve both problems? (Of course if configure scripts choose bash automatically if present, then that sort of throws a wrench in that logic.) If ash had all of bash's builtins and handled everything just like bash and it was smaller, then yes, it would be a big win. However, if all of that was true, then it seems like there is something seriously wrong with bash. Final question: It seems to me that most of what a shell does for most common things is essentially fork(); ... exec(); ... wait();. I'm sure there's an obvious reason why the following is not feasible, but would it be possible to special case this in the shell to use something that maps closer to the win32 api like spawn() so as to avoid having to fork()? The vfork implementation was essentially just a wrapper around spawn(). As soon as you start to contemplate using spawn instead of fork/exec you will probably run into all of the same issues that eventually drove me away from vfork. The biggest problem was keeping track of file descriptors. Getting tty file descriptors right was a pain and getting close-on-exec file descriptors right was another pain. Getting pids and process groups handled corectly was more pain. As I have had time to ruminate about this, I think I've come to the conclusion that I just didn't design things very well, so maybe the time is ripe for another vfork implementation. Even more interesting might be an implementation that intelligently tried to use vfork when fork was called -- that would give every program the benefit of vfork without recompiling. OTOH, there is a native Windows version of bash out there somewhere, isn't there? Maybe getting things working without fork would not be that hard given that as a template. 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/
Re: Making /bin/sh == bash. Has the time come?
On Sun, Jun 12, 2005 at 09:48:25PM -0500, Gary R. Van Sickle wrote: Can I just ask a basic question here? So if both ash and bash are using the same method of execution (fork), is the reason for bash's slowness due to it just being a larger program with more pages to copy during a fork()? Fork() also has to dup any and all handles/descriptors/etc, which takes all kinds of time. Actually most handles are just inherited. Only some of them have to be duped or recreated -- ttys and sockets are the most notable exceptions. Some close-on-exec'ed fds have to be closed, too. With the advent of the cygheap, most of the inherited information is just one large ReadProcessMemory with a fixups for problematic stuff like sockets. There are all sorts of other things that fork does, though, like making half-hearted attempts to load dlls in the same location in the child as they were in the parent, fixing up mmaps, maintaining a list of handles to slow pid reuse for bash (is that still needed?), etc. 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/
Re: Making /bin/sh == bash. Has the time come?
Thorsten Dahlheimer wrote:
Are you sure you didn't actually measure bash's performance twice?
I've just rerun the tests. This time I made sure in Task Manager that the
right shell is used.
Regards
Krzysztof Duleba
$ cat bench.sh
#!/bin/bash
benchmark() {
package=$1
shell=$2
unset CONFIG_SHELL
if [ $shell != bash ]; then export CONFIG_SHELL=/bin/$shell;
fi
echo Configuring $package with $shell
time $package/configure --prefix=/usr $package/confout.$shell
echo
}
benchmark netcat-0.7.1 sh
benchmark netcat-0.7.1 bash
benchmark mc-4.6.1-pre4 sh
benchmark mc-4.6.1-pre4 bash
benchmark octave-2.1.57 sh
benchmark octave-2.1.57 bash
$ ./bench.sh
Configuring netcat-0.7.1 with sh
real0m48.519s
user1m24.139s
sys 0m23.826s
Configuring netcat-0.7.1 with bash
real0m52.584s
user1m29.344s
sys 0m29.698s
Configuring mc-4.6.1-pre4 with sh
real1m55.170s
user3m25.148s
sys 0m58.383s
Configuring mc-4.6.1-pre4 with bash
real2m2.551s
user3m29.032s
sys 1m7.058s
Configuring octave-2.1.57 with sh
real2m22.899s
user3m59.346s
sys 1m8.478s
Configuring octave-2.1.57 with bash
real2m30.363s
user4m9.959s
sys 1m23.563s
--
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: Making /bin/sh == bash. Has the time come?
On Mon, Jun 13, 2005 at 05:45:47AM +0200, Krzysztof Duleba wrote:
I've just rerun the tests. This time I made sure in Task Manager that
the right shell is used.
$ cat bench.sh
#!/bin/bash
benchmark() {
package=$1
shell=$2
unset CONFIG_SHELL
if [ $shell != bash ]; then export CONFIG_SHELL=/bin/$shell;
fi
echo Configuring $package with $shell
time $package/configure --prefix=/usr $package/confout.$shell
echo
}
benchmark netcat-0.7.1 sh
benchmark netcat-0.7.1 bash
benchmark mc-4.6.1-pre4 sh
benchmark mc-4.6.1-pre4 bash
benchmark octave-2.1.57 sh
benchmark octave-2.1.57 bash
$ ./bench.sh
Configuring netcat-0.7.1 with sh
real0m48.519s
user1m24.139s
sys 0m23.826s
Configuring netcat-0.7.1 with bash
real0m52.584s
user1m29.344s
sys 0m29.698s
Configuring mc-4.6.1-pre4 with sh
real1m55.170s
user3m25.148s
sys 0m58.383s
Configuring mc-4.6.1-pre4 with bash
real2m2.551s
user3m29.032s
sys 1m7.058s
Configuring octave-2.1.57 with sh
real2m22.899s
user3m59.346s
sys 1m8.478s
Configuring octave-2.1.57 with bash
real2m30.363s
user4m9.959s
sys 1m23.563s
Thanks for running these. Would you mind running the same tests after
doing this:
mount -f -X -b c:/cygwin/bin /bin
mount -f -X -b c:/cygwin/bin /usr/bin
replacing the 'c:' above, as appropriate.
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/
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: Thanks for running these. Would you mind running the same tests after doing this: mount -f -X -b c:/cygwin/bin /bin mount -f -X -b c:/cygwin/bin /usr/bin replacing the 'c:' above, as appropriate. I've already had /usr/bin mounted and cygwin\bin in system path (so there seems to be no need for mounting /bin), but sure thing: $ ./bench.sh Configuring netcat-0.7.1 with sh real0m47.611s user1m24.266s sys 0m23.371s Configuring netcat-0.7.1 with bash real0m51.942s user1m29.815s sys 0m29.348s Configuring mc-4.6.1-pre4 with sh real1m52.675s user3m26.551s sys 0m57.965s Configuring mc-4.6.1-pre4 with bash real2m1.234s user3m30.280s sys 1m7.476s Configuring octave-2.1.57 with sh real2m20.639s user4m0.171s sys 1m10.804s Configuring octave-2.1.57 with bash real2m32.874s user4m12.131s sys 1m23.832s Regards Krzysztof Duleba -- 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: Making /bin/sh == bash. Has the time come?
On Mon, Jun 13, 2005 at 06:54:15AM +0200, Krzysztof Duleba wrote: Christopher Faylor wrote: Thanks for running these. Would you mind running the same tests after doing this: mount -f -X -b c:/cygwin/bin /bin mount -f -X -b c:/cygwin/bin /usr/bin replacing the 'c:' above, as appropriate. I've already had /usr/bin mounted and cygwin\bin in system path (so there seems to be no need for mounting /bin), but sure thing: The key here was the '-X' option. It looks like there was a negligible performance increase from mounting with -X. Thanks for trying this. 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/
Re: Making /bin/sh == bash. Has the time come?
On Mon, Jun 13, 2005 at 01:10:39AM -0400, Christopher Faylor wrote: On Mon, Jun 13, 2005 at 06:54:15AM +0200, Krzysztof Duleba wrote: Christopher Faylor wrote: Thanks for running these. Would you mind running the same tests after doing this: mount -f -X -b c:/cygwin/bin /bin mount -f -X -b c:/cygwin/bin /usr/bin replacing the 'c:' above, as appropriate. I've already had /usr/bin mounted and cygwin\bin in system path (so there seems to be no need for mounting /bin), but sure thing: The key here was the '-X' option. It looks like there was a negligible performance increase from mounting with -X. Sorry. It's too late. I meant a negligible performance improvement. 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/
Re: Making /bin/sh == bash. Has the time come?
On Jun 10 20:38, Christopher Faylor wrote: On Fri, Jun 10, 2005 at 06:13:31PM -0500, Gary R. Van Sickle wrote: Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. Wow. I never expected that bash would actually be faster. I would appreciate getting a few more benchmarks for other packages. If this holds out then moving to bash is a no-brainer. Looks like we're just waiting for Eric Blake to return from vacation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: On Fri, Jun 10, 2005 at 06:13:31PM -0500, Gary R. Van Sickle wrote: Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. Wow. I never expected that bash would actually be faster. I would appreciate getting a few more benchmarks for other packages. If this holds out then moving to bash is a no-brainer. Similar results here. Configuring on Athlon 2200 gives 1. octave 2.1.57: sh = ash real2m48.347s user4m13.299s sys 1m25.203s sh = bash real2m38.129s user4m11.777s sys 1m23.915s 2. netcat 0.7.1 sh = ash real0m56.847s user1m29.808s sys 0m30.186s sh = bash real0m57.015s user1m28.878s sys 0m29.338s 3. mc 4.6.1-pre4 sh = ash real2m13.248s user3m31.685s sys 1m9.772s sh = bash real2m10.112s user3m30.198s sys 1m10.563s Regards Krzysztof Duleba -- 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/
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/
RE: Making /bin/sh == bash. Has the time come?
Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Friday, June 10, 2005 10:07 AM To: cygwin@cygwin.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/
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: So, in conversation with Corinna, I think that we're starting to lean towards making /bin/sh == bash sometime soon. Excellent idea. And it even seems to handle the automatic switch to POSIX mode correctly when called sh.exe. Talking of which, how good is pdksh these days? Using your exec-expr-in-a-loop microbenchmark (without the builtin), it seems to be nearly as fast as ash (within a few percent), and almost 1.5x as fast as bash (I got 20, 23 and 38 seconds for ash, pdksh and bash respectively). And for the builtin (using $((i+1))) loop, it's still nearly 4x as fast as bash (0.06 vs 0.23 seconds, or 0.25 vs 1.1 seconds for 1 iterations). Is it stable enough (and well-enough maintained) to be considered for being the shell? We won't get rid of ash and will point to it when people send the inevitable Cygwin is slow! message here. Actually, has anyone done recent benchmarks comparing bash or pdksh vs ash on a reasonable-sized Configure script, or something like that (instead of toy benchmarks)? My gut feeling is that we may not even need all the alternatives stuff, and can just tell folks who are *really anal* about this (or running especially feeble machine) to just run SHELL=/bin/ash ash ./configure. -- 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: Making /bin/sh == bash. Has the time come?
PS: I was as surprised as the Gentle Reader was at the closeness of these results, so I repeated this test several times. I made absolutely sure I was running the sh I thought I was running, and the results are 100% repeatable; there is simply no real difference in speed between shells. So the conclusion we must jump to is that, at least on a machine as awesome as mine, the shell used as /bin/sh is not a bottleneck. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary R. Van Sickle Sent: Friday, June 10, 2005 6:14 PM To: cygwin@cygwin.com Subject: RE: Making /bin/sh == bash. Has the time come? Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Friday, June 10, 2005 10:07 AM To: cygwin@cygwin.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/
Re: Making /bin/sh == bash. Has the time come?
On Fri, Jun 10, 2005 at 04:35:05PM -0700, Shankar Unni wrote: Christopher Faylor wrote: So, in conversation with Corinna, I think that we're starting to lean towards making /bin/sh == bash sometime soon. Excellent idea. And it even seems to handle the automatic switch to POSIX mode correctly when called sh.exe. Talking of which, how good is pdksh these days? Using your exec-expr-in-a-loop microbenchmark (without the builtin), it seems to be nearly as fast as ash (within a few percent), and almost 1.5x as fast as bash (I got 20, 23 and 38 seconds for ash, pdksh and bash respectively). And for the builtin (using $((i+1))) loop, it's still nearly 4x as fast as bash (0.06 vs 0.23 seconds, or 0.25 vs 1.1 seconds for 1 iterations). Is it stable enough (and well-enough maintained) to be considered for being the shell? No, I don't think we want to go there. Most people these days expect that /bin/sh is the same thing as bash. That's the way it is on linux and that is what we're trying to emulate. Not doing that will just trade the explanation of Why doesn't this work? from It's because /bin/sh is ash to It's because /bin/sh is pdksh. 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/
Re: Making /bin/sh == bash. Has the time come?
On Fri, Jun 10, 2005 at 06:13:31PM -0500, Gary R. Van Sickle wrote: Configuring wxWindows from cvs, on a 3.4GHz P4: Sh = Ash: real3m55.351s user5m8.610s sys 1m53.240s Sh = Bash: real3m41.850s user5m6.220s sys 1m53.426s Looks like the time has come. Wow. I never expected that bash would actually be faster. I would appreciate getting a few more benchmarks for other packages. If this holds out then moving to bash is a no-brainer. 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/
Re: Making /bin/sh == bash. Has the time come?
Christopher Faylor wrote: Wow. I never expected that bash would actually be faster. I would appreciate getting a few more benchmarks for other packages. If this holds out then moving to bash is a no-brainer. FWIW, there has been a concerted effort in libtool-2.0 to replace fork/exec'ed subprocesses with builtins whenever available (e.g. fork/exec on ash, but if SHELL=bash/ksh/..., use some builtin construct). This is bound to help with respect to configury-type benchmarks as projects upgrade their libtools. Thus, things are only going to get better, in the ash-vs-bash race. With respect to alternatives, I was thinking about packaging that up for cygwin anyway, because the new family of automake packages could use it, instead of the hacked-together pseudo-alternative scheme it's using now. I haven't had a chance to look into it yet, tho. -- Chuck -- 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/
