Just because we can add multiple logical processors for the scheduler to use doesn’t mean we should

[WALID BELRHALMIA]

Hello my golang brother,

i was reading William kennedy post about Concurency https://www.goinggo.net/2014/01/concurrency-goroutines-and-gomaxprocs.html     and at the end he said "Just because we can add multiple logical processors for the scheduler to use doesn’t mean we should"  , because i think that ading the max logical CPU to awer program can only add moe performance, can somme one provide me with more information.

[William Kennedy]

There are many factors that will determine how well your program performs. There are no guarantees that using more threads or goroutines is going to yield better performance. Sometimes throwing more threads or goroutines at a problem can slow things down. It really depends on the work you are doing and how you are doing it.

If you are just learning Go and concurrency start with solving a problem with one goroutine on a single thread. Then add more goroutines and threads slowly and measure the results. Is the performance gains you may get using two goroutines or more worth the complexity it required to get there? Was the program fast enough using one goroutine? What is most important to you for this particular problem, readability, simplicity or performance? There are lots of factors at play here.

[Ingo Oeser]

The default of using only one thread to run goroutines default changed with Go 1.5 to using all available cores reported by the OS. Tuning GOMAXPROCS has now less relevance in practice, rendering the article as outdated in that regard.

Just leave the GOMAXPROCS settings alone until a strong use case with careful system benchmarks proves it wrong for a certain workload.

Just compose independent workloads as goroutines and tune it after benchmarks.

When you are just passing pure setup or processing tasks without any files, external program or network in between, just use a call instead of goroutines.

[T L]

Usually, GOMAXPROCS==NumberAvaliableCpuCores (the default value since go1.5) will get the best performance.
For some special cases, a smaller GOMAXPROCS value will perform better.
But A GOMAXPROCS value larger than NumberAvaliableCpuCores will always decrease the performance, IMO.

[John Souvestre]

Ø  But A GOMAXPROCS value larger than NumberAvaliableCpuCores will always decrease the performance, IMO.

Although unusual, I did have a case where it was handy to use double the value of CPUs.  It was a situation where there were a number of low-priority, compute-bound processes and a bunch of regular processes.  The regular processes saw less latency due to the operating system being able to implement its form of fairness when preemptively scheduling the treads/procs.

 

Btw – If you were referring to runtime.NumCPU it’s actually the number of logical CPUs, not cores.  Quite often hyperthreading results in more CPUs than cores.

 

John

    John Souvestre - New Orleans LA

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.