|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: Rohit Garg <rpg.314@xxxxxxxxx>
- Date: Wed, 23 Sep 2009 20:35:19 +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; bh=75WWJXjQOxa41GyoaF4SkkI2eo0uHX6gY15DjXEYWNA=; b=ldl47Uy+JUemMBnhs9+JMJUHZjcDhvYWmCKE40HjaJYIKKXWJu8y+0glLl/hK1lpft 2kbmeEP9ssGKlRUfyKmDfciLcJQYqmAq7/lOlINIJZiQ++k003ikwyTDUGp4r5/oAoqH yoNREpM0DOJUGBoV+FpeJ8Mehk7wPqrbL4BLI=
- 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=YvPytVMgkhBF7kjDJfFKNttT2lPo+yZNoxx9KciqbFd1DviSaJTYxUWZ5HE7G9hvae RfpS+omIOi2h0X3LiLL4sC+DXMRL9tPKwvfj0JgTsaSZc6yStDykZKL2YEDA19RX80sT mZzcwTl17Cm7YhSPIQaNIXCA7tbUZJ5t/7KJw=
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
> 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.
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. Eigen is a purely template library, so those who
compile their own code have no problem. We can ignore those amongst
them who are still running machines w/o SSEx.
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. At any rate, eigen needs
to focus on the future, and it is x86-64.
> 2009/9/23 Rohit Garg <rpg.314@xxxxxxxxx>:
>> fp exceptions are handled in software. Is it 32 bit or 64 bit? If it
>> is 32 bit, have you enabled -mfpmath=sse in your compiler flags?
>> On Wed, Sep 23, 2009 at 6:21 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> Sorry for adding to the currently already high traffic here.
>>> Here, on linux / x86, my programs run 100x slower when the
>>> floating-point values are 'inf' or 'nan'.
>>> Only scalar code is affected, SSE code is not affected.
>>> I haven't enabled floating-point exception signals. I don't have a FP
>>> signal handler. Just any basic c++ program.
>>> Can this be "fixed"? How?
>>> Otherwise, I really need to make sure that solve() methods avoid
>>> producing such special values when no solution exists --- otherwise
>>> they take much longer to return.
>>> Thanks for your help,
>> Rohit Garg
>> Senior Undergraduate
>> Department of Physics
>> Indian Institute of Technology
Department of Physics
Indian Institute of Technology