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 experience such great difficulties. This is very frustrating for me 在2021年2月2日星期二 UTC+8 上午3:13:18<Ian Lance Taylor> 写道：
> On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 <nnsm...@gmail.com> 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) return on your system? > > In general the Go runtime is optimized for the case where there are > more goroutines than there are processors. Goroutines that run for a > long time without yielding the processor are preempted. I don't think > that preemption process considers the possibility that there is > nothing else to do. > > Do you expect your real program that have long running CPU-bound > goroutines, and to not have any other work to do (i.e., no network > connections and no file I/O)? If so the goroutine scheduler may not > be well tuned for your code. > > Also note that the scheduler changed significantly in Go 1.14, so it's > worth testing that. I have no particular reason to think that it will > be better, but it may well be different. > > 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/fe722436-d5f5-4599-81ae-d073cb03beb7n%40googlegroups.com.
