Ah, I missed that, thanks!

On Thursday, November 10, 2016 at 9:05:53 AM UTC-5, alb.do...@gmail.com 
wrote:
>
> If the div overflow, it will trigger and hardware exception. 
>
> Il giorno giovedì 10 novembre 2016 15:01:06 UTC+1, ra...@cockroachlabs.com 
> ha scritto:
>>
>> 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.

Reply via email to