Go: многопоточность

/* channel_test01.go   * Tests how go-routines interact with channels  * Call: channel_test01 --help   * Pls, do not use name "channel_test", because this name always is used by go-pkg-system  */  package main  import ( 	"fmt" 	"time" 	"flag" 	"os" 	"runtime" )  // flag support for program var MAXPROCS int var LOAD_CYCLES int //internal burden cycle  var Usage = func() {     fmt.Fprintf(os.Stderr, "Usage channel_test01 [-maxprocs=NN] [-cycles=NN] \n", os.Args[0]) }  func init() {     flag.IntVar(&MAXPROCS, "maxprocs", 1, "maxprocs for testing. From 1 to 256 ");     flag.IntVar(&LOAD_CYCLES, "cycles", 1000, "burden internal cycle for testing. From 1 to 1000000 and more "); }  func main() {      flag.Parse();//get MAXPROCS and LOAD_CYCLES from flags      // runtime.GOMAXPROCS() returns previous max_procs     max_procs := runtime.GOMAXPROCS(MAXPROCS)      // second call to get real state     max_procs = runtime.GOMAXPROCS(MAXPROCS)     fmt.Println("MaxProcs = ", max_procs)           ch1 := make(chan int)     ch2 := make(chan float64)  	go chan_filler(ch1, ch2) 	go chan_extractor(ch1, ch2)      fmt.Println("Total:", <-ch2, <-ch2)  }  func chan_filler(ch1 chan int, ch2 chan float64) {      const CHANNEL_SIZE = 1000000       for i := 0; i < CHANNEL_SIZE; i++ {         for j := 0; j < LOAD_CYCLES; j++ {             i++         }         //thus we avoid optimizer influence         i = i - LOAD_CYCLES          ch1 <- i     }      ch1 <- -1     ch2 <- 0.0 }  func chan_extractor(ch1 chan int, ch2 chan float64) {      const PORTION_SIZE = 100000     total := 0.0      for {         t1 := time.Now().UnixNano()         for i := 0; i < PORTION_SIZE; i++ {             // burden cycle             for j := 0; j < LOAD_CYCLES; j++ {                 i++             }             i = i - LOAD_CYCLES              m := <-ch1             if m == -1 {                 ch2 <- total             }         } 		         t2 := time.Now().UnixNano()         dt := float64(t2 - t1)/1e9 //nanoseconds ==> seconds         total += dt         fmt.Println(dt)     } }   

Результаты

Машина: Intel, 4 ядра по 3ГГц, 4 ГБ RAM, linux-x86-64, kernel-3.11, golang-1.1.2

Максимальное достижимое значение runtime.MAXPROCS на моей машине равно 256. Можно задать и больше, но все равно будет выставлено 256. Значение по умолчанию = 1.

Число потоков, порождаемых программой (ps -C channel_test01 -L)
При -maxprocs=1: 3 потока.
При -maxprocs=2 и более: всегда 4 потока.

Иногда при длительных операциях появлялось еще 2 потока, которые оставались до конца работы процесса. Похоже на сборку мусора.

(Попробовал и на одном из виртуальных серверов, который показывает в /proc/cpuinfo наличие 24 ядер. На нем число потоков также было равно 4. Но часто был и пятый поток — весьма похоже на то, что жадная vds-ка не спешила выделять память, и сборщик мусора вылезал осмотреться).

Зависимость скорости наполнения канала от количества потоков при cycles = 1000

Максимальная производительность развивается при MAXPROCS=1

Зависимость скорости наполнения канала от увеличения балластной нагрузки

Под нагрузкой многопоточность все же берет свое.

Выводы из графиков

При maxprocs=1 все работает в 1 поток, псевдо-многопоточность обеспечивается внутренним планировщиком голанга, который является весьма эффективным.
При maxprocs=2 и более появляется больше потоков, включается механизм взаимодействия между потоками. Возникают блокировки, и все становится медленнее, на спящих потоках — примерно в 2 раза.
При maxprocs=3..256 реальное число потоков в системе не растет, но часть потоков становится «псевдо-потоками», взаимодействие между которыми начинает попадать под управление внутреннего планировщика голанга. Это дает небольшой прирост скорости с каждым увеличением количества «псевдо-потоков».
С дальнейшим увеличением maxprocs (вплоть до своего максимального значения 256) все больше потоков становятся псевдо-потоками и попадают под управление внутреннего планировщика. Но часть потоков все равно остается независимыми системными потоками. На спящих потоках и быстрых вычислениях это нам обходится примерно в 10% производительности.

Вывод.

Изменение параметра runtime.MAXPROCS может принести как выигрыш, так и потерю в производительности. Это еще раз подтверждает общий принцип, что эффект от распараллеливания зависит от конкретной задачи и конкретного оборудования.