blocks|key|3410334|text|这不是编译器或编译器编写者不聪明的问题。它更像是遵循标准并产生所有必要的“副作用”，如Infs、Nans和非规范化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3410335|此外，它还可以是关于不产生其他不必要的副作用，例如读取内存。但我确实认识到，在某些情况下，它可能会更快。|3410336|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's not about compilers or compiler writers not being smart. It's more like obeying standards and producing all the necessary "side effects" such as Infs, Nans, and denormals.

Also it can be about not producing other side effects that are not called for, such as reading memory. But I do recognize that it can be faster in some circumstances.

blocks|key|2926572|text|例如，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2926573|+2*+f可以简单地将f的指数递增1，从而节省一些周期。|blockquote|2926574|2926575|2926576|这根本不是真的。|2926577|首先，您有太多的角例，如0、无穷大、Nan和非正规化。然后你就有了性能问题。|2926578|误解是递增指数的速度并不比乘法快。|2926579|如果您查看硬件指令，就会发现没有直接递增指数的方法。所以你需要做的是：|2926580|将exponent.|2926581|Bitwise按位转换为integer.|unordered-list-item|2926582|
|2926583|Increment+exponent.|2926584|2926585|Bitwise转换回floating-point.|2926586|2926587|在整数和浮点执行单元之间移动数据通常有中等到较大的等待时间。因此，最终，这种“优化”变得比简单的浮点乘法更糟糕。|2926588|所以编译器不做这种“优化”的原因是因为它并不快。|2926589|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|18|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1B|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1C|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1D|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1E|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1G|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1H|8|@]|9|@]|A|$]]|$1|V|3|W|5|S|7|1I|8|@]|9|@]|A|$]]|$1|X|3|U|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|S|7|1K|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1M|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1N|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|16|$]]

<blockquote>
 For example, 2 * f, might simply increment the exponent of f by 1,
 saving some cycles.
</blockquote>

This simply isn't true.

First you have too many corner cases such as zero, infinity, Nan, and denormals. Then you have the performance issue.

The misunderstanding is that incrementing the exponent is not faster than doing a multiplication.

If you look at the hardware instructions, there is no direct way to increment the exponent.
So what you need to do instead is:

<ol>
<li>Bitwise convert into integer.</li>
<li>Increment the exponent.</li>
<li>Bitwise convert back to floating-point.</li>
</ol>

There is generally a medium to large latency for moving data between the integer and floating-point execution units. So in the end, this "optimization" becomes much worse than a simple floating-point multiply.

So the reason why the compiler doesn't do this "optimization" is because it isn't any faster.

blocks|key|5141180|text|在现代CPUs上，乘法通常具有每周期一次的吞吐量和低延迟。如果这个值已经在一个浮点寄存器中，你就不可能通过改变它来在表示上做整数运算来超越它。如果它一开始在内存中，并且假设当前值和正确结果都不是零、非正规、nan或无穷大，那么执行下面这样的操作可能会更快|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5141181|addl+$0x100000,+4(%25eax)+++#+x86+asm+example|code-block|syntax|javascript|5141182|乘以2；我认为只有当你在一个从零到无穷大的浮点数据的整个数组上进行操作时，这才是有益的，而2的幂缩放是你唯一要执行的操作(所以你没有任何现有的理由将数据加载到浮点寄存器中)。|5141183|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Central_processing_unit^0|3|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

On modern <a href="http://en.wikipedia.org/wiki/Central_processing_unit" rel="noreferrer">CPUs</a>, multiplication typically has one-per-cycle throughput and low latency. If the value is already in a floating point register, there's no way you'll beat that by juggling it around to do integer arithmetic on the representation. If it's in memory to begin with, and if you're assuming neither the current value nor the correct result would be zero, denormal, nan, or infinity, then it might be faster to perform something like

<pre><code>addl $0x100000, 4(%eax) # x86 asm example
</code></pre>

to multiply by two; the only time I could see this being beneficial is if you're operating on a whole array of floating-point data that's bounded away from zero and infinity, and scaling by a power of two is the only operation you'll be performing (so you don't have any existing reason to be loading the data into floating point registers).

blocks|key|5141243|text|对于嵌入式系统编译器来说，具有特殊的2的幂的缩放伪操作可能是有用的，该伪操作可以由代码生成器以对所讨论的机器最优的任何方式进行翻译，因为在一些专注于指数的嵌入式处理器上可能比进行完全的2次方乘法快一个数量级，但是在乘法最慢的嵌入式微处理器上，编译器可能可以通过让浮点乘法例程在运行时检查其参数以跳过尾数中为零的部分来实现更大的性能提升。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5141244|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It may be useful for embedded systems compilers to have special scale-by-power-of-two pseudo-op which could be translated by the code generator in whatever fashion was optimal for the machine in question, since on some embedded processors focusing on the exponent may be an order of magnitude faster than doing a full power-of-two multiplication, but on the embedded micros where multiplication is slowest, a compiler could probably achieve a bigger performance boost by having the floating-point-multiply routine check its arguments at run-time so as to skip over parts of the mantissa that are zero.

blocks|key|5050574|text|实际上，这就是在硬件中发生的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5050575|2也作为浮点数传递给浮点数，尾数为1.0，指数为2%5E1。对于乘法，指数相加，尾数相乘。|offset|length|style|CODE|5050576|假设有专门的硬件来处理复杂的情况(乘以不是2的幂的值)，并且特殊情况的处理并不比使用专用硬件差，因此没有必要使用额外的电路和指令。|5050577|entityMap^0|0|0|1|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Actually, this is what happens in the hardware.

The <code>2</code> is also passed into the FPU as a floating point number, with a mantissa of 1.0 and an exponent of 2^1. For the multiplication, the exponents are added, and the mantissas multiplied.

Given that there is dedicated hardware to handle the complex case (multiplying with values that are not powers of two), and the special case is not handled any worse than it would be using dedicated hardware, there is no point in having additional circuitry and instructions.

blocks|key|2926727|text|A+previous+Stackoverflow+question+about+multiplication+by+powers+of+2。共识和实际实现证明，不幸的是，目前没有比标准乘法更有效的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2926728|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/7720668/fast-multiplication-division-by-2-for-floats-and-doubles-c-c^0|0|1X|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="https://stackoverflow.com/questions/7720668/fast-multiplication-division-by-2-for-floats-and-doubles-c-c">A previous Stackoverflow question about multiplication by powers of 2</a>. The consensus, and the actual implementations, proved that unfortunately, there is no current way to be more efficient than standard multiplication.

blocks|key|5050628|text|如果你认为乘以2就意味着指数增加1，那就再想一想。以下是IEEE+754浮点算术的可能情况：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5050629|情况1:+Infinity和NaN保持不变。|5050630|情况2:通过增加指数并设置尾数(符号位除外)，将具有最大可能指数的浮点数更改为无穷大。|5050631|情况3:指数小于最大可能指数的归一化浮点数的指数增加1。耶！|5050632|情况4:设置了最高尾数位的非规格化浮点数的指数增加了1，将它们变成了规格化的数字。|5050633|情况5:最高尾数位被清除的非正规化浮点数，包括%2B0和-0，它们的尾数向左移动一个位位置，保持指数不变。|5050634|我非常怀疑，一个能正确处理所有这些情况的整数代码的编译器是否能像处理器中内置的浮点一样快。它只适用于2.0的乘法运算。对于乘以4.0或0.5，应用了一套全新的规则。对于乘以2.0的情况，您可能会尝试将x*+2.0替换为x%2B+x，许多编译器都这样做。也就是说，它们会这样做，因为例如，处理器可能能够同时执行一次加法和一次乘法，但不是每种类型中的一种。因此，有时你会选择x*+2.0，有时你会选择x%2B+x，这取决于其他操作需要同时做什么。|5050635|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

If you think that multiplying by two means increasing the exponent by 1, think again. Here are the possible cases for IEEE 754 floating-point arithmetic: 

Case 1: Infinity and NaN stay unchanged. 

Case 2: Floating-point numbers with the largest possible exponent are changed to Infinity by increasing the exponent and setting the mantissa except for the sign bit to zero. 

Case 3: Normalised floating-point numbers with exponent less than the maximum possible exponent have their exponent increased by one. Yippee!!!

Case 4: Denormalised floating-point numbers with the highest mantissa bit set have their exponent increased by one, turning them into normalised numbers. 

Case 5: Denormalised floating-point numbers with the highest mantissa bit cleared, including +0 and -0, have their mantissa shifted to the left by one bit position, leaving the exponent unchanged. 

I very much doubt that a compiler producing integer code handling all these cases correctly will be anywhere as fast as the floating-point built into the processor. And it's only suitable for multiplication by 2.0. For multiplication by 4.0 or 0.5, a whole new set of rules applies. And for the case of multiplication by 2.0, you might try to replace x * 2.0 with x + x, and many compilers do this. That is they do it, because a processor might be able for example to do one addition and one multiplication at the same time, but not one of each kind. So sometimes you would prefer x * 2.0, and sometimes x + x, depending on what other operations need doing at the same time.

blocks|key|2926807|text|这是我在GCC+10中看到的一个实际的编译器优化：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2926808|x+=+2.0+*+hi+*+lo;|code-block|syntax|javascript|2926809|生成以下代码：|2926810|mulsd+++%25xmm1,+%25xmm0++++++#+x+=+hi+*+lo;
addsd+++%25xmm0,+%25xmm0++++++#+x+%2B=+x;|2926811|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Here's an actual compiler optimization I'm seeing with GCC 10:
<pre><code>x = 2.0 * hi * lo;
</code></pre>
Generates this code:
<pre><code>mulsd %xmm1, %xmm0 # x = hi * lo;
addsd %xmm0, %xmm0 # x += x;
</code></pre>

I've often noticed gcc converting multiplications into shifts in the executable. Something similar might happen when multiplying an <code>int</code> and a <code>float</code>. For example, <code>2 * f</code>, might simply increment the exponent of <code>f</code> by 1, saving some cycles. Do the compilers, perhaps if one requests them to do so (e.g. via <code>-ffast-math</code>), in general, do it?

Are compilers generally smart enough to do this, or do I need to do this myself using the <code>scalb*()</code> or <code>ldexp()/frexp()</code> function family?

Why doesn't a compiler optimize floating-point *2 into an exponent increment?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我经常注意到gcc在可执行文件中将乘法转换为移位。当将int和float相乘时，可能会发生类似的情况。例如，2 * f可以简单地将f的指数递增1，从而节省一些周期。编译器，也许如果有人要求他们这样做(例如，通过-ffast-math)，通常会这样做吗？编译器通常是否足够智能来完成这项工作，或者我是否需要使用scalb*...

问为什么编译器不将浮点*2优化为指数增量？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么编译器不将浮点*2优化为指数增量？EN