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
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
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
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
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
>
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
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.
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
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
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
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
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)
I struggled to understand this for a white and just after posting I
embarrassingly notice that it's just a form of chaining and handler is
passed on. Sorry for the noise
On Tuesday, March 24, 2020 at 9:44:31 PM UTC+2, Karolis Tamutis wrote:
>
> Hi,
>
> I'm struggling to understand what's the
Hi,
I'm struggling to understand what's the point of doing the below
...
handler = {log: log, next: handler} // add logging
handler = ensureSessionID(handler) // add session ID
handler = { // add opencensus
instrumentation
...
Isn't the logHandler struct pointer
On Tuesday, 24 March 2020 18:50:32 UTC, Michael Jones wrote:
>
> yes
>
...and that is exactly the scenario that I believe is yielding inconsistent
results:
Given the following function to be benchmarked:
func foo() []string{
testData := []string{}
for i:= 0; i < 8; i++ {
testData =
Correct. I didn’t read the output... :) I just assumed the OP was doing that...
my bad.
> On Mar 24, 2020, at 1:46 PM, Tamás Gulácsi wrote:
>
>
> You've requested the total allocated space (--alloc_space), not only the heap
> used (--heap_inuse, or no flag).
> So that 17GiB is the total
yes
On Tue, Mar 24, 2020 at 11:48 AM Orson Cart
wrote:
> On Tuesday, 24 March 2020 18:31:29 UTC, Michael Jones wrote:
>>
>> You use them to stop the time charged against your benchmark.
>>
>> For example:
>>
>> bench:
>> stop timer
>> generate initial data
>> start timer
>> do test
>>
>
On Tuesday, 24 March 2020 18:31:29 UTC, Michael Jones wrote:
>
> You use them to stop the time charged against your benchmark.
>
> For example:
>
> bench:
> stop timer
> generate initial data
> start timer
> do test
>
Thanks Michael. What if the initial data has to be generated from
You've requested the total allocated space (--alloc_space), not only the
heap used (--heap_inuse, or no flag).
So that 17GiB is the total allocated size, does NOT include the released!
2020. március 24., kedd 15:16:46 UTC+1 időpontban Nitish Saboo a következőt
írta:
>
> Hi,
>
> I have already
You use them to stop the time charged against your benchmark.
For example:
bench:
stop timer
generate initial data
start timer
do test
On Tue, Mar 24, 2020 at 10:47 AM Orson Cart
wrote:
>
> On Tuesday, 24 March 2020 16:49:55 UTC, Robert Engels wrote:
>>
>> Can you please succinctly
On Tuesday, 24 March 2020 16:49:55 UTC, Robert Engels wrote:
>
> Can you please succinctly explain the problem?
>
Let's see. Benchmarks can yield incorrect results when b.StopTimer and
b.StartTimer are used.
My reasoning:
1/ I have a benchmark that calls a single function. The reported
Can you please succinctly explain the problem?
> On Mar 24, 2020, at 11:24 AM, 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 go
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 go test's benchmarks support and I'm
particularly interested in understanding the benchmark timer functions.
I've been
You have virtual memory most likely. The in use is clearly 17gb.
> On Mar 24, 2020, at 9:16 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> I have already gone through those links. They helped me to gather the mem
> profile and while analyzing the data(as given in those links) I have come
> across
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 go test's benchmarks support and I'm
particularly interested in understanding the benchmark timer functions.
I've been
I've recently started using go test's benchmarks support and I'm
particularly interested in understanding the benchmark timer functions.
I've been getting results that I found surprising and I was wondering if
anyone could explain what's going on here.
The code below has three benchmarks that
Hi,
I have already gone through those links. They helped me to gather the mem
profile and while analyzing the data(as given in those links) I have come
across the following issue:
While I was running the service for 100 minutes the 'top' command output
was showing Mem% as 11.1. There was no
Sorry not paper, two websites I gave you previously.
> On Mar 24, 2020, at 7:02 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> >>There is no root analysis available in Go. Read the paper I linked to.
>
> Sorry I did not get you. Which paper are you referring to?
>
> While I was running the
Hi,
>>There is no root analysis available in Go. Read the paper I linked to.
Sorry I did not get you. Which paper are you referring to?
While I was running the service for 100 minutes the 'top' command output
was showing Mem% as 11.1. There was no increase in mem usage since I had
not called
30 matches
Mail list logo
