Сообщение Re[3]: Горутины и потоки от 28.11.2021 18:35
Изменено 29.11.2021 8:37 gandjustas
Re[3]: Горутины и потоки
Здравствуйте, fk0, Вы писали:
fk0>Здравствуйте, gandjustas, Вы писали:
T>>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
G>>1) Переключение контекста не бесплатное
fk0> А у Go -- бесплатное?
Гораздо более дешевое, чем в ОС, примерно на два десятичных порядка.
G>>2) Каждый поток кушает 1МБ под стек минимум
fk0> Адресного пространства, а не стека. Памяти на стек тратится, минимум, килобайт 8 думаю.
Сколько реально тратится — зависит от того как написан код. Может оказаться довольно много в сумме.
Когда еще не было async\await в C# я переписал один сервер с использования потока на соединение на асинхронные вызовы и очередь. Получил экономию около 200мб, что составляло четверть расходуемой памяти.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
fk0> Можно подумать, Go знает. Часто этого и сам поток не знает.
Конечно знает. Я не знаю как точно в Go это устроено, но компилятор прекрасно определяет какие перменные нужны в продолжении.
G>>В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
fk0> В Linux тоже make_context и switch_context были с доисторических времён. Когда ещё потоков наверное не было.
Это типа cooperative multitasking? Увы в рукопашную его нигде практически не используют.
fk0>Здравствуйте, gandjustas, Вы писали:
T>>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
G>>1) Переключение контекста не бесплатное
fk0> А у Go -- бесплатное?
Гораздо более дешевое, чем в ОС, примерно на два десятичных порядка.
G>>2) Каждый поток кушает 1МБ под стек минимум
fk0> Адресного пространства, а не стека. Памяти на стек тратится, минимум, килобайт 8 думаю.
Сколько реально тратится — зависит от того как написан код. Может оказаться довольно много в сумме.
Когда еще не было async\await в C# я переписал один сервер с использования потока на соединение на асинхронные вызовы и очередь. Получил экономию около 200мб, что составляло четверть расходуемой памяти.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
fk0> Можно подумать, Go знает. Часто этого и сам поток не знает.
Конечно знает. Я не знаю как точно в Go это устроено, но компилятор прекрасно определяет какие перменные нужны в продолжении.
G>>В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
fk0> В Linux тоже make_context и switch_context были с доисторических времён. Когда ещё потоков наверное не было.
Это типа cooperative multitasking? Увы в рукопашную его нигде практически не используют.
Re[3]: Горутины и потоки
Здравствуйте, fk0, Вы писали:
fk0>Здравствуйте, gandjustas, Вы писали:
T>>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
G>>1) Переключение контекста не бесплатное
fk0> А у Go -- бесплатное?
Гораздо более дешевое, чем в ОС, примерно на два десятичных порядка.
G>>2) Каждый поток кушает 1МБ под стек минимум
fk0> Адресного пространства, а не стека. Памяти на стек тратится, минимум, килобайт 8 думаю.
Сколько реально тратится — зависит от того как написан код. Может оказаться довольно много в сумме.
Когда еще не было async\await в C# я переписал один сервер с использования потока на соединение на асинхронные вызовы и очередь. Получил экономию около 200мб, что составляло четверть расходуемой памяти.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
fk0> Можно подумать, Go знает. Часто этого и сам поток не знает.
Конечно знает. Я не знаю как точно в Go это устроено, но компилятор C# прекрасно определяет какие перменные нужны в продолжении.
G>>В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
fk0> В Linux тоже make_context и switch_context были с доисторических времён. Когда ещё потоков наверное не было.
Это типа cooperative multitasking? Увы в рукопашную его нигде практически не используют.
fk0>Здравствуйте, gandjustas, Вы писали:
T>>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
G>>1) Переключение контекста не бесплатное
fk0> А у Go -- бесплатное?
Гораздо более дешевое, чем в ОС, примерно на два десятичных порядка.
G>>2) Каждый поток кушает 1МБ под стек минимум
fk0> Адресного пространства, а не стека. Памяти на стек тратится, минимум, килобайт 8 думаю.
Сколько реально тратится — зависит от того как написан код. Может оказаться довольно много в сумме.
Когда еще не было async\await в C# я переписал один сервер с использования потока на соединение на асинхронные вызовы и очередь. Получил экономию около 200мб, что составляло четверть расходуемой памяти.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
fk0> Можно подумать, Go знает. Часто этого и сам поток не знает.
Конечно знает. Я не знаю как точно в Go это устроено, но компилятор C# прекрасно определяет какие перменные нужны в продолжении.
G>>В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
fk0> В Linux тоже make_context и switch_context были с доисторических времён. Когда ещё потоков наверное не было.
Это типа cooperative multitasking? Увы в рукопашную его нигде практически не используют.