Когда Вы пишете A | B, оба процесса уже выполняются параллельно. Если Вы рассматриваете их как использование только одного ядра, это, вероятно, потому что любая из настроек привязки ЦП (возможно, существует некоторый инструмент для порождения процесса с другой привязкой) или потому что одного процесса не достаточно для содержания целого ядра и системы, "предпочитает" не распространять вычисления.

Для выполнения нескольких B с одним A Вам нужен инструмент такой как split с --filter опция:

A | split [OPTIONS] --filter="B"

Это, однако, склонно испортить порядок строк в выводе, потому что задания B не будут выполнять все на той же скорости. Если это - проблема, Вы, возможно, должны были бы перенаправить B i-th вывод в промежуточный файл и сшить их вместе при использовании конца cat. Это, в свою очередь, может потребовать значительного дискового пространства.

Другие опции существуют (например, Вы могли ограничить каждый экземпляр B к выводу с буфером одной строки, ожидать, пока целый "раунд" B не закончил, выполнил эквивалент уменьшения до splitкарта, и cat временный вывод вместе), с переменными уровнями эффективности. 'Круглая' опция, просто описанная, например, будет ожидать самого медленного экземпляра B для окончания, таким образом, это будет значительно зависеть от доступной буферизации для B; [m]buffer мог бы помочь, или это не могло бы, в зависимости от того, каковы операции.

Примеры

Генерируйте первые 1 000 чисел и считайте строки параллельно:

seq 1 1000 | split -n r/10 -u --filter="wc -l"
100
100
100
100
100
100
100
100
100
100

Если бы мы должны были "отметить" строки, то мы видели бы, что каждая первая строка отправляется для обработки № 1, каждая пятая строка для обработки № 5 и так далее. Кроме того, во время это берет split для порождения второго процесса первым уже является хороший путь в свою квоту:

seq 1 1000 | split -n r/10 -u --filter="sed -e 's/^/$RANDOM - /g'" | head -n 10
19190 - 1
19190 - 11
19190 - 21
19190 - 31
19190 - 41
19190 - 51
19190 - 61
19190 - 71
19190 - 81

При выполнении на машине с 2 ядрами, seq, split и wc процессы совместно используют ядра; но выглядя ближе, система оставляет первые два процесса на CPU0 и делит CPU1 между рабочими процессами:

%Cpu0  : 47.2 us, 13.7 sy,  0.0 ni, 38.1 id,  1.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 15.8 us, 82.9 sy,  0.0 ni,  1.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM     TIME+ COMMAND
 5314 lserni    20   0  4516  568  476 R 23.9  0.0   0:03.30 seq
 5315 lserni    20   0  4580  720  608 R 52.5  0.0   0:07.32 split
 5317 lserni    20   0  4520  576  484 S 13.3  0.0   0:01.86 wc
 5318 lserni    20   0  4520  572  484 S 14.0  0.0   0:01.88 wc
 5319 lserni    20   0  4520  576  484 S 13.6  0.0   0:01.88 wc
 5320 lserni    20   0  4520  576  484 S 13.3  0.0   0:01.85 wc
 5321 lserni    20   0  4520  572  484 S 13.3  0.0   0:01.84 wc
 5322 lserni    20   0  4520  576  484 S 13.3  0.0   0:01.86 wc
 5323 lserni    20   0  4520  576  484 S 13.3  0.0   0:01.86 wc
 5324 lserni    20   0  4520  576  484 S 13.3  0.0   0:01.87 wc

Заметьте особенно это split ест значительную сумму ЦП. Это уменьшится в пропорции к потребностям A; т.е. если A является более тяжелым процессом, чем seq, родственник наверху split уменьшится. Но если A является очень легким процессом, и B довольно быстр (так, чтобы Вам был нужен не больше, чем B 2-3 для хранения наряду с A), затем параллелизируя с split (или каналы в целом), не могло бы хорошо стоить того.