显然,x86(可能还有许多其他指令集)将除法运算的商和余数都放在单独的寄存器中。
现在,我们可能相信编译器会优化这样的代码,只使用一次调用来除法:
( x / 6 )
( x % 6 )
他们可能会这样做。尽管如此,是否有任何语言(或库,但主要是寻找语言)支持同时给出除法和模数结果?如果是这样,它们是什么,语法是什么样的?
C 有div
和ldiv
。这些是否为商和余数生成单独的指令将取决于您特定的标准库实现以及编译器和优化设置。从 C99 开始,您还可以lldiv
使用更大的数字。
Python 可以。
>>> divmod(9, 4)
(2, 1)
这很奇怪,因为 Python 是一种高级语言。
红宝石也是如此:
11.divmod(3) #=> [3, 2]
* 编辑 *
应该注意的是,这些运算符的目的可能不是尽可能高效地完成工作,更有可能出于正确性/可移植性原因而存在这些功能。
对于那些感兴趣的人,我相信这是整数 divmod 的 Python 实现代码:
static enum divmod_result
i_divmod(register long x, register long y,
long *p_xdivy, long *p_xmody)
{
long xdivy, xmody;
if (y == 0) {
PyErr_SetString(PyExc_ZeroDivisionError,
"integer division or modulo by zero");
return DIVMOD_ERROR;
}
/* (-sys.maxint-1)/-1 is the only overflow case. */
if (y == -1 && UNARY_NEG_WOULD_OVERFLOW(x))
return DIVMOD_OVERFLOW;
xdivy = x / y;
/* xdiv*y can overflow on platforms where x/y gives floor(x/y)
* for x and y with differing signs. (This is unusual
* behaviour, and C99 prohibits it, but it's allowed by C89;
* for an example of overflow, take x = LONG_MIN, y = 5 or x =
* LONG_MAX, y = -5.) However, x - xdivy*y is always
* representable as a long, since it lies strictly between
* -abs(y) and abs(y). We add casts to avoid intermediate
* overflow.
*/
xmody = (long)(x - (unsigned long)xdivy * y);
/* If the signs of x and y differ, and the remainder is non-0,
* C89 doesn't define whether xdivy is now the floor or the
* ceiling of the infinitely precise quotient. We want the floor,
* and we have it iff the remainder's sign matches y's.
*/
if (xmody && ((y ^ xmody) < 0) /* i.e. and signs differ */) {
xmody += y;
--xdivy;
assert(xmody && ((y ^ xmody) >= 0));
}
*p_xdivy = xdivy;
*p_xmody = xmody;
return DIVMOD_OK;
}
在 C#/.NET 你有:http Math.DivRem
:
//msdn.microsoft.com/en-us/library/system.math.divrem.aspx
但是根据这个线程,这并不是一个优化。
在 Java(自 1.5 起)中,该类BigDecimal
具有divideAndRemainder
返回 2 个元素的数组的操作,其中包含除法的结果和余数。
BigDecimal bDecimal = ...
BigDecimal[] result = bDecimal.divideAndRemainder(new BigDecimal(60));
.NET 框架具有Math.DivRem
:
int mod, div = Math.DivRem(11, 3, out mod);
// mod = 2, div = 3
虽然,DivRem
只是这样的包装:
int div = x / y;
int mod = x % y;
(我不知道抖动是否可以/确实将这类事情优化为一条指令。)
正如 Stringer Bell 提到的那样DivRem
,没有针对.NET 3.5 进行优化。
在 .NET 4.0上,它使用 NGen。
我得到的结果Math.DivRem
(debug; release = ~11000ms)
11863
11820
11881
11859
11854
我得到的结果MyDivRem
(debug; release = ~11000ms)
29177
29214
29472
29277
29196
针对 x86 的项目。
Math.DivRem
使用示例
int mod1;
int div1 = Math.DivRem(4, 2, out mod1);
方法签名
DivRem(Int32, Int32, Int32&) : Int32
DivRem(Int64, Int64, Int64&) : Int64
.NET 4.0 代码
[TargetedPatchingOptOut("Performance critical to inline across NGen image boundaries")]
public static int DivRem(int a, int b, out int result)
{
result = a % b;
return (a / b);
}
.NET 4.0 伊利诺伊
.custom instance void System.Runtime.TargetedPatchingOptOutAttribute::.ctor(string) = { string('Performance critical to inline across NGen image boundaries') }
.maxstack 8
L_0000: ldarg.2
L_0001: ldarg.0
L_0002: ldarg.1
L_0003: rem
L_0004: stind.i4
L_0005: ldarg.0
L_0006: ldarg.1
L_0007: div
L_0008: ret
FWIW,Haskell 两者都有divMod
,quotRem
后者直接对应于机器指令(根据积分运算符 quot vs. div),而divMod
可能没有。
int result,rest;
_asm
{
xor edx, edx // pone edx a cero; edx = 0
mov eax, result// eax = 2AF0
mov ecx, radix // ecx = 4
div ecx
mov val, eax
mov rest, edx
}