Отличная презентация. Небольшие дополнения: • 8 мб - верхняя граница размера стека потока ОС, дефолтное значение зависит от дистрибутива, можно поменять через ulimit. По факту при создании системного потока эти 8 мб аллоцируются в виртуальной памяти (устанавливаются MMU page tables), т.о. начальный размер физической памяти для системного треда 16 кб для 64 битных дистров. • Про переключение контекста потоков ОС: стек горутины по факту создаётся в хипе, а не в стеке системного потока. Это тоже влияет на быстрое переключение контекста горутин (и на то, что стек горутины может расти до 1 Гб). Т.к. горутина не работает со стеком потока ОС, для горутины используется всего 3 регистра ЦПУ, которые нужно скинуть при переключении контекста. Т.е. даже если ОС переключит поток, на котором выполнялись горутины, планировщик может очень быстро перекинуть их на другой поток. Надеюсь, не слишком коряво написал.
@@avikbox ютуб не даёт ссылки вставлять в комменты. Про память - на kernel орг есть дока по vmallocated. Про горутины можно у Дейва Чейни (Dave Cheney) почитать, и вообще много что у него почтитать можно по go)
Владимир, спасибо. Лучшее объяснение по теме. Многие вещи знал, но не до конца понимал, а сейчас кааак понял. Все-таки сторителлинги решают. Еще раз спасибо за труд.
Прекрасная лекция. Пожалуй, что стоило еще хотя бы в пару предложений упомянуть, как этот планировщик (вместе с планировщиком памяти) начинают страдать, когда нужен интероп (например с C). Впрочем, похожие страдания возникают у всех языков с богатым рантаймом (Python, Java/JRE, C#/dotnet, JS/V8 и других). Отдельная забава, когда в одном процессе хочется иметь более одного такого рантайма.
Несовсем остался понятен момент с откреплением потока при системном вызове. В итоге по факту как работает? 1. Поток открепляется от процессора и переходи в тред пул? Тогда получается для этого процессора будет создан новый поток? У него же есть еще другие горутины 2. Поток не открепляется, а существует тред потоков, которые выполняют системные вызовы. Мы передаем выполнение кода этой горутины треду в тред пуле. Какой из вариантов корректный? В лекции эта часть сумбурно рассказана
Противоречие. Вопрос по 40:45, выполнившаяся горутина идет в lifo и вытесняет прежную lifo горутину в fifo или же в выполнение? В первый раз сказал первое, во второй раз второе.
Владимир спасибо большое за урок !!! Но вот я не могу понять что на собесе я говорю что в планировщике преимущественно все таки кооперативная много задачность , но теперь и есть вытеснение, но мне говорят что я не прав , что сейчас планировщик преимущественно реализует вытеснение, что это было переделано в последних версиях го , буду благодарен за Ваш ответ 🙏🏻
Поправьте правильно ли я понял: если приложение получает очень много ввода-вывода заведомо долгих операций (к примеру 1000)-> скедулер создаёт ос тред в котором крутится еполл на 1000 сокетов, вместо создания кучи ос тредов на тред пуле? Вот этот момент не до конца понял, объясните пожалуйста
Получается максимум может быть 256 горутин на один поток, тогда горутины ограничены количеством потоков * 256? Мой ноут начинает умирать при +-30к потоках, тогда максимум я смогу создать +-7,5млн горутин?
Если делать шардирование, как в видео, то нет смысла использовать больше потоков, чем ядер на цпу, плюс поток на обработку сискола, если делать больше потоков, они начнут голодать
Очень много понятия "контекст", но не дано определения, что это такое. А в го контекст - это вообще канал из пакета. Это такое же же или другое? Переключение контекстов медленное "потому что ядро". А других местах линупса это наоборот - аргумент того, что хорошо(какой-нибудь драйвер). А медленно - это насколько медленно?
И опять таки, линупс - прекраснейшее ядро. Неужели мы сейчас на коленке сделаем контекст свитчинг и быстрее и лучше чем там? В общем, не хватает конкретики в этой истории с конткстом.
Так говоришь, как будто на с/с++ многопоточности невозможно писать высоконагруженные системы. Всё на тредпулах, везде поток на соединение, везде всё работает прекрасно, никто в tcp очередях не ждёт. Руки прямые просто нужны.
Присоединяйтесь к моему каналу в Телеграм: t.me/vladimir_balun_programming
отдельное спасибо за темный фон, глазам комфортно 👍
Отличная презентация. Небольшие дополнения:
• 8 мб - верхняя граница размера стека потока ОС, дефолтное значение зависит от дистрибутива, можно поменять через ulimit. По факту при создании системного потока эти 8 мб аллоцируются в виртуальной памяти (устанавливаются MMU page tables), т.о. начальный размер физической памяти для системного треда 16 кб для 64 битных дистров.
• Про переключение контекста потоков ОС: стек горутины по факту создаётся в хипе, а не в стеке системного потока. Это тоже влияет на быстрое переключение контекста горутин (и на то, что стек горутины может расти до 1 Гб). Т.к. горутина не работает со стеком потока ОС, для горутины используется всего 3 регистра ЦПУ, которые нужно скинуть при переключении контекста. Т.е. даже если ОС переключит поток, на котором выполнялись горутины, планировщик может очень быстро перекинуть их на другой поток.
Надеюсь, не слишком коряво написал.
А где про это можно подробнее почитать\посмотреть ?
@@avikbox ютуб не даёт ссылки вставлять в комменты. Про память - на kernel орг есть дока по vmallocated. Про горутины можно у Дейва Чейни (Dave Cheney) почитать, и вообще много что у него почтитать можно по go)
@@antonioalejos1221 спасибо!
Владимир, спасибо тебе большое что делишся знаниями в доступном для понимания виде ❤
Спасибо!
Владимир, спасибо. Лучшее объяснение по теме. Многие вещи знал, но не до конца понимал, а сейчас кааак понял. Все-таки сторителлинги решают. Еще раз спасибо за труд.
думал это будет приватный урок для тех, кто зарегался. но время есть не у всех. респект за аплоуд на ютуб!
Большое спасибо за видео, отличная подача материала!
Спасибо!
Спасибо большое за видео
Не за что!
Спасибо большое!
Не за что!
Прекрасная лекция. Пожалуй, что стоило еще хотя бы в пару предложений упомянуть, как этот планировщик (вместе с планировщиком памяти) начинают страдать, когда нужен интероп (например с C). Впрочем, похожие страдания возникают у всех языков с богатым рантаймом (Python, Java/JRE, C#/dotnet, JS/V8 и других). Отдельная забава, когда в одном процессе хочется иметь более одного такого рантайма.
Несовсем остался понятен момент с откреплением потока при системном вызове. В итоге по факту как работает?
1. Поток открепляется от процессора и переходи в тред пул? Тогда получается для этого процессора будет создан новый поток? У него же есть еще другие горутины
2. Поток не открепляется, а существует тред потоков, которые выполняют системные вызовы. Мы передаем выполнение кода этой горутины треду в тред пуле.
Какой из вариантов корректный? В лекции эта часть сумбурно рассказана
Противоречие.
Вопрос по 40:45, выполнившаяся горутина идет в lifo и вытесняет прежную lifo горутину в fifo или же в выполнение?
В первый раз сказал первое, во второй раз второе.
Владимир спасибо большое за урок !!! Но вот я не могу понять что на собесе я говорю что в планировщике преимущественно все таки кооперативная много задачность , но теперь и есть вытеснение, но мне говорят что я не прав , что сейчас планировщик преимущественно реализует вытеснение, что это было переделано в последних версиях го , буду благодарен за Ваш ответ 🙏🏻
Добрый день, спасибо за лекцию) Есть вопрос: получается в модели "GMP", "М" это не абстракция, а прям конкретный тред ОС?
вольный пересказ книги Learn Concurrent Programming with Go
Так это общедоступная технология, тут особо не напридумываешь) Ваш референс - это тоже вольный пересказ комментариев разработчиков к коду
Какие-какие в нагрузки в web-приложениях? /sarcasm
А вообще, материал интересный, спасибо!)
Поправьте правильно ли я понял: если приложение получает очень много ввода-вывода заведомо долгих операций (к примеру 1000)-> скедулер создаёт ос тред в котором крутится еполл на 1000 сокетов, вместо создания кучи ос тредов на тред пуле? Вот этот момент не до конца понял, объясните пожалуйста
Получается максимум может быть 256 горутин на один поток, тогда горутины ограничены количеством потоков * 256? Мой ноут начинает умирать при +-30к потоках, тогда максимум я смогу создать +-7,5млн горутин?
Память закончится раньше вероятно :)
Если делать шардирование, как в видео, то нет смысла использовать больше потоков, чем ядер на цпу, плюс поток на обработку сискола, если делать больше потоков, они начнут голодать
Минут 10 уже не понимаю что происходит)
Очень много понятия "контекст", но не дано определения, что это такое. А в го контекст - это вообще канал из пакета. Это такое же же или другое? Переключение контекстов медленное "потому что ядро". А других местах линупса это наоборот - аргумент того, что хорошо(какой-нибудь драйвер). А медленно - это насколько медленно?
И опять таки, линупс - прекраснейшее ядро. Неужели мы сейчас на коленке сделаем контекст свитчинг и быстрее и лучше чем там? В общем, не хватает конкретики в этой истории с конткстом.
коммент для продвижения канала и контента
вообще, офигеть как информативное видео! охренеть
спасибо
костыли на костылях какие-то)
Так говоришь, как будто на с/с++ многопоточности невозможно писать высоконагруженные системы. Всё на тредпулах, везде поток на соединение, везде всё работает прекрасно, никто в tcp очередях не ждёт. Руки прямые просто нужны.
Это работает, но работает не так эффективно по сравнению с той моделью, которую я предложил - причины в видео были объяснены