Обработка файла CSV в Clojure параллельно

Question

У меня большой CSV-файл, который содержит независимые элементы, для обработки которых требуется немало усилий. Я хотел бы иметь возможность обрабатывать каждую позицию параллельно. Я нашел пример кода для обработки файла CSV на SO здесь:

Новичок, преобразовывающий файлы CSV в Clojure

Код:

(use '(clojure.contrib duck-streams str-utils))                 ;;'
(with-out-writer "coords.txt"
  (doseq [line (read-lines "coords.csv")]
    (let [[x y z p] (re-split #"," line)]
      (println (str-join \space [p x y z])))))

Это позволило распечатать данные из моего CSV-файла, что было здорово - но он использовал только один процессор. Я пробовал разные вещи, заканчивающиеся на:

(pmap println (read-lines "foo"))

Это работает нормально в интерактивном режиме, но ничего не делает при запуске из командной строки. Из разговора по IRC это связано с тем, что stdout по умолчанию недоступен для потоков.

На самом деле я ищу способ идиоматически применять функцию к каждой строке файла CSV и делать это параллельно. Я также хотел бы напечатать некоторые результаты на стандартный вывод во время тестирования, если это вообще возможно.

Есть идеи?

Answer 1

Если вы хотите, чтобы результаты на выходе были в том же порядке, что и на входе, то печать из pmap может быть не очень хорошей идеей.Я бы порекомендовал создать (ленивую) последовательность строк ввода pmap поверх этого, а затем распечатать результат pmap.Примерно так должно работать:

(dorun (map println (pmap expensive-computation (read-lines "coords.csv"))))

Answer 2

Если вы хотите сделать это со скоростью, вы можете посмотреть эту статью о том, как Алекс Осборн решил задачу Widefinder 2, поставленную Тимом Бреем. Алекс занимается всеми аспектами анализа, обработки и сбора результатов (в случае с Widefinder 2 файл представляет собой очень большой журнал Apache). Фактический используемый код здесь .

Answer 3

Я был бы очень удивлен, если бы можно было ускорить использование кода с использованием большего количества ядер.Я на 99% уверен, что фактическим ограничением скорости здесь является файловый ввод-вывод, который должен быть на пару порядков медленнее, чем любое одно ядро, которое вы можете выбросить при проблеме.накладные расходы, которые вы будете вводить при разделении этих минимальных задач на несколько процессоров.pmap не совсем свободеннесколько файлов в их собственных потоках принесут вам гораздо больше за гораздо меньшие усилия.