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 Google Groups
"golang-nuts" group.
To
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 Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from
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 "too high".
>
>
>> but I found that the
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 "too high".
> but I found that the GOMAXPROCS function doesn't work, it's a really
> confusing
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
>> anyway. That said, I found
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 understand why
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 understand why this is.
This is my code:
[image: 2021-02-02 15-45-01 的屏幕截图.png]
And then this is
Vtune is very useful for squeezing the ultimate performance out of Go
programs, once you have done
the usual optimisation, mimized allocations, io etc.
pprof is more than adequate for the average programmer. But when you need
to super-optimise
functions which implement math kernels, crypto
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 look at your
Unless it is an in memory database, I would expect the IO costs to dwarf the
cpu costs, but I guess a lot depends on how you define ‘analytical processing’.
In my experience, “out of the box” performance of Go routines in IO processing
is outstanding.
For the cpu bound case, I think with
I don't know much about the internal implementation of golang, sorry. I was
a c programmer and I tried to implement the original logic (olap database)
by using routine as a thread replacement. But I found that I would
encounter bottlenecks, and I don't know how to solve them. Maybe I should
Sorry, my machine has a cpu core of 8. I wrote the code this way because
the main routine is also involved in the calculation. So there will be code
like i = 1; i < Mcpu.
I considered the main routines when trying to control that the number of
routines is not more than the number of cpu. This
You wrote “I found that cache misses from routines switching is also a
headache”.
They would not be switching if they are cpu bound and there are less of than
number of cpus. Remember too that you need some % of the cpus to execute the
runtime GC code and other housekeeping.
> On Feb 1,
That is not what you told us, but perhaps there is a misunderstanding. In
your first message you said:
> My machine has exactly 8 cpu's and I found that the runtime does not
decrease linearly when the number of go routines increases.
Are you saying that the runtime does not decrease linearly
But the number of my routines is smaller than the number of cpu
在2021年2月2日星期二 UTC+8 上午11:17:55 写道：
> If you look at the “disrupter pattern” you’ll see what I mean. If the
> tasks are cpu bound - by having more threads/routines than cpus you cause
> inefficiencies (scheduling overhead, cache
If you look at the “disrupter pattern” you’ll see what I mean. If the tasks are
cpu bound - by having more threads/routines than cpus you cause inefficiencies
(scheduling overhead, cache locality / invalidation, lock contention).
> On Feb 1, 2021, at 9:02 PM, 颜文泽 wrote:
>
>
> I don't
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
> database), I found that
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 database),
> I found that cache misses from routines switching is also a headache and I
> don't know
I'll try 1.14, when writing cpu-intensive programs (I'm mainly a database),
I found that cache misses from routines switching is also a headache and I
don't know how to deal with it.
在2021年2月2日星期二 UTC+8 上午8:10:12 写道：
> On Mon, Feb 1, 2021 at 4:07 PM Wojciech S. Czarnecki
> wrote:
> >
> >
runtime.GOMAXPROCS(0) = 8, I write cpu-intensive olap databases, and the
basic principle of routines is smaller than the cpu, which I still control.
However, I found that routines can be very harsh and lead to a linear
performance increase, whereas the same implementation in cpp and c did not
On Mon, Feb 1, 2021 at 4:07 PM Wojciech S. Czarnecki 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 the processor are
>
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 the processor are
> preempted.
Since go1.14 TMK. OP is using 1.13.
> > I'm not sure how to
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 this phenomenon when I find that the parallel
> performance using go routine is not very good when writing database(olap)
> code.
What does runtime.GOMAXPROCS(0)
23 matches
Mail list logo
