[go-nuts] help understanding weird Benchmark results

2020-05-19 Thread Warren Bare
Hi Folks,

I'm getting weird results from Benchmark.  Maybe someone can help me 
understand this.  I'm running on amd-64 (Threadripper 16 core 32 thread) 
Windows 10.  Go 1.14.3

I have the benchmark below (main_test.go) on a minimum "hello world" 
main.go (just like playground).

When I run the benchmark as it is below, I get the results included just 
below here.  Notice it reports 0.135 ns/op but the time is actually 135 *ms* so 
it is off by a factor of 1 billion.  It is like it trying to report in 
seconds but did not change the label from ns to s.

Further, if I increase the loop 10x from 10_000_000 to 100_000_000, then it 
prints Duration 1.349 seconds (good) and now the Benchmark time has 
increased by a factor of 10 *billion *and is now correctly reported as 
1349224200 ns/op

What am I missing here?

BenchmarkMarshalSample-32   10   0.135 ns/op   0 
B/op  0 allocs/op
--- BENCH: BenchmarkMarshalSample-32
main_test.go:14: Duration 136.1221ms
main_test.go:14: Duration 135.1214ms
main_test.go:14: Duration 134.1763ms
main_test.go:14: Duration 135.1217ms
main_test.go:14: Duration 135.1298ms
main_test.go:14: Duration 135.1217ms
main_test.go:14: Duration 135.1218ms
main_test.go:14: Duration 135.1213ms
main_test.go:14: Duration 135.1298ms
main_test.go:14: Duration 135.1216ms
... [output truncated]
PASS



package main

import (
"math/rand"
"testing"
"time"
)

func BenchmarkMarshalSample(b *testing.B) {
start := time.Now()
for i := 0; i < 10_000_000; i++ {
rand.Int63()
}
b.Log("Duration", time.Now().Sub(start))
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/33c4ab46-18ae-46c2-99e9-e467d6f3e184%40googlegroups.com.


Re: [go-nuts] A little weird thing in using finalizer

2020-04-25 Thread T L


On Saturday, April 25, 2020 at 1:53:28 AM UTC-4, Brian Candler wrote:
>
> On Saturday, 25 April 2020 06:35:22 UTC+1, T L wrote:
>>
>> Why is each of the finalizers called twice?
>>
>
>
> Isn't it just printed once in main and once in finalizer?
> https://play.golang.org/p/7aY9NA1AFNa
>
>
Aha, I'm sorry I forgot that println line. I thought all the lines are 
printed in finalizers. ;D 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bef84b46-8e95-42b6-b7f9-68830c1eab3f%40googlegroups.com.


Re: [go-nuts] A little weird thing in using finalizer

2020-04-24 Thread Brian Candler
On Saturday, 25 April 2020 06:35:22 UTC+1, T L wrote:
>
> Why is each of the finalizers called twice?
>


Isn't it just printed once in main and once in finalizer?
https://play.golang.org/p/7aY9NA1AFNa

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/86e3714f-95fc-4cdd-a6ca-57e2dd240dc6%40googlegroups.com.


Re: [go-nuts] A little weird thing in using finalizer

2020-04-24 Thread T L
With time.Sleep, it always prints:

> 31
> 37
> 47
> 47
> 37
> 31
>

Why is each of the finalizers called twice?

On Saturday, April 25, 2020 at 1:08:43 AM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Apr 24, 2020 at 9:30 PM T L > 
> wrote: 
> > 
> > The following program might print: 
> > 
> >> 31 
> >> 37 
> >> 47 
> >> 47 
> >> 37 
> >> 31 
> > 
> > 
> > or 
> > 
> >> 31 
> >> 37 
> >> 47 
> >> 47 
> > 
> > 
> > but with the highest possibility to print 
> > 
> >> 31 
> >> 37 
> >> 47 
> > 
> > 
> > Is not normal? 
> > 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "math/rand" 
> > "runtime" 
> > "time" 
> > "unsafe" 
> > ) 
> > 
> > type Foo struct { 
> > x int 
> > a int 
> > } 
> > 
> > func main() { 
> > for i := 0; i < 3; i++ { 
> > f := NewFoo(i) 
> > println(f.a) 
> > } 
> > 
> > runtime.GC() 
> > 
> > time.After(time.Second) 
> > } 
> > 
> > func do(i *uint) { 
> > runtime.SetFinalizer(i, func(f *uint) { 
> > fmt.Println(*f) 
> > }) 
> > } 
> > 
> > //go:noinline 
> > func NewFoo(i int) *Foo { 
> > f := {a: rand.Intn(50)} 
> > 
> > do((*uint)(unsafe.Pointer())) 
> > 
> > return f 
> > } 
>
> Finalizers are not guaranteed to run. 
>
> That said, I'm not sure why you are calling time.After.  That doesn't 
> make finalizers any more likely to run.  You'll probably see fairly 
> reliable results if you change that to call time.Sleep instead. 
>
> Ian 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/68c17055-b1ed-4b26-a6d2-63c02e1d8ea0%40googlegroups.com.


Re: [go-nuts] A little weird thing in using finalizer

2020-04-24 Thread Ian Lance Taylor
On Fri, Apr 24, 2020 at 9:30 PM T L  wrote:
>
> The following program might print:
>
>> 31
>> 37
>> 47
>> 47
>> 37
>> 31
>
>
> or
>
>> 31
>> 37
>> 47
>> 47
>
>
> but with the highest possibility to print
>
>> 31
>> 37
>> 47
>
>
> Is not normal?
>
>
> package main
>
> import (
> "fmt"
> "math/rand"
> "runtime"
> "time"
> "unsafe"
> )
>
> type Foo struct {
> x int
> a int
> }
>
> func main() {
> for i := 0; i < 3; i++ {
> f := NewFoo(i)
> println(f.a)
> }
>
> runtime.GC()
>
> time.After(time.Second)
> }
>
> func do(i *uint) {
> runtime.SetFinalizer(i, func(f *uint) {
> fmt.Println(*f)
> })
> }
>
> //go:noinline
> func NewFoo(i int) *Foo {
> f := {a: rand.Intn(50)}
>
> do((*uint)(unsafe.Pointer()))
>
> return f
> }

Finalizers are not guaranteed to run.

That said, I'm not sure why you are calling time.After.  That doesn't
make finalizers any more likely to run.  You'll probably see fairly
reliable results if you change that to call time.Sleep instead.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW4U90dkpDi6%2B2tdU83LhRXiPSnrCPWrB87G%3DkK1Enh_A%40mail.gmail.com.


[go-nuts] A little weird thing in using finalizer

2020-04-24 Thread T L
The following program might print:

31
> 37
> 47
> 47
> 37
> 31
>

or 

31
> 37
> 47
> 47
>

but with the highest possibility to print

31
> 37
> 47
>

Is not normal?


package main

import (
"fmt"
"math/rand"
"runtime"
"time"
"unsafe"
)

type Foo struct {
x int
a int
}

func main() {
for i := 0; i < 3; i++ {
f := NewFoo(i)
println(f.a)
}

runtime.GC()

time.After(time.Second)
}

func do(i *uint) {
runtime.SetFinalizer(i, func(f *uint) {
fmt.Println(*f)
})
}

//go:noinline
func NewFoo(i int) *Foo {
f := {a: rand.Intn(50)}

do((*uint)(unsafe.Pointer()))

return f
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/db59b870-b9c7-4411-a461-5857eb7017e2%40googlegroups.com.


[go-nuts] Re: Really weird timezone behavior.

2017-02-05 Thread Uli Kunitz
The Playground doesn't appear to support correct timezone info. The time 
package is modified on the Playground.

Your program runs as expected on my local machine. You are certainly aware 
that it is not properly formatted and doesn't do proper error handling.


On Saturday, February 4, 2017 at 7:06:57 PM UTC+1, LEGOlord208 wrote:
>
> Trying to convert timezones.
> Works nearly, but they have some minutes off!
>
> For example, these timezones should be equals:
> https://play.golang.org/p/_mnELD1nCv
> They aren't.
>
> Fun fact: Because of the way time is built, I can't just simply round it. 
> So this isn't going very well
>

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread Ian Lance Taylor
On Mon, Jul 25, 2016 at 10:40 AM, Matt Harden  wrote:
> The syntax is {...}. &42 does not match this syntax. What Jan was
> describing is specific to that syntax, not to the use of & in general; in
> fact let's try it for :
>
> tmp := x
> 
>
> This gives a very different and not useful value for  {...} is an
> exceptional syntactic sugar for grabbing the address of a compound value. It
> doesn't make much sense to generalize this syntactic sugar to other values.

As I recall, at one point before the public release of Go Russ made a
pitch for changing {} to (*T){} as that would be more consistent:
just as T{} creates a value of type T, (*T){} would create a value of
type *T.  But even though it was more consistent nobody really liked
it and we stuck with the {} syntactic sugar.

Ian

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread Matt Harden
The syntax is {...}. &42 does not match this syntax. What Jan was
describing is specific to that syntax, not to the use of & in general; in
fact let's try it for :

tmp := x


This gives a very different and not useful value for  {...} is an
exceptional syntactic sugar for grabbing the address of a compound value.
It doesn't make much sense to generalize this syntactic sugar to other
values.

On Mon, Jul 25, 2016 at 9:57 AM Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Mon, 25 Jul 2016 15:54:02 +
> Jan Mercl <0xj...@gmail.com> wrote:
>
> > > If T{} is like 42, why “({})" is legal?
> >
> > Because
> >
> > {...}
> >
> > is syntactic sugar for
> >
> > tmp := T{...} // behind the scenes
> > 
> >
> > and  is an okay receiver in the OP.
>
> But by the same logic one could state that
>
>   &42
>
> should be allowed because behind the scenes it could have been
>
>   tmp := 42
>   
>
> So, why this is not allowed for simple types?
>
> --
> 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.
>

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread T L
@Matt Harden, the recursive reason listens quite reasonable.

@all, thanks for paticipating this discussion.

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread Sam Whited
On Mon, Jul 25, 2016 at 11:23 AM, T L  wrote:
> It doesn't work. The receiver should be a pointer in function definition.
>
> https://play.golang.org/p/fQbbeDhB9O

Oh I see, I misunderstood. If the receiver is a pointer it's probably
so that you can modify the value, but in this case you are immediately
discarding the value anyways so there's no point in having it work
this way.

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread Matt Harden
On Mon, Jul 25, 2016 at 9:10 AM Sam Whited  wrote:

> On Mon, Jul 25, 2016 at 11:05 AM, T L  wrote:
> > Then why
> >
> > T{...}
> >
> > can't be a syntactic sugar for
> >
> > tmp := T{...}
> > tmp
> >
> > and tmp is an okay receiver.
> > :P
>
> It is (effectively)


Not so. The actual code tmp := T{...} would define a variable of type T,
which we could (implicitly) take the address of. So T{} doesn't work like a
syntactic sugar for the two lines. Anyway, that sugar would be recursive:
the expansion of T{...} includes T{...} itself! The expansion of ({...})
doesn't have this problem; it involves T{...} but not {...}.

I think the intuitive answer is that with {...} you are explicitly
requesting an address, so the compiler gives you one (instead of declaring
it a syntax error). With T{...}, any pointer method would potentially
modify the value, but the value is going to be thrown away (it's not stored
in a variable). So there's no point in modifying it. We reject this to
prevent hard-to-find bugs. And if you really want to call a pointer method
on a temporary value like that, you can add 3 characters &().

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread T L
It doesn't work. The receiver should be a pointer in function definition.

https://play.golang.org/p/fQbbeDhB9O

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread Sam Whited
On Mon, Jul 25, 2016 at 11:05 AM, T L  wrote:
> Then why
>
> T{...}
>
> can't be a syntactic sugar for
>
> tmp := T{...}
> tmp
>
> and tmp is an okay receiver.
> :P

It is (effectively); that works just fine: https://play.golang.org/p/SF2lznWaRj

eg. (T{}).f() should work.

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread T L
Then why

T{...}

can't be a syntactic sugar for

tmp := T{...}
tmp

and tmp is an okay receiver.
:P

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread T L
If T{} is like 42, why “({})" is legal?

-- 
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.


Re: [go-nuts] Is it weird?

2016-07-25 Thread Jan Mercl
On Mon, Jul 25, 2016 at 5:34 PM T L  wrote:

I cannot see a problem.

> ().f() // ok

 is a pointer, no problem here.

> t.f() // ok

t is adressable, again, no problem.

> ({}).f() // ok

{} is already a pointer, no surprise it's ok as a receiver of a pointer
method.

> T{}.f() // cannot call pointer method on T literal
> // cannot take the address of T literal

The error is quite clear. T{} is like 42. It's a non addressable
expression, so a pointer method cannot be called on it.



-- 

-j

-- 
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.


[go-nuts] Is it weird?

2016-07-25 Thread T L
package main

type T struct{}

func (t *T) f() {}

func main() {
t := T{}
().f() // ok
t.f() // ok

({}).f() // ok
T{}.f() // cannot call pointer method on T literal
// cannot take the address of T literal
}

-- 
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.