Распараллеливание программы (ядра/потоки)

Dmitriy40 · 08.01.2020, 18:36

Для начала неплохо бы убедиться что проблема в этом (и только в этом).
Потом заполнить ind[] значениями подряд и убедиться что время остаётся стабильным.
И только после выполнения всех этих условий — плюнуть. Если нельзя отказаться от косвенной адресации.
Хотя можно проверить мысль заключить этот цикл копирования в критическую секцию, вдруг это упорядочит запросы в память и ускорит выполнение, несмотря даже на ожидание остальных потоков.

Andrey_Kireew · 08.01.2020, 19:30

Сделал так

Код:

for (i=0; i<R; i++) buf[i]=M[i];

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

Получается, что есть какая то общая причина, а нестабильное время чтения данных - это лишь её следствие. Самое главное, ведь иногда работает отлично, а иногда в 2 раза дольше. И данные одни и те же, и алгоритм ...

Но вообще замечено, что при первом включении, всё работает очень медленно, почти как на 1-2 ядрах. Но потом, после множества запусков, как то разрабатывается, и становится более-менее нормально. Хотя, возможно, это лишь случайное совпадение

Dmitriy40 · 08.01.2020, 23:36

Andrey_Kireew в сообщении #1434016 писал(а):

время выполнения циклов чтения стало даже ещё нестабильнее.

У меня идеи кончились.

Andrey_Kireew в сообщении #1434016 писал(а):

Самое главное, ведь иногда работает отлично, а иногда в 2 раза дольше. И данные одни и те же, и алгоритм ...

А окружение разное. И порядок выполнения команд в разных потоках тоже может быть разным. Отсюда и возможность разного времени. Но вот что конкретно влияет на разброс времени мне так и непонятно. Вообще не представляю что может так влиять на время выполнения трёхпоточного кода с 180К readonly данных на четырёхядерном процессоре при загрузке последнего на 75%.
Комментируйте строки по одной с конца и ищите когда время станет стабильным. Что ещё сказать ...

А потом оставляя последнюю строку, и вызывающую проблемы, удаляйте всё прочее пора проблема остаётся, и получив минимальный работающий пример с проблемой, показывайте, будем думать конкретно.

Andrey_Kireew в сообщении #1434016 писал(а):

Но потом, после множества запусков, как то разрабатывается, и становится более-менее нормально.

Такой эффект возможен если читаются большие файлы, при запуске или в процессе работы, и диск не SSD — винда оптимизирует порядок чтения файлов (prefetcher), но кажется это не происходит не сразу, а спустя дни. Это явно не ваш вариант.

Andrey_Kireew · 09.01.2020, 00:30

В общем, надо всё обмозговать

Mihaylo · 09.01.2020, 18:40

Сделайте фиксированные одинаковые входные данные для всех потоков, вдруг, где косяк в обработке.

Andrey_Kireew · 14.01.2020, 19:02

Mihaylo в сообщении #1434151 писал(а):

Сделайте фиксированные одинаковые входные данные для всех потоков

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

Так же пробовал привязывать потоки к ядрам, но это ничего хорошего не даёт.

Mihaylo · 15.01.2020, 07:47

Andrey_Kireew в сообщении #1435176 писал(а):

Вот только что из этого следует понять не могу.

Отсюда следует, что ядра-потоки-конвейера не мешают друг другу. Это сам алгоритм "запинается" о данные.
Попробуйте продолжить эксперимент, подобрав данные, которые сильно замедляют все потоки, потом попробуйте проанализировать и найти узкое горлышко.

Andrey_Kireew · 15.01.2020, 21:15

Будучи в полном отчаянии, я решил прибегнуть к крайним мерам - заменить динамически выделяемые массивы внутри потоковой функции простыми массивами фиксированных размеров. Как ни странно, но проблема исчезла. Запускал уже много раз - время выполнения потоков однообразное, различается от случая к случаю примерно на 1%. Как Вы думаете Dmitriy40, с чем это может быть связано? Вообще, подозрения на динамические массивы у меня были с самого начала. Как я их не выделял, и в основном потоке, и внутри потоковых функций ...

mihaild · 15.01.2020, 21:29

Andrey_Kireew, а когда вы запускали во всех потоках одну задачу, вы использовали динамические массивы, и проблемы не было?
Само по себе выделение памяти занимает сколь-нибудь значительное время?

Andrey_Kireew · 15.01.2020, 21:37

mihaild в сообщении #1435386 писал(а):

вы использовали динамические массивы, и проблемы не было?

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

mihaild в сообщении #1435386 писал(а):

Само по себе выделение памяти занимает сколь-нибудь значительное время?

не думаю. Причём, выделение происходит однократно, только в начале потоковой функции, и освобождение происходит перед выходом из неё. В общем всё как обычно, ничего особенного.

-- 15.01.2020, 22:48 --

Вот такие результаты получаются:

mihaild · 15.01.2020, 21:56

Итого если данные во всех потоках одинаковые, аллокация в куче, то всё работает стабильно и быстро. Если данные разные и аллокация на стеке, то тоже стабильно и быстро. Если данные разные и аллокация в куче, то разброд и шатание. Так?

Andrey_Kireew · 15.01.2020, 22:03

mihaild в сообщении #1435390 писал(а):

Так?

Может и так, Вам виднее, я в этом не спец ...
но хотелось бы узнать почему такое происходит?

mihaild · 15.01.2020, 22:25

Andrey_Kireew в сообщении #1435391 писал(а):

Может и так, Вам виднее

Это же вопрос к вам - у вас экспериментальные данные. Я просто попробовал собрать эти результаты в одном месте, чтобы прежде чем про них думать убедиться что всё понял правильно.

Andrey_Kireew · 15.01.2020, 22:31

Если простые массивы обитают на стёке - то значит так
к стати, сама скорость выполнения от этого не меняется, т.е. если без "глюков" то и с динамическими массивами поток выполняется примерно за 95 сек

-- 15.01.2020, 23:38 --

Ещё важный нюанс, как Выmihaild наверное понимаете, статический массив я создал один, и завёл указатели на разные его участки. Так, что получилось - все данные идут подряд и находятся в одном участке памяти.

Ранее, пробовал так же сделать с динамическим массивом - выделить большой кусок памяти, и потом завести указатели на разные участки. Но получилось только хуже, работать стало ещё медленнее чем раньше.

Dmitriy40 · 16.01.2020, 01:15

Andrey_Kireew в сообщении #1435388 писал(а):

или если подать одну и ту же задачу во все потоки,

Объясните нормальным языком что значит фраза "подать одну и ту же задачу" - это просто подать в потоки N одинаковых указателей на одно и то же место массива или скопировать данные N раз и подать разные указатели/массивы (но с одинаковым содержимым) в разные потоки?

mihaild в сообщении #1435390 писал(а):

Так?

Походу так.

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

Научный форум dxdy

Распараллеливание программы (ядра/потоки)