Причина непроизвольного переключения контекста

Вы упомянули, что существует 32 ядра, но какова точная компоновка оборудования? Например. сколько пакетов у машины, сколько ядер, как распределяется кеш и т. д. Для обмена такой информацией лично мне нравится делиться выводом likwid-topology -g.

В любом случае, в вашем прогоне есть один элемент недетерминизма: сходство потоков. Операционная система назначает потоки SW для работы в определенных потоках HW каким-то образом, не принимая во внимание знания о том, как потоки взаимодействуют (просто потому, что у него нет этих знаний). Это может вызвать всевозможные эффекты, поэтому для воспроизводимых прогонов рекомендуется каким-то образом закрепить потоки SW к потокам HW (может быть и оптимальный способ, но пока что я я как раз про детерминизм).

Для закрепления (также известного как affinity) вы можете использовать явные вызовы Pthread или попробовать другой инструмент из пакета Likwid под названием likwid-pin - см. здесь.

Если это не дает стабильных результатов, запустите хороший профилировщик (например, Intel VTune) для своей рабочей нагрузки, убедившись, что вы фиксируете более быстрый запуск и более медленный запуск, а затем сравните результаты. В VTune вы можете использовать функцию сравнения, которая показывает два профиля рядом.

Я считаю, что ваша проблема связана с расписанием.

Нельзя избежать вытеснения одного процесса из ЦП, но проблема в том, что если поток вытесняется, а затем на его следующем кванте оказывается на другом ЦП, или, если быть более конкретным, на ЦП с другим L2 cache, то все обращения к памяти приведут к промахам кеша и вызову выборки данных из памяти. С другой стороны, если поток планируется на одном и том же процессоре, вполне вероятно, что его данные будут по-прежнему доступны на cahce, например, обеспечивая гораздо более быстрый доступ к памяти.

Обратите внимание, что такое поведение, скорее всего, произойдет, когда у вас будет все больше и больше ядер. И поскольку это своего рода «случайность», когда ваш поток завершится на следующем такте, то это объясняет случайность производительности.

Существуют инструменты профилирования, которые позволяют вам регистрировать, где запланированы ваши потоки, например perf для Linux. Обычно эти инструменты относятся к топологии, в которой вы выполняете свою программу. К сожалению, сейчас мне в голову не приходит ничего другого. Есть также способы указать ОС, чтобы она планировала потоки на одних и тех же (или соседних) процессорах, чтобы они выиграли от меньшего количества промахов в кеше. Для этого вы можете проверить этот вопрос SO

Я бы посоветовал вам спросить своего администратора, с какими инструментами вы можете рассчитывать, чтобы вы могли правильно профилировать и назначать свое планирование потоков.

Вы упоминаете о двухмодальном профиле производительности, который вы видите на одной машине, а не на другой. Ужасно, но это нормально даже для однопоточных приложений.

Проблема в том, что в системе Linux (любое ядро, независимо от используемого планировщика) слишком много факторов, влияющих на производительность приложения. Он начинается с рандомизации адресов и заканчивается микроскопическими различиями во времени, которые перерастают в огромные задержки переключения контекста между процессами.

Linux - это не система реального времени. Он просто пытается быть максимально эффективным в среднем случае.

Чтобы свести к минимуму разницу в производительности, вы можете сделать несколько вещей:

Уменьшите количество потоков до минимально необходимого. Не разбивайте различные аспекты вашей проблемы на темы. Просто разбейте их на потоки, когда это действительно необходимо, например, чтобы накормить ЦП независимыми (!) Заданиями по вычислению чисел. Постарайтесь выполнить как можно больше причинно-следственной работы в одном потоке. Вы должны как можно реже общаться друг с другом. В частности, у вас не должно быть шаблонов запроса / ответа между потоками, в которых складываются задержки.

Предположим, ваша ОС может выполнять только около 1000 переключений контекста между потоками / процессами в секунду. Это означает пару 100 транзакций запроса / ответа в секунду. Если вы проводите тест в Linux и обнаруживаете, что можете сделать гораздо больше, не обращайте на это внимания.

Постарайтесь уменьшить объем памяти, занимаемый жизненно важными данными. Распределенные данные имеют тенденцию уничтожать кеш с очень тонким и труднообъяснимым влиянием на производительность.

Вы можете отслеживать источник переключения контекста в ядре, используя ftrace (используя трассировщик sched_switch). Кроме того, использование perf может помочь вам сузить круг других показателей (промахи в кэше, и т.д.).

Как изменяется изменчивость производительности при увеличении вашей программы с 1 потока до 32 (и, возможно, выше)?

Может быть, ваша программа имеет общие данные (или какой-либо другой ресурс), за которые борются отдельные потоки? Таким образом, они испытывают состояние гонки, которое усиливается при большем количестве параллельного выполнения (отсюда и переменная производительность)? За какие ресурсы помимо процессорного времени борются потоки вашей программы?

Я думаю, вам придется скомпилировать старое ядро ​​на своей 4-ядерной машине. Это было бы не только хорошим учебным упражнением, если вы еще не сделали этого, но и полезным для выделения переменных в этой задаче. Если бы вы сделали это, я бы также попытался сопоставить точный дистрибутив, поскольку ваша проблема может быть ограничена не только ядром. Это также может быть что-то в пользовательском пространстве или, возможно, просто в параметрах компиляции для ядра (которые, следовательно, будут соответствовать в том же выпуске дистрибутива).

Вы можете изучить возможность использования профилировщика, такого как gprof. Это может дать вам представление о (потенциальном) узком месте. Например, если вы ждете системного вызова write или чего-то подобного.

Вот несколько статей, которые могут помочь вызвать идею или две:

http://halobates.de/lk09-scalability.pdf

http://pdos.csail.mit.edu/papers/linux:osdi10.pdf

Дополнительный источник: Почему одно недобровольное переключение контекста в секунду?

В многопоточной программе прикрепите поток к определенному номеру ЦП и проверьте, заметили ли вы улучшение производительности.

Когда дело доходит до изменения расписания, лучше всего использовать профилировщик ядра / регистратор Ftrace. Это должно показать вам, какие потоки вытесняются другими потоками. К сожалению, обработчики прерываний в нижней половине не имеют должной маркировки, поэтому их может быть сложно расшифровать.