Traditionally you'd write that sort of thing in assembler to get that
amount of control. Though the modern thing would be to have intrinsics..
I guess in the go world, having assembler routines that could be inlined
would be the optimum solution.
On 10/11/16 13:45, alb.donize...@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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
Nick Craig-Wood <n...@craig-wood.com> -- http://www.craig-wood.com/nick
--
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.
