2016-10-13 2 views
0

Я пытался использовать параллелизацию для запуска некоторых симуляций с помощью программного обеспечения моделирования MEEP немного быстрее. По умолчанию программное обеспечение использует только один процессор, а симуляции FDTD легко ускоряются путем распараллеливания. В конце концов я обнаружил, что нет никакой разницы между запуском 1 или 4 ядер, время моделирования было одинаковым.Непрерывное параллельное выполнение, без ускорения (MEEP, openMPI)

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

Удивительно то, что когда я начинаю новую симуляцию, уже начатые имитации замедлятся, хотя они работают на отдельных ядрах. Например, если я запускаю только 1 симуляцию на 1 ядро, каждый временной шаг моделирования FDTD занимает около 0,01 секунды. Если я начну другой процесс на другом ядре, каждая симуляция теперь будет тратить 0,02 секунды на шаг времени и так далее, что означает, что даже когда я запускаю разные симуляции, которые не имеют ничего общего друг с другом на отдельных ядрах, все они замедляются, чистое увеличение скорости.

Я не обязательно ищу помощь в решении этой проблемы, так как я ищу ее, чтобы понять ее, потому что она достигла своего любопытства. Каждый экземпляр моделирования требует менее 1% от моей общей памяти, поэтому это не проблема памяти. Единственное, о чем я могу думать, это то, что ядра, использующие кеш-память, или насыщенность полосы пропускания памяти, есть ли способ проверить, так ли это?

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

Любые советы, которые помогут мне понять это явление?

+0

Вы должны использовать соответствующий инструмент для чтения счетчиков производительности оборудования, которые могут указывать на общие ресурсы как узкое место.Существует много [параллельных] (https://stackoverflow.com/questions/10607750/tools-to-measure-mpi-communication-costs/10608276) [tools] (https://stackoverflow.com/questions/18191635/good -profiler-для-Fortran-и-MPI/18205748). Но если вы просто запускаете приложения отдельно, вы можете использовать что-то простое, например [perf] (https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record). – Zulan

+1

Ваш анализ - хороший старт, но есть и другие возможные проблемы: уменьшенная частота турбонаддува, гиперпотоки/модули bulldozer AMD, но без более конкретной информации о системе и приложении невозможно сообщить – Zulan

+0

, какая длина данных? 100 МБ? попытайтесь заставить все ядра работать только с частью 1 Мб, а затем, когда закончите, продолжайте в другой части. Таким образом, когда ядро ​​доступа к ячейке, другое ядро ​​может обращаться к нему как к соседству с другой ячейкой. –

ответ

0

Я думаю, что лучше смотреть на симуляции, потому что хорошо известная проблема с технологией turbo boost, как технология (изменение производительности одного ядра с количеством потоков) не может объяснить ваш результат. Это объяснит, если у вас есть один основной процессор.

Итак, я думаю, что это можно объяснить с помощью уровней кэша памяти. Возможно, если вы попробуете симуляции намного больше, чем L3 Cache (> 8 МБ для i7).

0

МОЙ тест на процессоре Intel (R) Core i7-3517U с процессором 1,90 ГГц с двойным сердечником (4 резьбы). Все расчеты за 1 МПИ нити (-np 1)

10mb моделирования:

  • Четыре моделирования 0,0255 s/шаг
  • Два моделирования 0.0145 s/шаг
  • Один моделирования 0,0129 с/шаг

    100mb моделирования:

  • Четыре моделирования 1,13 с/шаг

  • Два моделирования 0,61 s/шаг
  • Один имитационные 0,53 s/шаг

Любопытно то, что два моделирования с 2 нитями каждый прогон почти с такой же скоростью, как два моделирования с 1 нитью.