Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow? |

[ Thread Index | Date 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 11:42:10 -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=VyJ8AZ5gQH4sEOqXoIPwOKmLnULGj9lPx1CF2wLwP1o=; b=bxE4YnoULGHwUVEOsd56fC5pbyyMtYJ8TeeYMpQyM6dB0ExhtqUUgztq8YPO8euA3v q+b9i4ggRFI/lUsz0/SFrFloVJ+yIKNaOjFStTQsvr2CG7rWZs2Htla7yuBonDmJm1al GYftM4AkwZytttMr2VzfhcoMQ/y/onXCyoirI=*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=hgLz3QORfON5obVo5fJgwRlm7iz3OxUulCMjJDEggJGT6+8vK+8RIw1q19ycVbXJX7 cYgGVBW8QD6nIM+ze/wTo3jCTRcvJJczFMCRUGlR0pu0XDbYhfWgKKZ4ZQgR3bHRVcly NTsxkURaCUAHupqETzJP0hdHCBwezyMIouAR0=

2009/9/23 Rohit Garg <rpg.314@xxxxxxxxx>: > On Wed, Sep 23, 2009 at 8:17 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >> Ah, passing: >> -mfpmath=sse -msse2 -DEIGEN_DONT_VECTORIZE >> >> does fix the problem (I pass -DEIGEN_DONT_VECTORIZE because I already >> knew that SIMD instructions like mulps avoids the problem; now I can >> see that indeed scalar instructions like mulss also avoid the >> problem). >> >> So, the problem is a non-issue on SSE2-capable systems (SSE2, because >> SSE doesn't support double). >> >> But what about non-SSE2-capable systems, or simply linux distros who >> need to build a generic i686 binary package.... are they out of luck? >> >> The big design decision that I am facing now is this: floating point >> numbers claim to be able to represent special values such as "inf" and >> "nan"; ideally we would play this game, returning "inf" when that is >> the natural result given the user's input; but if that must be 100x >> slower than normal even before the user has any chance of checking if >> that's happening, then in practice we can't do that and we need to >> explicitly avoid generating "inf" and "nan" values even when that >> would be the natural result given the user's input. > > At any rate, eigen needs > to focus on the future, and it is x86-64. No, that doesn't work, for 2 separate reasons: Reason 1: What about all the embedded CPUs and low-power CPUs out there, I'm sure that many of them have the same issues. -- if, as Jitse's link suggests, the problems are inherent in the design of the x87, then all x87-compatible non-SSE-capable CPUs will have the same problem. That's a lot of embedded CPUs. -- what about the Intel Atom... etc, etc. Reason 2: Linux distros aren't going to drop support for i686 (some even still support i586) anytime soon, we can't change that, and that's all the more going to continue with the current trend of "netbooks". Plus, it's legitimate to want to continue using old machines. > Those who use prepackaged software for 32 bit can still make 2 > codepaths, detecting CPU at runtime. This is how EVERY body else does > it,and it has worked out pretty well so far. .....and the x87 code path would be generated how? If we designed Eigen without x87 in mind, making x87 as much as 850x slower than it should be (Jitse's link), then that code path would have to be generated using another library? That doesn't work ! > No, we should return inf and nan wherever needed. Reason being inf and > nan usually signal errors in data/algorithm. Not returning them at all > will be a BAD idea. Yes, if it's just a matter of returning them, why not. But my dilemmas start when there are situations when INF may happen in the middle of the computation and one would still have to do the rest of the computation with INF values. That is not reasonable if INF goes 850x slower. Benoit

**Follow-Ups**:

**References**:**[eigen] (General question) Floating point: why are 'inf' and 'nan' slow?***From:*Benoit Jacob

**Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?***From:*Rohit Garg

**Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?***From:*Benoit Jacob

**Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?***From:*Rohit Garg

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] backporting the vectorized quaternion product to 2.0 ?** - Next by Date:
**Re: [eigen] backporting the vectorized quaternion product to 2.0 ?** - Previous by thread:
**Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?** - Next by thread:
**Re: [eigen] (General question) Floating point: why are 'inf' and 'nan' slow?**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |