我正在检查以确保浮动不为零。浮子不可能变为负面。那么执行此操作float != 0.0f
还是此float > 0.0f
会更快?
感谢。
编辑:是的,我知道这是微优化。但是每次通过我的游戏循环都会调用它,无论如何我想知道。
答案 0 :(得分:8)
性能不太可能存在可察觉的差异。
答案 1 :(得分:5)
仅考虑娱乐目的:
只有2个浮点值比较等于0f
:零和负零,它们仅在1位不同。所以测试31个非符号位是否清晰的电路/软件仿真就可以实现。
比较>0f
稍微复杂一点,因为负数和0导致错误,正数导致为真,但NaN(两个符号)也导致错误,所以它不仅仅是检查标志位。
根据浮点模式的不同,任何一个操作都可能导致浮点寄存器中的超精确结果在比较前四舍五入为32位,因此得分甚至在那里。
如果存在差异,我会期望!=
更快,但我真的不希望会有差异,我不会对于错误而感到惊讶一些特别的实施。
我认为您的证据表明该值不能为负值,不会出现浮点错误。例如,如果错误恰好累积而不是取消,那么沿1/2.0 - 1/3.0 - 1/6.0
或0.4 - 0.2 - 0.2
行的计算可能会产生正值或负值,因此可能不会发生这种情况。关于仅实际使用与0相等的浮点测试,是测试是否为其分配了文字0
。或者某些其他计算的结果保证在0
中有结果float
,但这可能很棘手。
答案 2 :(得分:3)
在不了解您的平台和编译器的情况下,无法给出明确的答案。 C标准没有定义如何实现浮点数。
在某些平台上,是的,在其他平台上,没有。
如果有疑问,请测量。
答案 3 :(得分:2)
据我所知,f != 0.0f
有时会在您认为错误时返回。
要检查浮点数是否为非零,您应该执行Math.abs(f) > EPSILON
,其中EPSILON
是您可以容忍的错误。
在这种比较中,性能不应该是一个大问题。
答案 4 :(得分:0)
这几乎可以肯定是在你有定量数据表明这是一个问题之前你不应该进行的微观优化。如果您可以证明这是一个问题,您应该弄清楚如何让您的编译器显示它正在生成的机器指令,然后获取该信息并转到您正在使用的处理器的数据手册,并查找所需的时钟周期数用于相同逻辑的替代实现。然后你应该再次测量,以确保你看到了好处,如果有的话。
如果您没有任何数据表明这是一个性能问题,请坚持使用最清晰,最简单的逻辑来表达您尝试做的事情。