ok
在2021年2月2日星期二 UTC+8 下午4:24:12 写道：
> On Mon, 2021-02-01 at 23:48 -0800, 颜文泽 wrote:
> > This is my code:
> > 2021-02-02 15-45-01 的屏幕截图.png
>
> Please don't post code as images.
>
>
>
--
You received this message because you are subscribed to the Goog
thank you。
在2021年2月2日星期二 UTC+8 下午4:17:46 写道：
> On Tue, Feb 2, 2021 at 8:48 AM 颜文泽 wrote:
>
>> And then this is the result, it's amazing.I think I know why my program
>> is slow, the number of routines is too high
>
>
> 13 goroutines is certainly not "
Probably introduced by a third-party package. I'll troubleshoot.
在2021年2月2日星期二 UTC+8 下午3:50:32<颜文泽> 写道：
> Note: I don't use the init function
> 在2021年2月2日星期二 UTC+8 下午3:48:26<颜文泽> 写道：
>
>> If it works, it's fine, I'll just keep using vtune. I only work on x86
&g
Note: I don't use the init function
在2021年2月2日星期二 UTC+8 下午3:48:26<颜文泽> 写道：
> If it works, it's fine, I'll just keep using vtune. I only work on x86
> anyway. That said, I found another miracle, my program has 13 routines as
> soon as it starts. It's so peculiar. I simply can't
to the masses for free..
>
> On Tuesday, 2 February 2021 at 06:37:37 UTC nnsm...@gmail.com wrote:
>
>> One more question, is it effective to use vtune to tune golang. I am
>> afraid that vtune is not suitable, although intel claims to be effective.
>> 在2021年2月2日星期二 UTC
One more question, is it effective to use vtune to tune golang. I am afraid
that vtune is not suitable, although intel claims to be effective.
在2021年2月2日星期二 UTC+8 下午2:32:40<颜文泽> 写道：
> Thanks, it's not memory db, but my current test is not involving io. I'll
> take time to
number of cpus. Remember too that you need some % of the cpus to
> execute the runtime GC code and other housekeeping.
>
> > On Feb 1, 2021, at 10:04 PM, 颜文泽 wrote:
> >
> > I found that cache misses from routines switching is also a headache
>
>
--
You received this mes
original code did `for i := 1; i < Mcpu; i++ {` which only
> creates 7, not 8, goroutines. Is that intentional? It seems wrong given the
> discussion to this point. Which raises additional questions about your
> premise.
>
> On Mon, Feb 1, 2021 at 8:04 PM 颜文泽 wrote:
>
>&g
ad, cache locality / invalidation, lock
> contention).
>
> On Feb 1, 2021, at 9:02 PM, 颜文泽 wrote:
>
>
>
>
> I don't understand what you mean.
> 在2021年2月2日星期二 UTC+8 上午10:56:41 写道：
>
>> Having more cpu bound routines than you have physical cpus is not a good
&g
I don't understand what you mean.
在2021年2月2日星期二 UTC+8 上午10:56:41 写道：
> Having more cpu bound routines than you have physical cpus is not a good
> idea.
>
> On Feb 1, 2021, at 8:21 PM, 颜文泽 wrote:
>
> I'll try 1.14, when writing cpu-intensive programs (I'm mainly a
&g
wrote:
> >
> > Dnia 2021-02-01, o godz. 11:12:22
> > Ian Lance Taylor napisał(a):
> >
> > > On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 wrote:
> >
> > > > go version go1.13 linux/amd64
> >
> > > Goroutines that run for a long time without yielding th
not
experience such great difficulties. This is very frustrating for me
在2021年2月2日星期二 UTC+8 上午3:13:18 写道：
> On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 wrote:
> >
> >
> > $ go version
> > go version go1.13 linux/amd64
> >
> >
> > I'm not sure how to deal with thi
$ go version
go version go1.13 linux/amd64
I'm not sure how to deal with this phenomenon when I find that the parallel
performance using go routine is not very good when writing database(olap)
code. I have written the following example to verify this:
```
package main
import (
"fmt"
13 matches
Mail list logo
