|Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 23 Sep 2009 13:56:31 -0400
- 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; bh=Reli+FFDgy/SsIEPLvHoW2IVR7C4wuDoH2uB+PyI2KA=; b=TFdy/jzibxGQ29D2bPw5EarVQEU4C9aYAqjPvA8SrALPyg0oXd5w6IDrVhWPixNNTB pJ6Mfh59VIqT8oxBaQYR9EMEm6Q6r5ihdfc7iNb0CWiXWeMW2HpTVv1rx4VbjVTMX2Zb fZ0SKJSTRhPe7h+XuWQwwaGxlvxzwAWx8Nvq8=
- 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; b=wqNt9FFqWjV50igFKa3rxRa0Oo+xSSY1BUBNk4MyeWot+nHRFm5sPpS49IMMrkEeHL tch5TMd9/5NVBvHY4dkJqzr3iq5VsUSIe7YeZ8ONWjsmEivY7Ewum/bxyXiEE7Qz96g8 q99F85pqr3Vamp3cM7VQMEU7Y3fW7k7bm9VNU=
2009/9/23 Rohit Garg <rpg.314@xxxxxxxxx>:
> On Wed, Sep 23, 2009 at 10:27 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> The list of x86 CPUs that don't have SSE2 (SSE is not enough for
>> double) includes Pentium 3, Athlon XP, VIA C7, AMD Geode, etc. There's
>> no way that we could neglect all of them performance-wise. Moreover,
>> even with SSE2, people may still want to use -mfpmath=387 (and it's
>> the default) in which case the non-vectorized part of Eigen
>> computations is affected.
>> It's not a corner case at all, I was wondering if when redesigning the
>> solvers I could assume it to be safe to produce INF and NAN during the
>> computation, not just as return values at the end, and the answer is
>> that I can't do that.
> How do you propose to handle this then? Will you check for values
> before writing them to memory? And what happens on the SSE2 machines?
> There too, denormals are handled in sw.
I don't need to handle all cases, it's OK if in corner cases I have INF values.
All I need to take care of is the "mainstream" cases. This is far
easier :) Current Eigen already does that, as does LAPACK.