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