On 4/20/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Roland Mainz wrote on Sat, Apr 19, 2008 at 11:46:02PM CEST: > > On 4/19/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > [ > <http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00096.html> ] [snip] > > Erm... thanks! ... :-) > > ... is it possible to see the "diff -u" for the change and a shell > > script code sample how the generated shell code may look like ? > > > Yes. The diff -u is in the link that I quoted at the beginning.
Oh.. I missed that... sorry... ;-( ... Thanks! :-) > > The > > part where I am curently worrying is something like (( foo=$foo+5)) > > vs. (( foo=foo+5 )) - the first firm is wrong because it forces the > > shell to convert the value for "foo" into a string and back after > > expansion while the 2nd form avoids this mess (for integer operations > > this is just a performance issue, for floating-point math the first > > form leads to wrong results because the conversion to a string will > > normally cause rounding errors due the base2---->base10--->base2 > > conversion > > Sorry, but: first, there is no floating point in either Libtool, nor > Posix shell semantics. No, but the general issue applies to integer math, too - and that is part of the POSIX shell spec and supported by ksh88, ksh93, bash etc. And the floating-point thing is now on the ToDo list for the next revision of the standard... > Second, if you can prove to me (by posting > timing comparisons) that conversion from integer to string or vice > versa, Here come the requested numbers: -- snip -- $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i < 100000 ; i++ )) ; do (( sum=sum+1 )) ; done ; print $sum' 100000 real 3.89 user 3.81 sys 0.02 $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i < 100000 ; i++ )) ; do (( sum=$sum+1 )) ; done ; print $sum' 100000 real 18.70 user 18.52 sys 0.03 -- snip -- .. or short: (( sum=$sum+1 )) is at least five times slower than (( sum=sum+1 )) > has *any* performance impact whatsoever on Libtool, I'll gladly > send lots of beer your way. Erm... I don't have a good way to benchmark libtool... all machines I have access to are either heavily overtaxed with swapping or shared between multiple users (an option may be to use the "realtime scheduler class" on Solaris for benchmarking but that requires "root" access... ;-/ ). > I mean hey, we still fork quite a bit, and > you can probably solve a cheap differential equation during the time > that one fork takes even on sane systems like Linux. Right... technically |fork()| is one problem... and |exec()| the other - each |exec()| call must make crosscalls to all CPUs (belonging to that OS image) to tear-down the address space being used... and that becomes time-consuming on machines with 256 CPU strands (like the four-socket Niagara 2+ machines (and don't ask how horrible this will be on the machines with 2048 CPU strands (see http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/))) ... ;-( ... but the |fork()|+|exec()| thing in Solaris's libtool 1.5.x is now mainly under control on our side ; ksh93 has many common commands built-in (e.g. basename, dirname, printf, mkdir, rmdir, mkfifo etc.) and using them greatly reduces the number of |fork()|+|+|exec()| done. Another group is doing benchmarking of the patch but AFAIK it looks very good right now... BTW: below is the Solaris patch for libtool 1.5.x I've used to improve the performace: -- snip -- diff -N -r -u original/usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff --- original/usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff 1970-01-01 01:00:00.000000000 +0100 +++ usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff 2008-04-16 23:28:29.042660000 +0200 @@ -0,0 +1,50 @@ +diff -u libtool-1.5.22/libtool.m4 libtool-1.5.22/libtool.m4 +--- libtool-1.5.22/libtool.m4 2005-12-18 22:53:17.000000000 +0100 ++++ libtool-1.5.22/libtool.m4 2008-04-16 23:27:06.989694000 +0200 +@@ -390,7 +390,7 @@ + done + IFS="$lt_save_ifs" + +- if test "X$echo" = Xecho; then ++ if true ; then + # We didn't find a better echo, so look for alternatives. + if test "X`(print -r '\t') 2>/dev/null`" = 'X\t' && + echo_testing_string=`(print -r "$echo_test_string") 2>/dev/null` && +@@ -4229,6 +4229,38 @@ + # configuration script generated by Autoconf, you may include it under + # the same distribution terms that you use for the rest of that program. + ++builtin \ ++ basename \ ++ cat \ ++ chgrp \ ++ chmod \ ++ chown \ ++ cmp \ ++ cp \ ++ cut \ ++ date \ ++ dirname \ ++ expr \ ++ fold \ ++ head \ ++ id \ ++ join \ ++ ln \ ++ logname \ ++ mkdir \ ++ mkfifo \ ++ mv \ ++ paste \ ++ rev \ ++ rm \ ++ rmdir \ ++ tail \ ++ tee \ ++ tty \ ++ uname \ ++ uniq \ ++ wc ++ + # A sed program that does not truncate output. + SED=$lt_SED -- snip -- Chunk one makes sure we use "print -r" for ksh-based shells because otherwise the automake stuff will attempt to use /usr/ucb/echo (which requires a |fork()|+|exec()|) ; the 2nd chunk enables lots of builtins present in ksh93 version 's+' (which saves lots of fork()|+|exec()| calls, too) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
