Garrett D'Amore wrote: > > I recently heard that there are plans to use isaexec to wrap ksh93. I > think this is an incredibly bad idea. Especially given the > microoptimizations that have been done lately to make ksh93 faster (e.g. > the MMU page size adjustment.)
Please read http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-October/001631.html for the explanation about why I bumped the default page size of the stack to 64k. In this specific case it makes sense since larger data have been moved from BSS to the application stack. > The reason for this is that I understand that someday ksh93 will replace > the default shell. I agree that having a POSIX shell be the default > will be a good thing for the system, and I look forward to the day with > ksh93 can fulfill this role. > > What concerns me, is that the extra time (2 milliseconds was a rough > measurement done in one case) it takes to spawn a shell is going to have > a negative impact on overall system performance if this becomes the > default shell. See below... > The shell is forked/execed a _lot_. Consider builds of Solaris, where > "make" spends almost all of its time execing the shell. See below. In many cases Makefiles execute commands which are available as ksh93 builtin commands. In that case a full |fork();exec()| sequence gets saved which renders the "overhead" by /usr/lib/isaexec void (you can observe this in the OS/Net build when you replace the default shell with ksh93). > Consider large interactive servers like Sun Ray servers, or login > servers like shared compute farms. > > Consider system startup. > > All of these things hit the shell rather quite a bit. And as a result, > will be penalized by the cumulative effect of any startup penalty. This has been considered many times and we did some benchmarking in this case. The effect of isaexec is completely canceled out by ksh93's ability of builtin commands and other optimisations (for example that $( ... ) and ( ... ) no longer fork child processes of the shell (unless a subprocess is needed (in a pipe chain or requested via "( ... ) &" ))). Even the fork() of ONE single external command is so heavywheight that more than 50 calls through /usr/lib/isaexec easily fit "in" there. /usrlib/isaexec comes with a "price" but IMO this is completly outwheighted and overlaid by ksh93's new features (as described above) and improved performance compared to ksh88. [snip] > I do think it may be reasonable to ship a 64-bit ksh93, e.g. in > /usr/bin/sparcv9/ksh93 or somesuch, which can then either be hardlinked > into /usr/bin or hardcoded into those scripts that need such large data, > at the sites where it is necessary. So I'm not saying we shouldn't ship > a 64-bit ksh93, I'm just saying that we shouldn't wrap ksh93 with isaexec. I *STRONGLY* disagree. Solaris is a 64bit operating system and I strongly belive that there should be no "artificial" restriction in the size the data the shell can process. The 32bit vs. 64bit executable discussion would be appropriate ten or fifteen years ago but today it matters more whether a 64bit system can really process 64bit data. We've seen clones of ksh93 process far more than 4GB of data in associative arrays and IMO the default shell should have no "artificial" size limit in processing any data. And the performance concerns are for /dev/null as desccribed above... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
