Re: [Xenomai] Building with hard float: cannot open shared object file libpthread_rt.so.1

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Thu, Mar 19, 2015 at 11:00:12AM -0700, Steve B wrote:
> On Thu, Mar 19, 2015 at 9:54 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
> > On Thu, Mar 19, 2015 at 09:49:45AM -0700, Steve B wrote:
> > > On Thu, Mar 19, 2015 at 9:43 AM, Lennart Sorensen <
> > > lsorense@csclub.uwaterloo.ca> wrote:
> > >
> > > > On Thu, Mar 19, 2015 at 05:04:03PM +0100, Gilles Chanteperdrix wrote:
> > > > > My point was, there may be some pathological values that may involve
> > > > > using expm1 or logp1 instead of log or exp, and so to avoid pow
> > > > > entirely. Also, I am not sure pow optimizes the case where b is an
> > > > > integer. It would be interesting to know the actual values of a and
> > > > > b which cause pow to explode.
> > > >
> > > > Could be.
> > > >
> > > > For fun I checked how many instructions it took to execute
> > > > pow(1.234000,12.200000) to get 13.003041 and according to my gdb run,
> > > > it took 1151 instructions.  Now I did not enable optimization for that
> > > > build, which might matter.  Those were of course not all floating
> > pointer
> > > > instructions, but quite a few of them are.
> > > >
> > > > With -O3, it dropped to 303 instructions.
> > > >
> > > > I should try the same test on armel to see what difference it shows
> > just
> > > > because I am curious.  I would have to setup an armel chroot to run
> > > > in first.
> > > >
> > > > --
> > > > Len Sorensen
> > > >
> > >
> > > Hi guys,
> > > Here are some input values that have caused problems for me:
> > >
> > > b=0.975800; c= 7.000000;
> > > b = -1789009.391544; c = 6.000000;
> > > b= 42442350436303.453125; c = 4.500000;
> > >
> > > (where I am doing a = pow(b,c);)
> > > Interestingly the first two took a long time in my actual application but
> > > not in my test program where I was just plugging them straight into the
> > > pow() function. I guess there may be some difference in compile options
> > > that I need to take a look at to see what is going on.
> > > And the third one (yeah, that's a huge number!) takes a very long time no
> > > matter what, and seems to take much longer with the hf compiler.
> > >
> > > Let me know if this looks interesting..
> > > My original plan was to try to get my algorithm designer to get rid of
> > the
> > > pow() calls wherever he can, and hopefully that will get us straightened
> > > out...
> >
> > For the first example, b being close to 1, and pow(b,c) being
> > exp(c * log(b))
> >
> > you may want to try exp(c * log1p(b - 1))
> >
> > Also, since the exponents are integers
> > you may want to try the russian peon algorithm
> > 4.5 is 9 / 2 so pow(b, 4.5) is sqrt(pow(b, 9))
> >
> >
> > >
> > > Steve
> >
> > --
> >                                             Gilles.
> >
> 
> Yes, that's a good idea, or maybe sqrt(b)*b*b*b*b would even work better,
> since it's just a few multiplies and a square root.

For b^4, you want to do
x = b * b
y = x * x

That is only two multiplications (instead of 4). I believe the
russian peasant would do it that way. It gives a reduced number of
multiplications (it is not optimal though), and that works for any
integer power.

Anyway, I do not believe the pow function is supposed to be
efficient for integer powers, I do not know if there is another
glibc function, but if there is not, the russian peasant is simple
and efficient.

-- 
					    Gilles.