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

[kambala]

Здравствуйте. Никогда толком не имел дел с многопоточностью / параллельностью, а хотелось бы научиться.

Есть папка с n файлами. Требуется загрузить данные из каждого файла (файлы маленькие, не более 10 кб, нужных данных и того меньше), а потом провести перекрестное сравнение файлов (т.е. сравнить данные 1-го файла с 2,3,...,n и т.д.).

Сейчас у меня сделано очень банально: слот загрузки/обработки запускается через QtConcurrent::run(), а интерфейс обновляется через QMetaObject::invokeMethod(). Процессор при этом загружается на 30% (по ядрам не смотрел), а сам процесс отрабатывает крайне долго для 10к файлов. (даже для 500 файлов приходится ждать секунд 30)

Это можно как-то распараллелить и ускорить?

[Old]

10 000 файлов * 10К = 100Мб, даже если таких файлов будет 100 000, то они все займут чуть больше 1Гб. Расходы на память приемлемые, поэтому не вижу причин отказываться от их загрузки в память и дальнейшем разборе уже без чтения с диска.
Поэтому, я бы разделил этот вопрос на два:
* параллельная загрузка всех файлов в память
* параллельная их обработка.
С какой начнем?

[kambala]

10 000 файлов * 10К = 100Мб, даже если таких файлов будет 100 000, то они все займут чуть больше 1Гб. Расходы на память приемлемые, поэтому не вижу причин отказываться от их загрузки в память и дальнейшем разборе уже без чтения с диска.

сейчас я так и делаю, только память на этих 10к вырастает до 400 МБ (это с учетом создания необходимых структур данных), но это нестрашно.

Поэтому, я бы разделил этот вопрос на два:
* параллельная загрузка всех файлов в память
* параллельная их обработка.
С какой начнем?

логично начать с первого пункта

[Old]

Самый простой в реализации вариант с использованием  QtConcurrent.
Посмотрите пример Image Scaling Example, только вместо скалинга картинок загружайти файлы в QByteArray. Из коробки будет прогресс, сигнал окончания и коллекция результирующих буферов.
Тоже можно сделать руками, с организацией пула рабочих потоков, очередями заданий и средствами синхронизации или использовать openmp.

[Igors]

сейчас я так и делаю, только память на этих 10к вырастает до 400 МБ (это с учетом создания необходимых структур данных), но это нестрашно.

А в чем заключается сравнение? По размеру файла, по содержимому, или как-то хитро? Не верится в полчаса, пусть и на одной нитке

[kambala]

Самый простой в реализации вариант с использованием  QtConcurrent.
Посмотрите пример Image Scaling Example, только вместо скалинга картинок загружайти файлы в QByteArray. Из коробки будет прогресс, сигнал окончания и коллекция результирующих буферов.

спасибо, попробую

сейчас я так и делаю, только память на этих 10к вырастает до 400 МБ (это с учетом создания необходимых структур данных), но это нестрашно.

А в чем заключается сравнение? По размеру файла, по содержимому, или как-то хитро? Не верится в полчаса, пусть и на одной нитке

хитро по содержимому файлы — это сохранения диабло 2, задача — поиск клонированных предметов.

[kambala]

пример посмотрел, оказывается все достаточно просто

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

теперь в шаге 2 имеется QHash<QString, QList> и нужно провести сравнение каждого с каждым (списки, естественно, сравниваются поэлементно). Можно ли разрезать хэш пополам и раздать сравнение 3-м потокам, которые будут сравнивать 1 с 1, 2 с 2 и 1 с 2? Или лучше как-то по-другому?

[Igors]

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

Multi-threading - отличное лекарство от синглтон и глобальных переменных вообще  

теперь в шаге 2 имеется QHash<QString, QList> и нужно провести сравнение каждого с каждым (списки, естественно, сравниваются поэлементно). Можно ли разрезать хэш пополам и раздать сравнение 3-м потокам, которые будут сравнивать 1 с 1, 2 с 2 и 1 с 2? Или лучше как-то по-другому?

Надо стремиться к равномерной загрузке ниток, поэтому напрашивается аналогия с суммой арифметической прогрессии,
1 + 100
2 + 99
3 + 98
...
Так сразу известно число задач и они примерно равны. Рез-ты сравнения лучше писать в саму задачу, обходясь без всяких блокировок

[kambala]

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

[Igors]

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

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

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

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

[poru]

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

[Bepec]

Ну тут уже вопрос, стоит ли овчинка выделки?
Ну и да, вопрос сколько обрабатывать будет простой цикл?

[kambala]

это мне вопрос? ну время указано в первом посте

[Bepec]

А есть возможность скинуть минимальный проект и файлы для обработки?
Я б тогда поковырялся.

[kambala]

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

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

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

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

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

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

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