Почему парфор медленный, несмотря на нарезку?

У меня есть простой цикл parfor, приведенный ниже.

% fileAddr is a cell array of (size N) of file-addresses
sIdx = nan(N,1);
eIdx = nan(N,1);
errMsg = cell(N,1);
parfor i=1:N
    [sIdx(i),eIdx(i),errMsg{i}] = myFunk(fileAddr{i});
end

Функциональный файл myFun() загружает файл, заданный fileAddr{i}, выполняет некоторые вычисления и возвращает результаты. Часть загрузки файла занимает больше всего времени. Моя машина имеет 4 физических ядра. Я пробовал parfor() с пулом из 1,2,3 и 4 рабочих. Каждый раз затраты времени примерно одинаковы. Я так понимаю, что если несколько рабочих load()обрабатывают файлы параллельно, программа будет работать быстрее, но результаты профилировщика показывают обратное.

Может кто-нибудь объяснить, где я делаю ошибку?


matlab parfor matlab-load
person Abhinav    schedule 26.07.2018    source источник
comment
parfor() НЕ волшебная палочка, не обращайтесь с ней как таковой. Если загрузка файлов действительно является узким местом этой операции, никакое распараллеливание не поможет вам ускорить код. Жесткие диски и твердотельные накопители имеют конечную скорость чтения, и если вы максимизируете ее, вы не сможете ускориться. Распараллеливание потенциально может помочь вам только тогда, когда узким местом являются вычисления.   -  person Adriaan    schedule 26.07.2018

Ответы (1)


arrow_upward
5
arrow_downward

У вас есть только 1 жесткий диск. Одновременно с него может читать только 1 рабочий (это скоростной диск с магнитной головкой!). Это медленнее, потому что рабочие ждут своей очереди за жестким диском, поэтому вы не выигрываете время. Добавьте к этому все подслушанные сообщения об отправке и обмене данными, и вы сделаете их медленнее.

Пробовали ли вы spmd? Но я подозреваю, что это закончится тем же результатом, что и с parfor.

person Ander Biguri    schedule 26.07.2018
comment
Так что единственный шанс сделать это быстрее - заменить HDD на SSD? - person Abhinav; 26.07.2018
comment
@Abhinav нет, у твердотельных накопителей такое же ограничение. Это будет быстрее, потому что SSD быстрее, а не из-за parfor - person Ander Biguri; 26.07.2018
comment
Нет, я не пробовал `spmd', но полагаю, что его постигнет та же участь, поскольку каждая итерация зависит от другого файла. Хотя я могу попробовать. - person Abhinav; 26.07.2018
comment
@Abhinav да, я подозреваю, что вы столкнетесь с той же проблемой. У вас узкое место при загрузке данных. - person Ander Biguri; 26.07.2018
comment
@Abhinav: поместите файлы на разные физические диски. - person Cris Luengo; 26.07.2018
comment
@CrisLuengo Размещение данных на разных дисках ... хм, хорошее предложение. Данные в настоящее время помещаются на два диска по 4 ТБ. Но имена файлов итератора располагаются последовательно, т. е. сначала все файлы диска-1, а затем все файлы диска-2. Может быть, если я поставлю файлы в альтернативном порядке (файл на диске-1, затем файл на диске-2 и т. д.), тогда он должен получить некоторую экономию. - person Abhinav; 26.07.2018
comment
@AnderBiguri: SSD намного лучше работают с параллельными задачами, чем с вращающимися дисками, потому что им не нужно искать. Для вращающегося диска parfor страдает не только от накладных расходов на синхронизацию потоков (возможно, замедление на 3-5%), но и от времени, затрачиваемого на перемещение физических головок туда и обратно между файлами (возможно, замедление на 30 000-500 000%). SSD не имеют ЭТОГО ограничения (они по-прежнему имеют ограниченную скорость произвольного доступа, но она довольно близка к скорости последовательного доступа). - person Ben Voigt; 26.07.2018
comment
@BenVoigt да, это то, что я имел в виду в комментарии. Быстрее будет из-за SSD, а не из-за парфора. Я предполагаю, что 4 последовательных чтения одинаково быстры, если существует хороший компилятор (JIT или другой). - person Ander Biguri; 26.07.2018