From roland.mainz at nrubsig.org Thu May 29 06:23:57 2008 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu, 29 May 2008 15:23:57 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008] References: <200805272319.m4RNJieD001649@almas.sfbay.sun.com> <483D7585.5070908@sun.com> <18493.33194.70846.591126@gargle.gargle.HOWL> <483D88D6.7010007@Sun.COM> <18493.35509.225803.983454@gargle.gargle.HOWL> <483e993e.IBWdTmFXN4aNkf+b%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <483EAE6D.6C27C43F@nrubsig.org> Joerg Schilling wrote: > James Carlson wrote: > > Darren J Moffat writes: > > > While it is ksh93 I don't think any of this really matters that much > > > because you have to explicitly ask for ksh93. On the other hand if this > > > same implementation was exporting this same functionality by default > > > when it was used as the implementation of /bin/sh I would feel very > > > differently. This still isn't the case to make ksh93 /usr/bin/ksh which > > > is where I think this type of issue matters most. > > > > True enough, though, because of Indiana, we're already hacking our > > system scripts to comply with ksh93's differing requirements. > > Why? > > Did you thing about the fact that ksh93 is _really_ big and that people who > like to use OpenSolaris in embedded environments probably cannot use ksh93 for > this reason? Erm... the issue is the other way around - the use of builtin commands enables ksh93 to work much faster and with less memory (since you can avoid awk/sed/tr/etc. completely and even avoid temporary files for small things (e.g. stuff data into arrays, variable trees or plain string variables)) than using Bourne shell and lots of external commands (that's why we're (slowly) working on libbusybox.so.1, too). The startup time of ksh93 is highter than the Bourne shell (primarily because we do the i18n setup correctly and simply have more stuff to init at startup) - but that "price" is quickly paid-off by simply avoiding one single |fork()|+|exec()| sequence - beyond that ksh93 outperforms the Bourne shell, bash, zsh, dash etc. in all benchmarks (remeber David Korn had a slide about perforamce in his talk at the OpenSolaris May 2008 summit). --- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From John.Plocher at Sun.COM Fri May 30 06:54:22 2008 From: John.Plocher at Sun.COM (John Plocher) Date: Fri, 30 May 2008 06:54:22 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008] In-Reply-To: <483feb18.dS84cWTXSQCC03xx%Joerg.Schilling@fokus.fraunhofer.de> References: <200805272319.m4RNJieD001649@almas.sfbay.sun.com> <483D7585.5070908@sun.com> <18493.33194.70846.591126@gargle.gargle.HOWL> <483D88D6.7010007@Sun.COM> <18493.35509.225803.983454@gargle.gargle.HOWL> <483e993e.IBWdTmFXN4aNkf+b%Joerg.Schilling@fokus.fraunhofer.de> <483EAE6D.6C27C43F@nrubsig.org> <483feb18.dS84cWTXSQCC03xx%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4840070E.8070705@Sun.Com> Joerg Schilling wrote: >You would need to prove this on an embedded system. I am not convinced at all. Interesing discussion - But not as part of this case. A future appliance/embedded OpenSolaris project is free (nay, almost expected) to make its own choices as to which utilities it will use. Almost certainly, it will not use the same choices as do the laptop or bigiron configurations we are building here. -John From gsf at research.att.com Fri May 30 07:10:32 2008 From: gsf at research.att.com (Glenn Fowler) Date: Fri, 30 May 2008 10:10:32 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008] References: <200805272319.m4RNJieD001649@almas.sfbay.sun.com> <483D7585.5070908@sun.com> <18493.33194.70846.591126@gargle.gargle.HOWL> <483D88D6.7010007@Sun.COM> <18493.35509.225803.983454@gargle.gargle.HOWL> <483e993e.IBWdTmFXN4aNkf+b%Joerg.Schilling@fokus.fraunhofer.de> <483EAE6D.6C27C43F@nrubsig.org> <483feb18.dS84cWTXSQCC03xx%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <200805301410.m4UEAWAp002145@penguin.research.att.com> I'm sure we can have this discussion off-ARC size can be levereged when properly engineered (properly == transparent to the user save space/time measurements) a few years back we did a real world test on a handheld with ksh+libshell.so+libcmd.so+libast.so+libcmd-main-stubs where libcmd-main-stubs were all hard links to one main a.out for all ast libcmd command and the disk footprint was smaller than the equivalent set of /bin utilities, and, once the .so's were pulled in by the first exec, ksh startup time was in the noise, and set up to use the builtin libcmd commands directly enabled the usual fork/exec-less speedups in that off-ARC discussion we can resurrect real numbers based on scripts you deem typical for embedded systems -- Glenn Fowler -- AT&T Research, Florham Park NJ -- On Fri, 30 May 2008 13:55:04 +0200 Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: > Roland Mainz wrote: > > > Did you thing about the fact that ksh93 is _really_ big and that people who > > > like to use OpenSolaris in embedded environments probably cannot use ksh93 for > > > this reason? > > > > Erm... the issue is the other way around - the use of builtin commands > > enables ksh93 to work much faster and with less memory (since you can > > avoid awk/sed/tr/etc. completely and even avoid temporary files for > You would need to prove this on an embedded system. I am not convinced at all. > If you run huge shell scripts like "configure", I would expect the ksh to be > faster but for the scripts that Solaris uses for startup, things look much > different. From Joerg.Schilling at fokus.fraunhofer.de Fri May 30 04:56:03 2008 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 30 May 2008 11:56:03 -0000 Subject: [busybox-dev] [ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008] In-Reply-To: <483EAE6D.6C27C43F@nrubsig.org> References: <200805272319.m4RNJieD001649@almas.sfbay.sun.com> <483D7585.5070908@sun.com> <18493.33194.70846.591126@gargle.gargle.HOWL> <483D88D6.7010007@Sun.COM> <18493.35509.225803.983454@gargle.gargle.HOWL> <483e993e.IBWdTmFXN4aNkf+b%Joerg.Schilling@fokus.fraunhofer.de> <483EAE6D.6C27C43F@nrubsig.org> Message-ID: <483feb18.dS84cWTXSQCC03xx%Joerg.Schilling@fokus.fraunhofer.de> Roland Mainz wrote: > > Did you thing about the fact that ksh93 is _really_ big and that people who > > like to use OpenSolaris in embedded environments probably cannot use ksh93 for > > this reason? > > Erm... the issue is the other way around - the use of builtin commands > enables ksh93 to work much faster and with less memory (since you can > avoid awk/sed/tr/etc. completely and even avoid temporary files for You would need to prove this on an embedded system. I am not convinced at all. If you run huge shell scripts like "configure", I would expect the ksh to be faster but for the scripts that Solaris uses for startup, things look much different. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily