-ffast-math可以安全地用于典型项目吗? [英] Can -ffast-math be safely used on a typical project?

问题描述

在回答我建议-ffast-math的问题时，有评论指出这很危险.

While answering a question where I suggested -ffast-math, a comment pointed out that it is dangerous.

我个人的感觉是，经过科学的计算，还可以.我还假设严重的金融应用程序使用定点而不是浮点.

My personal feeling is that outside scientific calculations, it is OK. I also asume that serious financial applications use fixed point instead of floating point.

当然，如果要在项目中使用它，最终的答案是在项目上对其进行测试，并查看对其有多大影响.但是我认为，经过尝试并具有此类优化经验的人可以给出一个普遍的答案:

Of course if you want to use it in your project the ultimate answer is to test it on your project and see how much it affects it. But I think a general answer can be given by people who tried and have experience with such optimizations:

ffast-math可以在 normal 项目中安全使用吗?

Can ffast-math be used safely on a normal project?

鉴于IEEE 754浮点具有舍入错误，因此假设您已经在使用不精确的计算.

Given that IEEE 754 floating point has rounding errors, the assumption is that you are already living with inexact calculations.

此答案特别说明了一个事实，即-ffast-math的作用远不止是对命令进行重新排序而导致的略有不同的结果(不检查NaN或零，仅禁用带符号的零而已)，但我看不到这些最终会在 real 代码中产生什么影响.

This answer was particular illuminating on the fact that -ffast-math does much more than reordering operations that would result in a slightly different result (does not check for NaN or zero, disables signed zero just to name a few), but I fail to see what the effects of these would ultimately be in a real code.

我试图想到浮点的典型用法，这就是我想出的:

I tried to think of typical uses of floating points, and this is what I came up with:

• GUI(2D，3D，物理引擎，动画)
• 自动化(例如汽车电子产品)
• 机器人学
• 工业测量(例如电压)

和学校项目，但这些在这里并不重要.

and school projects, but those don't really matter here.

推荐答案

它做的特别危险的事情之一就是暗示-ffinite-math-only，它允许显式的NaN测试假装不存在NaN.对于任何显式处理NaN的代码来说，这都是一个坏消息.它会尝试测试NaN，但测试将贯穿于牙齿，并声称NaN永远不会存在，即使存在.

One of the especially dangerous things it does is imply -ffinite-math-only, which allows explicit NaN tests to pretend that no NaNs ever exist. That's bad news for any code that explicitly handles NaNs. It would try to test for NaN, but the test will lie through its teeth and claim that nothing is ever NaN, even when it is.

这可以产生非常明显的结果，例如让NaN冒泡给用户，而以前他们在某个时候会被滤除.这当然很不好，但是您可能会注意到并修复它.

This can have really obvious results, such as letting NaN bubble up to the user when previously they would have been filtered out at some point. That's bad of course, but probably you'll notice and fix it.

当NaN检查用于错误检查时，会出现一个更加隐蔽的问题，因为实际上不应该使用NaN.但是也许通过某些错误，错误的数据或通过-ffast-math的其他影响，它仍然变为NaN.现在，您无需检查它，因为通过假设NaN永远不会存在，因此isnan是false的同义词.在您已经交付软件很长时间之后，事情就会虚假地出错，并且您会收到不可能的"错误报告-您确实检查了NaN，它在代码中就在那，它不会失败！但这是因为某人某天将-ffast-math添加到了标志中，也许您甚至自己做了，也不完全知道该怎么做，或者忘记了您使用了NaN支票.

A more insidious problem arises when NaN checks were there for error checking, for something that really isn't supposed to ever be NaN. But perhaps through some bug, bad data, or through other effects of -ffast-math, it becomes NaN anyway. And now you're not checking for it, because by assumption nothing is ever NaN, so isnan is a synonym of false. Things will go wrong, spuriously and long after you've already shipped your software, and you will get an "impossible" error report - you did check for NaN, it's right there in the code, it cannot be failing! But it is, because someone someday added -ffast-math to the flags, maybe you even did it yourself, not knowing fully what it would do or having forgotten that you used a NaN check.

那么我们可能会问，这正常吗?那已经很主观了，但是我不会说检查NaN特别异常.完全循环并断言这是不正常的因为 -ffast-math会破坏它，这可能不是一个好主意.

So then we might ask, is that normal? That's getting quite subjective, but I would not say that checking for NaN is especially abnormal. Going fully circular and asserting that it isn't normal because -ffast-math breaks it is probably a bad idea.

它还会执行许多其他令人恐惧的事情，如其他答案中所述.

It does a lot of other scary things as well, as detailed in other answers.

这篇关于-ffast-math可以安全地用于典型项目吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！