параллельная обработка файлов

[Bepec]

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

[kambala]

по-моему всю необходимую информацию я предоставил: имеется хэш «строка-массив» (ну или просто массив массивов, непринципиально), необходимо поэлементно сравнить каждый массив с каждым, это сравнение я хочу распараллелить.

[Bepec]

Ну я вообще то брал в расчёт все расходы - на чтение, на вычисление хеша и на сравнение.

PS я имел в виду дать данные для работы, эти 10к файлов или что там

[kambala]

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

главный затык в перекрестном сравнении (потому что много сравнивать), а что там внутри — неважно.

[poru]

трудно будет вычленить минимальный

тема создана не для «напишите мне», а «расскажите как правильно сделать и что почитать».

то есть хэш разрезать на n/2 частей и на каждую выделить нить, которая будет проводить 3 сравнения?

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

Первая задача будет сравнивать первый файл со всеми остальными
Вторая задача будет сравнивать второй файл со всеми последующими + предпоследний с последним
Третья - третий файл со всеми последующими + 3 последних
и.т.д

Задаче надо знать только контейнер и 2 индекса с которых начинать

вот это буду пробовать

В случае когда 1-я задача в первом потоке будет сравнивать 1-й и 2-й файлы, а 2-я задача во втором потоке будет сравнивать 2-й и 3-й файлы, то два потока будут обращаться к одному и тому же 2-му массиву данных. Это приведет к снижению производительности.

[Igors]

В случае когда 1-я задача в первом потоке будет сравнивать 1-й и 2-й файлы, а 2-я задача во втором потоке будет сравнивать 2-й и 3-й файлы, то два потока будут обращаться к одному и тому же 2-му массиву данных. Это приведет к снижению производительности.

Читать одно и то же могут хоть все нитки сразу. Это будет даже чуть шустрее за счет кеша процессора

[poru]

Да, если адреса данных для 2х потоков будут совпадать. Я смотрел с другой стороны, а если за квант времени каждый поток обрабатывает по 40 байт и адреса данных перекрываются, то будет постоянная перезагрузка кэша.

[Igors]

Да, если адреса данных для 2х потоков будут совпадать. Я смотрел с другой стороны, а если за квант времени каждый поток обрабатывает по 40 байт и адреса данных перекрываются, то будет постоянная перезагрузка кэша.

При использовании QString и (я так подозреваю) "регулярки" о таких вещах говорить просто неприлично 

[poru]

главный вопрос темы: как ускорить обработку, отсюда Q'стринги просто не применимы 

[Igors]

главный вопрос темы: как ускорить обработку, отсюда Q'стринги просто не применимы 

Давайте спокойнее относиться к моде/увлечениям молодежи 

[kambala]

Да, если адреса данных для 2х потоков будут совпадать. Я смотрел с другой стороны, а если за квант времени каждый поток обрабатывает по 40 байт и адреса данных перекрываются, то будет постоянная перезагрузка кэша.

При использовании QString и (я так подозреваю) "регулярки" о таких вещах говорить просто неприлично  

мимо

[gil9red]

Вспомнилась мне точно такая же история. Нужно было в строго определенное время анализировать ~40000 техпроцессов (1 тп - 1 файл). Программа была написана задолго до меня в Delphi и отрабатывала за 2,5 часа. Руководству для принятия каких-то там решений оставалось 30 минут и попросили ускорить. Переписал все в Builder 2006 и результат получал через 40 минут. Все в восторге! Но какой то гвоздь в заднице не давал покоя и в одну  из новогодних ночей переписал все на чистом "С" без шаблонов, классов, с загрузкой файлов в память и расчета смещения указателей и все на 2-х потоках. Программа обсчитала все эти файлы за полторы минуты. Я в шоке! Руководство в испуге! Попросили больше таких программ не писать) Использование привычных классов будет вас тормозить.

http://bash.im/quote/438082

 

[kambala]

всем спасибо, все получилось. результаты (дебаг сборка без подключенного дебаггера):

• загрузка файлов и обработка по отдельности (эту часть я не менял):
  
  • 1000 файлов: 17 секунд
  • 10000 файлов: 220 секунд
• перекрестное сравнение:
  
  • 1000 файлов: 30 секунд => 13 секунд
  • 10000 файлов: 2850 секунд => 1420 секунд

[kambala]

в релиз сборке студией 2015 10к файлов обрабатывается чуть менее 3-х минут правда, тут машина чуть помощнее.

[Igors]

• 1000 файлов: 30 секунд => 13 секунд

Наверное 4 ядра? Маловато КПД. Если интересно сравните с OMP, там главная забота - подключить либу, (в MSVC она есть), дальше так

Код

C++ (Qt)
#pragma omp parallel for
for (int i = 0; i < task.size(); ++i)
 DoTask(task[i]);
 

Ну и воткнуть omp_set_num_threads на старте приложения