Вопросы Теги

Как использовать параллель GNU эффективно

Можно использовать fgrep для этого:

fgrep -v -f file1  file2  > unique_addresses

Эта задача будет намного легче, если у Вас будет 1 адрес электронной почты на строку в обоих файлах.

Традиционно fgrep существует как отдельная программа, но в утилитах GNU, grep -F делает то же самое.

8
03.02.2015, 13:31
3 ответа

Декомпрессия здесь узкое место. Если декомпрессия не параллельна внутренне, вы не добитесь его самостоятельно. Если у вас есть более одной работы, то, конечно, запустите их параллельно, но ваш трубопровод сам по себе трудно распараллелизовать. Разделение одного потока в параллельные потоки почти никогда не стоит того, а может быть очень болезненным с синхронизацией и слиянием. Иногда вам просто нужно принять, что несколько ядер не помогут с каждой задачей, которую вы работаете.

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

1
27.01.2020, 20:11

GreeP очень эффективен - нет смысла в работе параллельно. В вашей команде только декомпрессия нужна больше процессора, но это не может быть параллельно.

Разделение ввода параллельно нужна больше процессора, чем получить соответствующие строки GREP.

Ситуация изменяется, если вы хотите использовать вместо Grep-то, что нужно гораздо больше процессора для каждой строки - тогда параллель будет иметь больше смысла.

Если вы хотите ускорить эту операцию - посмотрите, где есть узкое место - вероятно, это декомпрессия (затем помогает использовать другой инструмент декомпрессии или лучшего процессора) или - чтение с диска (затем помогите использовать другой инструмент декомпрессии или лучшего диска).

Из моего опыта - иногда лучше использовать LZMA (-2, например) для сжатия / декомпресс-файлов - оно имеет более высокое сжатие, чем GZIP, насколько гораздо меньше необходимо прочитать данные с диска и скорость сопоставимы.

2
27.01.2020, 20:11

Я действительно удивлен, что вы получаете 270 МБ / с с использованием GNU Parallel's - труба . Мои тесты обычно максимально максятся примерно на 100 МБ / с.

Ваше узкое место, скорее всего, в GNU Parallel: - труба не очень эффективна. - PipePart , однако, это: здесь я могу получить порядка 1 ГБ / с на CRO CPU.

К сожалению, есть несколько ограничений по использованию - PipePart :

  • Файл должен быть искать (т. Е. Нет трубы)
  • Вы должны быть в состоянии найти начало записи с - -recStart / - Process (т. Е. Не сжатый файл)
  • Номер строки неизвестен (так что вы не можете иметь 4-строчную запись).

Пример: 

parallel --pipepart -a bigfile --block 100M grep somepattern
8
27.01.2020, 20:11

Теги

Похожие вопросы