Just an FYI - this is by no means Go related. These problems and techniques are
very common when doing HPC micro benchmarking.
> On Mar 24, 2020, at 4:10 PM, Orson Cart wrote:
>
>
>> On Tuesday, 24 March 2020 21:00:38 UTC, Sean Liao wrote:
>> setup upfront shouldn't be a problem
>> b.N is co
On Tuesday, 24 March 2020 21:00:38 UTC, Sean Liao wrote:
>
> setup upfront shouldn't be a problem
> b.N is constant throughout the function lifetime, the entire function is
> called multiple times during benchmarking
>
Thank you! I'd missed that. That makes things so much more straightforward
fo
setup upfront shouldn't be a problem
b.N is constant throughout the function lifetime, the entire function is
called multiple times during benchmarking
On Tuesday, March 24, 2020 at 9:56:19 PM UTC+1, Orson Cart wrote:
>
> On Tuesday, 24 March 2020 20:47:07 UTC, Robert Engels wrote:
>>
>> One way
On Tuesday, 24 March 2020 20:47:07 UTC, Robert Engels wrote:
>
> One way to handle this is to generate all of the data up front in an array
> and then just index into the array based on the run.
>
Yeah, I had thought of that before posting but then I'd have to decide on a
value for b.N. I was t
One way to handle this is to generate all of the data up front in an array and
then just index into the array based on the run.
> On Mar 24, 2020, at 3:42 PM, Orson Cart wrote:
>
>
>
>
>> On Tuesday, 24 March 2020 20:27:39 UTC, Adrian Ratnapala wrote:
>> ...
>> So that sounds like the use-
On Tuesday, 24 March 2020 20:16:21 UTC, Jake Montgomery wrote:
>
> I took a quick glance at the code, and I think I figured it out. The
> benchmark code, including StartTimer() and StopTimer() use time.Now(). On
> my windows machine time.Now() has an accuracy of 1ms. So by calling it for
> ever
On Tuesday, 24 March 2020 20:27:39 UTC, Adrian Ratnapala wrote:
>
> ...
So that sounds like the use-case is to call Stop-, StartTimer once
> before you enter the main loop of the benchmark. They not efficient
> enough for a tight inner loop.
>
Thanks for the input and I think that you are p
On Tuesday, 24 March 2020 20:26:10 UTC, Sean Liao wrote:
>
> see https://github.com/golang/go/issues/27217
>
Thanks, will do.
>
>
> On Tuesday, March 24, 2020 at 5:24:08 PM UTC+1, Orson Cart wrote:
>>
>> I posted this earlier but I realised that the code had a fundamental
>> error in it. I
Between foo() exiting and the hardware timer being read, there is
* The call to StopTimer()
* A conditoinal branch
* A call to time.Since
* Another conditional
* A call to either Now() or runtimenano()
Now calls might get inlined, and the branches get predicted, but I
doubt the overhead of all th
see https://github.com/golang/go/issues/27217
On Tuesday, March 24, 2020 at 5:24:08 PM UTC+1, Orson Cart wrote:
>
> I posted this earlier but I realised that the code had a fundamental error
> in it. I've corrected here it but the underlying problem still exists.
>
> I've recently started using g
I took a quick glance at the code, and I think I figured it out. The
benchmark code, including StartTimer() and StopTimer() use time.Now(). On
my windows machine time.Now() has an accuracy of 1ms. So by calling it for
every iteration, when the actual time is 600ns just makes the whole thing
wi
On Tuesday, 24 March 2020 19:51:24 UTC, Jake Montgomery wrote:
>
> Strange. I hope someone has a real answer for you.
>
> In the meantime, you can simplify your example to demonstrate the issue:
>
Thanks for taking a look at the code Jake. Just one question: you have the
call to b.StopTimer outsi
Strange. I hope someone has a real answer for you.
In the meantime, you can simplify your example to demonstrate the issue:
package demo_test
import (
"testing"
)
var Foo1 []string
var Count int = 8
func Benchmark1(b *testing.B) {
for i := 0; i < b.N; i++ {
Foo1 = foo(Count)
13 matches
Mail list logo
