Что не так с потоками?

Question

[vasyash]

По непонятной причине потоки (goroutines) сами по себе перестают выполняться. А именно работает только половина потоков, если даже создать только два. Функцию runtime.GOMAXPROCS() пробовал, ничего не меняется.
Хотя на скриншоте процессор загружен полностью, если создать 56 потоков.

package main
import (
	"math"
	"time"
)
func thread(x *int64) {
	print("thread")
	for {
		math.Sqrt(math.Pow(1999990093912455, 234))
		math.Sqrt(math.Pow(1999990093912455, 234))
		math.Sqrt(math.Pow(1999990093912455, 234))
		math.Sqrt(math.Pow(1999990093912455, 234))
		math.Sqrt(math.Pow(1999990093912455, 234))
		math.Sqrt(math.Pow(1999990093912455, 234))
		*x++
	}
}

func main() {
	perftracing := []int64{}
	threads := 2
	for i := 0; i < threads; i++ {
		perftracing = append(perftracing, 0)
		go thread(&perftracing[i])
		time.Sleep(1)
	}
	for { //цикл чтобы не завершался основной процесс
		time.Sleep(1) 
		for i := 0; i < threads; i++ { //цикл чтобы следить за выполнением
			print(perftracing[i], " ")
		}
		println()
	}
}

Comments

[vasyash]

Значения элементов массива

1. 32444 2170 37844 16979 3119 3055 361 464 78804 51713 73836 67799 22803 18418 16646 8884 1906258 1767282 1806336 1772800 1780497 1717713 1754590 1744924 2163826 2194542 2073995 2023747
   
2. 32444 2170 37844 16979 3119 3055 361 464 78804 51713 73836 67799 22803 18418 16646 8884 1924693 1785910 1821730 1791150 1795940 1733121 1772935 1763390 2184964 2215907 2094449 2045257
   
3. 32444 2170 37844 16979 3119 3055 361 464 78804 51713 73836 67799 22803 18418 16646 8884 1942865 1804361 1837017 1808923 1811454 1748349 1791085 1781784 2206099 2236873 2115593 2066269
   
4. 32444 2170 37844 16979 3119 3055 361 464 78804 51713 73836 67799 22803 18418 16646 8884 1963289 1824514 1851671 1824053 1826297 1763309 1811155 1801959 2226331 2259539 2137539 2089160
   
5. 32444 2170 37844 16979 3119 3055 361 464 78804 51713 73836 67799 22803 18418 16646 8884 1983293 1844454 1866540 1839076 1841269 1778056 1830740 1821680 2246426 2281849 2159185 2111918
   
6. 32444 2170 37844 16979 3119 3055 361 464 78804 51713 73836 67799 22803 18418 16646 8884 2003541 1864914 1881450 1854323 1856262 1793048 1850931 1841952 2266896 2304516 2181265 2134925
   
   

[vasyash]

Дополняю.
Количество запущенных потоков - Количество работающих потоков
1 - 1; 2 - 1; 3 - 1; 4 - 2; 6 - 2; 8 - 4; 12 - 4; 16 - 8; 32 - 16

[Александр Павлюк]

@vasyash
Какая версия go?

[d'Ivan]

vasyash, не потоки, а корутины.

[d'Ivan]

В одном потоке может работать много корутин.

[vasyash]

Александр Павлюк, go1.19 windows/amd64

[vasyash]

Román Mirilaczvili, в системе они работают как потоки. судя по диспетчеру задач

[d'Ivan]

vasyash, ну конечно же. Но в каждом потоке может быть > 1 корутины. С точки зрения ОС выделяются потоки, а как там внутри работает, это ответственность рантайма Го.

[d'Ivan]

И еще непонятно что за идея преследовалась при написании этого бесполезного примера.

[vasyash]

Román Mirilaczvili, да программа для примера просто. проблема везде такая

[vasyash]

всё, отставить xD
проблема решена. если объявить массив perftracing статическим, то всё нормально работает.
ещё прописал runtime.GOMAXPROCS(416) (в четыре раза больше чем потоков) и всё нормально заработало

[d'Ivan]

vasyash, тогда напиши свой ответ и отметь его как решение.

[d'Ivan]

vasyash,

GPUs are best suited for repetitive and highly-parallel computing tasks. Beyond video rendering, GPUs excel in machine learning, financial simulations and risk modeling, and many other types of scientific computations. While in years past, GPUs were used for mining cryptocurrencies such as Bitcoin or Ethereum, GPUs are generally no longer utilized at scale, giving way to specialized hardware such as Field-Programmable Grid Arrays (FPGA) and then Application Specific Integrated Circuits (ASIC).

https://www.heavy.ai/technical-glossary/cpu-vs-gpu

[mayton2019]

Насколько я понимаю юзкейс Go-Lang не связан с интенсивными вычислениям. Все-таки язык создавался Google для обслуживание микро-сервисных задач. А это на 80% - Network/IO. О рендеринге графики или о транс-вычислительных задачах речи нет. А автор шутки ради зарядил возведение в степень и квадратный корень для длинных целых. Это - чистой воды троллинг Go-архитектуры.

Answer 1

[falconandy]

С "потоками" всё так, просто вы неправильно работаете с "массивом".

perftracing = append(perftracing, 0) при исчерпании выделенной памяти выделяет новый блок памяти (по-моему удвоенного размера) и копирует текущие элементы в новый блок. Соответственно часть (половина) горутин пишет по старым адресам, а в выхлопе данные из последнего выделенного блока памяти.

...
0 0 0 0 5197273 5671085 5177800 5797080 
0 0 0 0 5197332 5671147 5177908 5797137 
0 0 0 0 5197388 5671208 5178008 5797195 
0 0 0 0 5197450 5671269 5178118 5797248
...

Если создать "массив" заранее со всеми элементами, то всё выводится нормально:

threads := 4
perftracing := make([]int64, threads)
for i := 0; i < threads; i++ {
	go thread(&perftracing[i])
	time.Sleep(1)
}

...
5593758 7107822 5575001 6449763 6321574 5535152 5728000 7196092 
5593813 7107884 5575056 6449859 6321628 5535209 5728060 7196153 
5593879 7107959 5575122 6449976 6321695 5535275 5728122 7196217 
5593936 7108030 5575180 6450079 6321757 5535339 5728190 7196285 
...
5594008 7108109 5575251 6450199 6321821 5535403 5728251 7196349

Ну и вместо time.Sleep(1) вы наверно имели в виду что-то типа time.Sleep(time.Second * 1)

Go 1.19.3, Kubuntu 22.04

Answer 2

[Александр Павлюк]

Рантайм го расчитан на то, что большинство горутин будут иметь точки блокировок, что логично для веб-сервисов. Когда сервис блокируется на чтении/записи сети/файла, планировщик переключается на другую горутину. Поэтому нет никаких гарантий того, что нагрузка равномерно распределиться, если все горутины будут заняты просто числомолотилками.
После какой-то версии го (точно не помню номер), завезли вытесняющую многозадачность и теперь планировщик может переключать горутины даже на числомолотилках, но делает он это обычно когда запускается сборка мусора или срабатывает случайный таймер. Поэтому равномерного распределения на таких задачах не ждите, язык просто делался не для этого.

Answer 3

[d'Ivan]

непонятной причине потоки (goroutines) сами по себе перестают выполняться.

В каждом потоке может быть > 1 корутины. С точки зрения ОС выделяются потоки, а как там внутри работает - это ответственность рантайма Го. Выделяется то количество потоков ОС, которое рантайм посчитает достаточным.

Answer 4

[Алексей Бадяев]

Для ответа на вопрос нужна дополнительная информация: как именно было установлено, что "потоки (goroutines) сами по себе перестают выполняться" и "работает только половина потоков, если даже создать только два" ?

Comments

[vasyash]

Через массив, я же написал в комментарии

[Алексей Бадяев]

Горутины не являются потоками - в одном потоке ОС может быть много горутин и управляются они планировщиком Go-runtime, вследствие чего отдельные горутины, поток выполнения которых не содержит операций с каналами или иных прерываний, могут не получать управления длительное время.