Горутины создаются и управляются рантаймом Go, а не операционной системой, что позволяет минимизировать накладные расходы.
Уточняйте в чём минимизировать. Так можно сказать и про потоки.
Размер начального стека обычно 1 МБ (или больше, в зависимости от ОС).
Размер начально стека - размер страницы, а это обычно 4/16 КБ
Сравнение горутин с потоками в других языках в таблице
Почему нет сравнения тогда с async/await C++/Rust ?
Можно запустить сотни тысяч горутин на одном сервере без существенных затрат памяти.
Если мы говорим про Go, то на практике как раз наоборот.
Переключение между горутинами выполняется рантаймом Go и гораздо быстрее, чем переключение системных потоков.
Опять без дополнительного контекста. Так можно сказать что это дополнительный оверхед - у нас всё-равно есть шедулер системных потоков, и теперь к нему добавляется шедулер горутин.
Начальный стек небольшой (2 КБ) и растет по мере необходимости, что экономит память.
Выше уже написал, привет виртуальная память.
Таблица аналогов каналов в разных языках
1) Что в таблице означает "Асинхронность" и "Интеграция с корутинами"?
Ключевые особенности каналов в go
Так а где ключевые особенности? Это стандартные свойства каналов.
Каналы помогают избежать гонок данных.
Каким образом?
Простота дизайна. Конкурентные задачи организуются через ясную модель.
Простота дизайна - акторы, каналы + горутины - это сложность.
Горутины и каналы — мощные инструменты, делающие Go одним из лучших языков для конкурентного программирования.
Если размер стека выбран слишком большим, пользователь может не использовать всю выделенную память, тратя ресурсы впустую.
Динамическое изменение размера позволяет экономнее распределять ресурсы системы
Размер в любом случае буде кратный размеру страницу. Так что обычно никакой разницы по памяти вообще не будет. Единственный минус в первом варианте - возможное, пугающее значение использование виртуальной памяти.
Если корутины практически не используют стек, то в таком случае используется 1 стек на пачку корутин.
В целом разница между Stackful/Stackless вообще не связана с использованием памяти т.к. stackful реализуется через mmap
На айпадах с м чипами идёт Virtualization.framework, так что установив дополнительно линукс можно закрыть специфические задачи под которые нужна производительность.
Последний пункт особенно важен. Почему? А потому что OpenBLAS - это монстр, состоящий из ассемблерного кода, который годами оптимизировали красноглазые гении в подвалах под каждую существующую микроархитектуру Intel, в то время как программа на Mojo - это пара сотен строк условно-платформонезависимого питоноподобного кода, что очень впечатляет.
А кто тогда MKL оптимизировал? Он то побыстрей будет.
Плюс OpenBLAS в том, что вендор его может замокать (например как это делает Apple).
Мы говорим про zero-cost, это означает что для оптимизатора не должно быть разницы использовали ли мы абстракцию или нет.
При чём тут ускорение при добавление вызова .len() если разговор идёт об информации которая есть у оптимизатора (на проходах в которых она нужна) при использовании абстракций?
Например len не особо юзается в стандартной библиотеке, а вместо неё используется макрос, т.к. в определённых кейсах оптимизатор не может доказать что 2 вызова len ссылаются на одно значение.
В плане ускорения, конечно итераторы в расте могут быть быстрей чем пользовательский код, т.к. проблемы оптимизатора компенсируются вызовом `assume`, у другими механиками. Но речь немного о другом.
Объясните минуса? Я вот могу показать примеры, например, с банальным вызовом `.len()` из-за которого отключаются определённые оптимизации. Или же написать примеры кода, в котором на выходе из-за использования функций падение в производительности в 10+ раз.
zero-cost abstractions это маркетинг, он невозможен из-за природы работы оптимизатора.
Я вот проверил, у меня на макбуке минимальный WPM 96, на более простом для чтения тексте(10 слов) минимальный ровно 100 (410 CPM). И я не уверен что получу больше если возьму другую клавиатуру (чисто из-за удобства и привычки).
Но вот если начну тренироваться как Вы, то уверен что эффект будет (хотя бы из-за того что начну все пальцы использовать).
Тупейшая статья сгенерированная ChatGPT.
Уточняйте в чём минимизировать. Так можно сказать и про потоки.
Размер начально стека - размер страницы, а это обычно 4/16 КБ
Почему нет сравнения тогда с async/await C++/Rust ?
Если мы говорим про Go, то на практике как раз наоборот.
Опять без дополнительного контекста. Так можно сказать что это дополнительный оверхед - у нас всё-равно есть шедулер системных потоков, и теперь к нему добавляется шедулер горутин.
Выше уже написал, привет виртуальная память.
1) Что в таблице означает "Асинхронность" и "Интеграция с корутинами"?
Так а где ключевые особенности? Это стандартные свойства каналов.
Каким образом?
Простота дизайна - акторы, каналы + горутины - это сложность.
Вообще нет.
Размер в любом случае буде кратный размеру страницу. Так что обычно никакой разницы по памяти вообще не будет. Единственный минус в первом варианте - возможное, пугающее значение использование виртуальной памяти.
Если корутины практически не используют стек, то в таком случае используется 1 стек на пачку корутин.
В целом разница между Stackful/Stackless вообще не связана с использованием памяти т.к. stackful реализуется через mmap
кнопка больше для полного отключения/перезагрузки. При подключении через type-c режим спокойно управляется отключением/включением монитора
а на деле - и vm и скомпилить и докер запустить.
На айпадах с м чипами идёт Virtualization.framework, так что установив дополнительно линукс можно закрыть специфические задачи под которые нужна производительность.
может он говорит про условие `if (spawnAtTheLeftEdge)`
его можно заменить на
```
sign = spawnAtTheLeftEdge - 1 | 1
```
и в тело добавить умножение на sign, это уберет условие.
А кто тогда MKL оптимизировал? Он то побыстрей будет.
Плюс OpenBLAS в том, что вендор его может замокать (например как это делает Apple).
Так что пока, Mojo смешно смотрится.
Мы говорим про zero-cost, это означает что для оптимизатора не должно быть разницы использовали ли мы абстракцию или нет.
При чём тут ускорение при добавление вызова
.len()если разговор идёт об информации которая есть у оптимизатора (на проходах в которых она нужна) при использовании абстракций?Например
lenне особо юзается в стандартной библиотеке, а вместо неё используется макрос, т.к. в определённых кейсах оптимизатор не может доказать что 2 вызоваlenссылаются на одно значение.В плане ускорения, конечно итераторы в расте могут быть быстрей чем пользовательский код, т.к. проблемы оптимизатора компенсируются вызовом `assume`, у другими механиками. Но речь немного о другом.
Объясните минуса? Я вот могу показать примеры, например, с банальным вызовом `.len()` из-за которого отключаются определённые оптимизации. Или же написать примеры кода, в котором на выходе из-за использования функций падение в производительности в 10+ раз.
zero-cost abstractions это маркетинг, он невозможен из-за природы работы оптимизатора.
Так какой в итоге профит получили?
Я вот проверил, у меня на макбуке минимальный WPM 96, на более простом для чтения тексте(10 слов) минимальный ровно 100 (410 CPM). И я не уверен что получу больше если возьму другую клавиатуру (чисто из-за удобства и привычки).
Но вот если начну тренироваться как Вы, то уверен что эффект будет (хотя бы из-за того что начну все пальцы использовать).
Получается что клавиатура не играет роли?
Т.е. везде? Вызов функции не гарантирует сохранения и обработку всех инвариантов.
Хотите zero-cost - юзайте макросы (кстате, в стандартной библиотеке так и поступают)