Re: /bin/sh and 32-bit arithmetics [CORRECTED]

On Tue, Apr 22, 2003, Narvi wrote:
> 
> 
> On Sun, 20 Apr 2003, Alex Semenyaka wrote:
> 
> >  7    5.20     6.37     3.51    22.50%     i=$(($i<<1))
> >  8    5.25     6.42     3.51    22.27%     i=$(($i<<$m))
> >
> > As you can see, even for arithmetic-only script the overhead is not too big
> > except with one case: shift operation. I decided to investigate is it usual
> > script operation. I've went through all scripts I could find in my FreeBSD
> > box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot
> > of them:
> >
> > $ locate .sh | grep '\.sh$' | wc -l
> >     1637
> >
> > But there was no any script that uses the shift operation. Good, but not
> > enough. I've take the script that uses arithmetics and do some other job,
> > ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop
> > with both (64-bit and 32-bit) shells. As an argument it received empty
> > directory so no work has been done, just run, check pars, found no files,
> > exit. It takes 65.35 seconds in the first case and 65.30 second in the second
> > one. So the the time that arithmetics takes during the real script execution
> > is too small in comparison to total running time (obviously: arithmetics
> > is in-core calculations while any script usually run some external programs
> > etc, and at least I/O is involved).
> 
> Ahem - wouldn't it be easier to find out *why* the dramatic speed-down
> happens and trying to combat it as opposed to trying to show the
> speed-down is not releavant? There shouldn't be anything inherently that
> much slower in 64 bit shifts...

We're talking about interpreted Bourne shell here.  It's slow by
design, and 64-bit arithmetic is not going to make it
significantly slower for anything other than microbenchmarks.

BTW, I'll review the patches next month when I have some free time
if nobody else jumps on it.