Comments 5
чтобы понимать, что применение многопоточности в разных кейсах может привести как к повышению производительности, так и к потере производительности.
Я бы сказал, что это нужно не понимать, а измерять. Во первых, многопоточность по определению может как замедлить, так и ускорить. Ведь все имеет накладные расходы. А во вторых, измерять, измерять и ещё раз измерять. Невозможно утверждать, что мы добавили многопоточность в наш проект и теперь оно бысирее, не имея таймингов перед изменением и после изменения, для сравнения. Такое утверждение будет просто враньём. Поэтому, понимать не нужно, нужно просто замерить изменение скорости работы и все будет видно.
По этой теме есть хороший доклад https://www.youtube.com/watch?v=-K11rY57K7k
Спасибо большое за статью)
Единственное, M - это не совсем поток OS, это объект рантайма Go, вот тут https://www.sobyte.net/post/2022-07/go-gmp/#2-life-cycle-of-m подробнее
И поделюсь ссылкой на видео, которое, как и ваша статья, помогло мне понять всю механику https://www.youtube.com/watch?v=rloqQY9CT8I
Простое описание того, как работает go - планировщик по большому счету смысла не имеет. Если бы я брал человека на работу и он он бы рассказал вот эту статью, я бы затем спросил: «ну и что?». Ну вот работает он так, ну и что? Горутины в go в чем - то лучше/хуже корутин в том же python? В kotlin? В js? Зачем go? Как - то все сложно тут сделали. А зачем GOMAXPROCS? А что, горутины путешествуют между потоками? А в других языках? Все познается в сравнении.
Сама суть то я считаю, простая. Конечно, по статье можно косвенно об этом судить, но вот это G,M,P понимание не особенно для рядового программиста важно. Многие пытаются на собесах про это G,M,P, я думаю, вспомнить, при этом за деревьями леса не видя
Go scheduler. Простыми словами