Как выполнить надежные тесты производительности в параллельной архитектуре?

Question

Я разрабатываю структуры данных и алгоритмы в области вычислительной геометрии. Для меня очень важно иметь возможность достоверно сравнить время работы двух алгоритмов.

Проблема в том, что когда я запускаю алгоритм и работает в течение 30 минут, я не могу сказать, что эти 30 минут были потрачены на выполнение алгоритма, а не на воспроизведение mp3.

У меня есть процессор Intel® Core ™ i7-2600 с процессором процессора 3,40 ГГц × 8 с Ubuntu 13.04. Все мои программы написаны на C++ и используют только библиотеки, написанные на C или C++.

1. Означает ли это, что я могу спокойно работать, скажем, 6 экспериментов параллельно, в то время как операционная система будет использовать другой 2 для своего бизнеса?

2. Должен ли я запускать эксперименты как 6 нитей одной программы или делать 6 разных исполняемых файлов и запускать их?

3. В чем разница между этими двумя подходами?

Answer 1

Если вы хотите согласующиеся результаты, работает один тест в то время, улучшит шансы - потому что разные задачи, скорее всего:

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

Если вы используете контрольный образец одновременно с воспроизведением MP3-файлов, загрузкой полнофункциональных фильмов с блокбастерами и т. Д., То вы не будете знать, действительно ли это мешает (или насколько мешает ему) ваш процессор интенсивные задачи - вы можете, возможно, сказать наоборот, если музыка начинает становиться изменчивой или время загрузки ...;) Как и при одновременном запуске нескольких задач, кеш и переход от процессора к ядру процессора будут наиболее важные эффекты.

Вы можете обнаружить, что если вы запустите один набор тестов «со всем на» и еще один набор тестов «со всем выключенным», это не имеет значения. Но вы также можете обнаружить, что это действительно имеет значение.

То же самое относится к запуску одного или нескольких эталонных тестов. Попробуйте запустить 6 параллельно и сравните время, которое каждый сам тест выполняет, когда запускается ничем иным.

Вы знаете только это, сравнивая различные случаи.

Если нет никакой разницы, вы можете продолжать играть музыку, загружать последнюю версию блокбастера и т. Д. Во время бенчмаркинга, потому что вы знаете, что разница в 0,01% не важна для общей производительности приложения.

Из опыта я обнаружил, что обычно это не имеет большого значения, если вы запускаете множество других «легких» вещей в фоновом режиме, но это увеличит количество вариаций от одного прогона к другому ,Опять же, если эталонная программа работает в течение получаса, это может и не иметь значения. В конце концов, вы, вероятно, будете иметь достаточно вариаций в этой среде выполнения от одного запуска к другому, просто из общих вещей, которые различаются в CPU и в ОС, чисто «вещи не происходят ТОЧНО одинаково каждый раз», то это не будет иметь достаточных различий.

Если вы делаете небольшие оптимизации, например, переключаете параметры компилятора, которые дают 0,5% -ную разницу в результатах, но разница между прогонами составляет 1%, тогда вам нужно запустить несколько прогонов, чтобы показать фактическую разницу, и тем больше вмешательства других процессов, тем больше шансов, что вы не сможете измерить небольшие изменения. Иногда многие небольшие изменения могут заметно различаться (например, если вы переместите функцию F1, чтобы она была встроена, а затем сделать то же самое с функцией F2, вместе они составляют 1% улучшения, но индивидуально она не поддавалась измерению , потому что он был скрыт в шуме). Чем больше шум, тем больше вероятность того, что вы «пропустите» некоторые небольшие, но в конечном итоге полезные изменения.

Answer 2

Прежде всего: Intel i7-2600 имеет 4 "истинных" ядра, но каждое ядро ​​может параллельно запускать два потока. Эта «гиперпоточность» быстрее, чем традиционная потоковая передача с помощью превентивного решения OS-планировщика. Поскольку выполнение может продолжаться в другом потоке, если один поток должен ждать короткое время (например, при чтении значения из основной памяти после промаха в кеше), гиперпоточность имеет тенденцию к увеличению пропускной способности. Таким образом, совместная производительность двух процессов, работающих на гиперпрочленном ядре, обычно на 10-20% выше, чем производительность одного процесса, работающего на одном и том же ядре. В случае повышенного давления в кэш, комбинированные характеристики могут быть хуже.

Но, что более важно для удовлетворения потребностей в производительности: если два потока на одном сердечнике имеют общую производительность 120%, это означает, что производительность одного потока падает до 60%!

Насколько я знаю, планировщик ядра Linux знает об гиперпотоке, поэтому он попытается сохранить второй поток на каждом ядре бездействия, если первый поток выполняет тяжелую работу, и если есть все еще доступные ядра , Итак, если вы запускаете только 3 процесса синхронизации параллельно и оставляете одно ядро ​​для своего рабочего стола и не выполняете большую работу на стороне (например, компиляцию и т. Д.), Тогда вы должны получить довольно согласованные данные синхронизации! Если вы запускаете 4 процесса, убедитесь, что рабочий стол действительно не работает. Если вы начинаете 5 процессов и более, ожидайте несогласованные результаты синхронизации из-за гиперпотока.

Если вы используете время на оболочке для выполнения своих команд, сообщаемое пользовательское и системное время имеют тенденцию быть более точными, чем общее время. Это связано с тем, что ОС подсчитывает как пользовательское, так и системное время только то время, что процесс фактически выполнялся в пользовательской области или в системе, соответственно. Если ваш код не делает много ввода-вывода, системное время должно быть низким, а время пользователя должно быть близко к общему времени работы.