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 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.