d的nan讨论4
我会远离快速数学.但是,如果你想用它,就得靠你自己了,因为D假设IEEE数学.
因此断定可引入新的_未定义行为_.
"快速数学",也因编译器而异,有时会使事情变慢!
甚至需要它来提高性能吗?不确定,因为只是矢量化,无论是自动的还是显式的,都会带来更好的结果.至少,这是我使用LLVM后端的经验.
最好不用-release.
-release唯一应该做的就是删除调试语句.不多也不少.
是的.-release出于多种原因应该*永远认真*使用,但请阅读规范的该部分,规范:
第一个AssignExpression必须求值为真.如果没有,则断定失败且程序进入无效状态.
如果失败了,即使没有真正编译进去,程序*仍然*进入无效状态.
一旦无效状态,继续执行程序是未定义的.
即优化器可自由假设断定都是正确的,因为它向前移动,如果从未经过实际测试,它可能会非常随机.
默认不使用调试语句.
显然,断定失败后扔掉你的计算机.
绝对地.地下室里到处都是敢于失败的垃圾电脑.
DMD有个开关,可以在断定失败时插入暂停指令.
-release适合速度基准测试的人.我根据几十年的经验说话.
如果不在输出中找错误,更不可能在初化为0时就找到它.
我还在此写过在不想使用时退出时,NaN的合法用途.
它类似Unicode中的"替换字符".我们有在看到无效代码点时,触发异常的经验.这是错误的答案.大错特错,它是Phobos版本2的动力之一.
我已经和布鲁斯谈过很多次了.
充分了解向量化后,结论是,显式矢量化通常是错误选择.它占用了开发人员的时间,且好处很少.
LLVM和GCC都可利用的是assert(arg1 !is arg2);,这么简单的断言!然而其中有很重要的别名信息.我喜欢断言.
文档应该直截了当地说"除非你在人为的速度基准上作弊,否则永远不要使用它",-release.
它应该重命名为-optimize-for-benchmark.
并不可怕.只需要了解正在发生的事情.
合同旨在支持正确性,而不是帮助加剧漏洞.
比较常见用例是禁用合约/断言检查.
问题是DMD似乎不能安全切换到禁用检查.
我遇到"非法指令"的经验是,他们只是假设编译器有错误并产生了无效的机器代码.此外,"hlt"语义根本不终止任何事情,它只是等待下一个中断的触发.它在用户空间崩溃的唯一原因是它需要访问0环.
现在,使用UD2了.