Обновить

Память в GoOS, часть 2. Нативные потоки, горутины и GC на SMP

Уровень сложностиСложный
Время на прочтение17 мин
Охват и читатели5.5K
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Комментарии 2

Вот я и добрался до второй части статьи! Признаюсь, пришлось три раза перечитывать, так как я терял нить, складывается впечатление перескакивания с темы на тему. Повторюсь, может для специалистов нормой миксовать горутины и тут же FPU/SSE.

Как и в первой части мне нехватает сравнений с чем-то уже распространенным. Тема многопоточности занимает меня с давних времен и чуть отстраненно я реализовывал многопоточный парсер файла, конечно не задумываясь, что там в потрохах операционной системы происходит. Однако, вот к чему я пришёл - на коротких дистанциях - файл в несколько гигабайт однопоточная загрузка была быстрее. На длинных дистанциях - файл десятки гигабайт, многопоточный выигрывал. Не сразу, а где-то на полпути.

Тогда я сформулировал это так - однопоточный "устаёт", в то время как многопоточный - марафонец. Вероятно это как-то связано с работой с памятью. В качестве "крутилки" я использовал количество потоков n. И довольно быстро уперся в производительность ноутбука разработки. Есть ли у вас реальные варианты, где ваш вариант многопоточности мог бы применится, встречали ли такую проблему в современных ОС?

Очень интересно узнать как действует разграничение/высвобождение памяти процессами под нагрузкой.

Возможно да, получился слегка (самую малость) неудобный текст. Для меня это просто одна цепочка причин и следствий, но со стороны действительно может выглядеть как скачок между темами. Вообще XMM там появился не ради отдельной низкоуровневой темы, а потому что без корректного сохранения этих регистров preemption ломал обычный Го-код. Наверное, стоило сильнее проговорить этот переход. А что касается остального… Да, это нормальная картина, на короткой задаче многопоточность легко проигрывает из-за накладных расходов на потоки, синхронизацию и кэши. В долгосроке эти расходы уже размазываются, и параллельность начинает уже окупаться. Я поэтому тоже не пытаюсь распараллеливать всё подряд. Например, в VFS параллельно идут только независимые чтения, а операции, где важен порядок, проходят через барьеры. С памятью тоже похожая история. Локальные slab-кэши уже сильно лучше одной общей блокировки, но GC и общая куча пока всё равно ограничивают масштабирование. Я в этом плане уже произвожу некоторые оптимизации, изыскания, процесс не очень быстрый

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации