I don't understand. We are truncating the result to 32-bits either way.
What's the point of computing the entire 64-bits of the result just to
throw away the high 32?
In your example, A=2^62 and B=13`, `uint32(A / uint64(B))` is (2^62 / 13) %
2^32 which I thought is exactly the result of DIV r32.
-Radu
On Thursday, November 10, 2016 at 8:46:02 AM UTC-5, alb.do...@gmail.com
wrote:
>
> When you do a DIV r32 in 64bit mode the result will be saved in
> EAX but this means that you can only do that if the high word
> of the dividend is smaller that the divisor.
>
> You can't unconditionally replace uint32(A / uint64(B)) with a
> DIV r32 instruction because if A is big (take 2**62) and B is
> small (take 13) then the quotient will overflow EAX.
>
> A.
>
>
>
> Il giorno martedì 8 novembre 2016 06:18:02 UTC+1, ra...@cockroachlabs.com
> ha scritto:
>>
>> Sorry to revive an old thread. One thing to note is that dividing a
>> 64-bit by a 32-bit is much faster than dividing a 64-bit by a 64-bit, at
>> least on recent Intel platforms. Unfortunately there is no valid way to
>> express that kind of calculation in Go..
>>
>> Is the compiler/optimizer smart enough to figure out it can do that if
>> you do something like `uint32(a / uint64(b))` where a is `uint64` and b is
>> `uint32`? (the result of that expression can be computed using the 32-bit
>> version of DIV)
>>
>> On Saturday, January 19, 2013 at 6:10:34 PM UTC-5, Michael Jones wrote:
>>>
>>> Integer division is slow.
>>>
>>> It is the unloved arithmetic operation in CPU design because of its low
>>> frequency of occurrence in the instruction stream. It is the one--if you
>>> remember childhood schooling--that was "not like the others" in its
>>> mechanism: there was lots of guessing using leading digits, trial divisors,
>>> and so on. This awkwardness exists even in base 2 (though much less) and
>>> means that any division circuit my have to do at least one "fixup" step. (A
>>> good design does either zero or one fixup, but that one means more work and
>>> plausibly an extra cycle on what is already a long cycle-count activity.)
>>>
>>> As one specific example, when adding and subtracting were 1 cycle and
>>> multiply was 4, a 32-bit integer division required 19 cycles.
>>>
>>>
>>> On Sat, Jan 19, 2013 at 1:25 PM, minux <minu...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Jan 20, 2013 at 5:22 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>>>
>>>>> On Sat, Jan 19, 2013 at 10:13 PM, Dominik Honnef <
>>>>> domi...@fork-bomb.org> wrote:
>>>>>
>>>>> Cannot reproduce here (Xeon on dont-know-how-much GHz)
>>>>>
>>>>> jnml@fsc-r630:~/src/tmp/20130119$ cat a_test.go
>>>>> package main
>>>>>
>>>>> import (
>>>>> "testing"
>>>>> )
>>>>>
>>>>> func BenchmarkBase(b *testing.B) {
>>>>> var x int32
>>>>> for i := 1; i < b.N; i++ {
>>>>> }
>>>>> _ = x
>>>>> }
>>>>>
>>>>> func BenchmarkInt(b *testing.B) {
>>>>> var x int
>>>>> for i := 1; i < b.N; i++ {
>>>>> x /= 42
>>>>> }
>>>>> _ = x
>>>>> }
>>>>>
>>>> division by a constant should be turned into multiplication by magic
>>>> constants
>>>> by the Go compiler just to avoid the costly divide instruction.
>>>>
>>>> you can verify that by 'go tool 6g -S'.
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
>>> 650-335-5765
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
