Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
Файлов около 10000-20000.
Размеры каждого каталога порядка ~100Mb.
Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

Самый adyaq вариант — распаралелить сравнение каталогов.
Имеет ли смысл использовать для такой задачи эрланг?
Как у эрланга обстоит дело с чтением текстовых файлов?
Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?

Здравствуйте, Аноним, Вы писали:

А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
А>Файлов около 10000-20000.
А>Размеры каждого каталога порядка ~100Mb.
А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

А>Самый adyaq вариант — распаралелить сравнение каталогов.
А>Имеет ли смысл использовать для такой задачи эрланг?
А>Как у эрланга обстоит дело с чтением текстовых файлов?
А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?

По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.

Здравствуйте, Code Digger, Вы писали:

CD>Здравствуйте, Аноним, Вы писали:

CD>По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.

Но вообще-то сомневаюсь, что подойдёт. У Эрланга блокирующие вызовы системных ф-ий, AFAIK, так что его треды Вас не спасут. Треды нужны нативные. Так что и с Пёрлом вопрос. Берите Хаскель, одним словом.

CD>Берите Хаскель, одним словом.
Задача конечно не срочная, но с хаскелем я точно быстро не разберусь.
А откладывать задачу на пол года-год как-то не хочется

Здравствуйте, Аноним, Вы писали:

А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?

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

Эрланг использовать совершенно бессмысленно. Дисковый ввод-вывод вывод у него очень тормозной. Дальше три варианта
1) алгоритм сравнения достаточно прост, и производительность ограничена random io, например сравниваются загаловки файлов
2) алгоритм сравнения прост и производительность ограничена linear io. Например считаем контрольные суммы файлов.
3) алгоритм сравнения мегасложен, так что упираемся в cpu.

Если #1 то подойдет по сути любой язык, много Вы не проиграете
Если #2 то подойдет любой язык с вменяемой скорость ввода вывода. perl, python, java, c... только не erlang
Если #3 то тоже что и #2 + нормальная поддержка многопоточности, думаю это есть во всех языках, но на перле я с этим дела не имел. я бы делал на java или c++ если уж совсем скорости не хватает.

Алгоритм сравнения — простой.
Где-то в начале файла находится строка с айдишником, датой, временем, которую сравнивать не нужно.
Весь остальной текст сравнивается просто построчно до первого различия.

Здравствуйте, Аноним, Вы писали:

А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
А>Файлов около 10000-20000.
А>Размеры каждого каталога порядка ~100Mb.
А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

Что значит СРАВНИВАЛА? /bin/cmp годится? Это наиболее принципиальный момент.

А>Самый adyaq вариант — распаралелить сравнение каталогов.

На небольшое (2-4-8) число потоков. Для использования двухвёдерных процессоров с быстрыми жёсткими дисками.
И упираться всё будет скорей в них, в диски. Тогда не факт вообще, что распараллеливание не сделает только хуже
(из-за нелинейного чтения). Небольшое же число потоков нагрузки на диск сильной не даст, но позволит отдать процессор
в другие задачи, когда где-то упёрлось в диск (IMHO).

А>Имеет ли смысл использовать для такой задачи эрланг?

Слов нет. А старый добрый fork() ничем не хуже какбы.

ну тогда ответ очевиден — пишите на том, на чем быстрее напишите и удобнее поддерживать. Вообще хоть я и не любитель перла, но на нем эту программу было бы написать быстрее чем мы тут с Вами обсуждаем

А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.

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

А>Файлов около 10000-20000.
А>Размеры каждого каталога порядка ~100Mb.
А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

Если настолько часто, что это загоняет диск, тогда нужно создать отображение filename -> state. Berkley DB/memcache/xattr/что угодно key-value подойдёт. state может быть, например, md5 хэш от содержимого. Здесь — самое важное, при изменении файлов сразу же обновлять эту базу. Тогда сравнение (сначала лезем в базы и отсекаем файлы с одинаковым state) будет супер мега быстрое.

И такое, опять же, тоже есть. Называется git (ну это для скорости, а то ещё и другие тоже есть). Заводите в каждой из директорий по git-репозиторию, на каждом [втором/десятом/etc] изменении файлов делаете git add . && git commit -a -m "". Перед сравнением git fetch ../other-dir, само сравнение git diff other/master. Если выберете этот способ, могу подробно расписать что и зачем надо запускать.

А>Самый adyaq вариант — распаралелить сравнение каталогов.
А>Имеет ли смысл использовать для такой задачи эрланг?
А>Как у эрланга обстоит дело с чтением текстовых файлов?

Плохо. Для скорости придётся читать их как бинарные и парсить руками.
http://muharem.wordpress.com/2008/04/30/text-filtering-with-erlang/
http://www.tbray.org/ongoing/What/Technology/Erlang/

А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?

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

Здравствуйте, Аноним, Вы писали:

CD>>Берите Хаскель, одним словом.
А>Задача конечно не срочная, но с хаскелем я точно быстро не разберусь.
А>А откладывать задачу на пол года-год как-то не хочется

Вы себя переоцениваете! Нужно быть исключительным идиотом, чтобы потратить на эту задачу полгода, даже изучая Хаскель с нуля.

Первое, что я написал на Хаскеле был "Hello, World", второе — grep.
Многопоточность в Хаскеле вполне понятна, с точностью до местного колорита. Можно писать и как на Си.
Поскольку в этой задаче никаких абстракций Вам городить не придётся, то даже понимать монады не обязательно — достаточно принять как данность IO Monad.

Здравствуйте, Code Digger, Вы писали:

CD>Здравствуйте, Code Digger, Вы писали:

CD>>Здравствуйте, Аноним, Вы писали:

CD>>По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.

CD>Но вообще-то сомневаюсь, что подойдёт. У Эрланга блокирующие вызовы системных ф-ий, AFAIK, так что его треды Вас не спасут. Треды нужны нативные. Так что и с Пёрлом вопрос. Берите Хаскель, одним словом.

Спасут. Стартовать рантайм с опцией async-threads и вперед — никаких проблем. Треды нативные не нужны.

Здравствуйте, Code Digger, Вы писали:

CD>По поводу скоростного (относительно) файлового ввода-вывода писал в ЖЖ Gaperton (gaperton.livejournal.com) — посмотрите, там есть замеры скорости.

С тех пор в модуле file как-то тихо появилась функция read_line, или что-то вроде того. Для чтения строки. Если это, что я думаю (а это по ходу оно), то все должно быть отлично с чтением текстовых файлов без плясок с бубном. Главное в этом деле, по большому счету — не использовать модуль io. И вся хитрость.

Здравствуйте, Аноним, Вы писали:

А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
А>Файлов около 10000-20000.
А>Размеры каждого каталога порядка ~100Mb.
А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

А>Самый adyaq вариант — распаралелить сравнение каталогов.
А>Имеет ли смысл использовать для такой задачи эрланг?

Нет. Если надо сравнивать контент файлов находя разницу построчно, есть хорошие шансы упрется в процессор, а не в диск. В случае с Эрлангом — я могу гарантировать упирание в CPU.

Рекомендую С/С++. Параллелить — только по показаниям, количество тредов иметь несколько больше, чем процессорных ядер, чтобы сравнение контента наложилась на операции ввода-вывода. Да, и ни в коем случае ничего не копировать между тредами — предпочтительно в тредах сравнения работать с неизменяемыми данными, и не класть на них блокировок.

Это если очень хочется, чтобы работало очень быстро. А для начала — тупо заколбасить на С/С++, взяв готовую хорошую либу, которая быстро умеет искать diff. Тысячи их.

Здравствуйте, Temoto, Вы писали:

T>Во-первых, на HDD вы раньше упретёсь в скорость диска. А если будете читать много файлов одновременно (в несколько потоков), то загоняете диск и скорость будет только хуже.

Точно. Но конвейеризовать — можно, чтобы наложить чтение на вычисление. Один поток читает файлы последовательно (блоками, чтоб памяти хватило), передает данные второму, второй — на фоне чтения выполняет сравнение.

Возможно, проще будет асинхронным вводом-выводом воспользоваться, делать все в одном треде, и не парить мозг. Вариант.

Здравствуйте, Аноним, Вы писали:

А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
А>Файлов около 10000-20000.
А>Размеры каждого каталога порядка ~100Mb.
А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

А>Самый adyaq вариант — распаралелить сравнение каталогов.

Эта задача будет упираться в файловый ввод-вывод. Если распараллелете чтение каталогов, скорее всего получите падение скорости. Порядка так на два. Из-за того, что система, пытаясь угодить всем потокам сразу, будет ездить головкой диска туда-сюда, вместо того, чтобы долбить в каком-то одном месте.

Здравствуйте, Аноним, Вы писали:

А>Нужно написать утилиту, которая бы сравнивала два каталога с большим количеством текстовых файлов.
А>Файлов около 10000-20000.
А>Размеры каждого каталога порядка ~100Mb.
А>Сравнивать нужно будет часто. И желательно чтобы утилита работала быстро.

А>Самый adyaq вариант — распаралелить сравнение каталогов.
А>Имеет ли смысл использовать для такой задачи эрланг?
А>Как у эрланга обстоит дело с чтением текстовых файлов?
А>Или многозадачность эрланга в этом случае не поможет и лучше обойтись добрым старым перлом?

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

Здравствуйте, LelicDsp, Вы писали:

LD>Эрланг использовать совершенно бессмысленно. Дисковый ввод-вывод вывод у него очень тормозной.

Да что вы говорите?
На недавней задаче он выдавал до 40мб/с при линейном чтение + обработке (с этого диска dd if=big_file of=/dev/null даёт около 100Mb/s)

Здравствуйте, FR, Вы писали:

FR>Есть подозрение что многозадачность тут совсем не поможет так как быстродействие будет
FR>упираться в файловый ввод-вывод.

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

Вот только все эти задачи не из серии ФП — это точно. Тут нужны хорошие библиотеки или низкоуровневый доступ к ОС (читай С).

Здравствуйте, VladD2, Вы писали:


VD>Ну, как сказать. Асинхронный ввод-вывод тут очень даже кстати будет. Пока файлы читаются можно будет прочитанные сравнивать. Ну, и сравнение может быть разной степени ресурсоемкости. Одно дело тупо сравнить побайтовый, другое дело некий дифференциал рассчитать.

Ну для этого настоящая многозадачность не нужна, достаточно ассинхронного IO или легких потоков. Хотя конечно зависит от тяжести вычислительной части задачи, если простое сравнение то оно и в интерпретаторе будет рантаймом делаться.

VD>Вот только все эти задачи не из серии ФП — это точно. Тут нужны хорошие библиотеки или низкоуровневый доступ к ОС (читай С).

Ну если есть нормальные библиотеки без разницы на чем.