|Re: [eigen] sse asin implementation|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] sse asin implementation
- From: Rohit Garg <rpg.314@xxxxxxxxx>
- Date: Tue, 31 Mar 2009 22:27:30 +0530
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wjZLYtPPF7MWLEkcTHJg5VGoQsrL/R99e59wtTwuF18=; b=mJZ5UEHjOWvthETT+/GVLsatCpbhVUBFcgTGkpa8zxcYROiXoknA56ZaAj8+dUUcaz rmsHVjLRpdB9ahVFPv8xxWWyBQVwcMj5tywf9A8ERq44+Ho/jaXE7J0jPrTyo8C2TD10 XYEraNO/HOMsNB2XEV6NnC8r782LDODFHm9k0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IataUyuVya0Y0PM3XQEGV0+cuuUU+vVv1upyQe3DLjZ5kcPzT4ug5PD1IFTULrgprP u5GFocSTw5QD0cDDNVYP0i6WfOzvpoVtKEpKduq7sVoI0VHza3H8WkJ1BFzwY7VrvCSF ckseJGkRu22nm4fYU5TspXrUC1dDySVDqsM1s=
On Tue, Mar 31, 2009 at 10:19 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/3/31 Rohit Garg <rpg.314@xxxxxxxxx>:
>> For general exponentiation, I think a cheap and easy route would be
>> just exp(b*log(a))
>> I looked at the cephes library implementation of pow and they do a lot
>> of hacks just to get 3 bits of precision. In the use case that you
>> have cited, I think it's better to just have the above implementation.
>> It is certainly good enough for the -ffast-math case.
> OK, seems sensible. But I thought the main justification for a simd
> pow() would be performance, that it could be faster than the above
> formula. If that's not the case then sure, I agree with you.
ATM, I don't know of any way to do that without going the log ->exp
route. cephes does something without taking a full blown log and an
exp but the general approach is same. But yes, we'll have to flush the
denormals if we want any real performance benefit. Perhaps this is a
candidate to be vectorized only if the fast-math is chosen. And
looking at the log code already in eigen, ATM the user has no way to
select the default route if he wants the denormals to be treated with
respect. Silently killing them is suitable only if the -ffast-math is
>> BTW, what do you think of enabling the fast math paths in eigen when
>> just -ffast-math is supplied to gcc. It can be detected by the
>> __FAST_MATH__ macro.
> That seems like a good idea! Let's see what Gael thinks.
Department of Physics
Indian Institute of Technology