|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 10:57:15 -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 :content-transfer-encoding; bh=ifBGl52Odk0gw5Bk1/HWvVydewRhaREWqj8xPaz5+kE=; b=HKcBWERTdH/uGFFckuf69UI5JO1dRLkQEZffjHFXedyUPESj7ofxwtIOhJZhwpxlJP g2iH6dNWnzOTU/TrkJcPqu0ytXKzZJRssWyUCRoFgdxrUyqI8CeNLyaao/6kZzMlf3c/ QRe2V0iZ6LWzF5WkVBAxknV+j/nygnUhdo9Ec=
- 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=RAxLWwgVOnCIwEWNdR3F4qFUC5pHfQzGzXMnw0ow+T38oOqvDNHmda9hvNhrw1L2qL N6StgkOl8kfmkEtHHCdHZmzssHt9GO7Zpt3E4/oYZR/Pda6fydiOqBVnGAma8YOzwUa0 w4TVs4CASur4rmIGfOg0/9lOHhDRiKC6s2O8o=
My program is just repeatedly computing inf*inf, so denormalized
numbers can't be the explanation...
2009/9/23 Robert Bocquier <robert.bocquier@xxxxxxxxxxx>:
> Benoit Jacob a écrit :
>> 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,
> Hi Benoit,
> may be *before* arriving to those extremes you've encountered
> "denormalized numbers" ?
> There are provisions to get rid of them with SSE, while in regular "387"
> code you must explicitly deal with them. This is consistent with your
> observation (but it's not a proof).
> Robert Bocquier
> 4 chemin de Malacher
> 38240 Meylan - France
> Tel: +33 438 020 555
> Fax: +33 438 020 525