Re: func_arith and func_len

[Roland Mainz]

On 4/20/08, Ralf Wildenhues <address@hidden> wrote:
>  * Roland Mainz wrote on Sat, Apr 19, 2008 at 11:46:02PM CEST:
> > On 4/19/08, Ralf Wildenhues <address@hidden> 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) address@hidden
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)