Paralelo GNU - grepping n linhas para m expressões regulares

4

O paralelo GNU grepping n linhas para m expressões regulares , o exemplo declara o seguinte:

If the CPU is the limiting factor parallelization should be done on the regexps:

cat regexp.txt | parallel --pipe -L1000 --round-robin grep -f - bigfile

This will start one grep per CPU and read bigfile one time per CPU, but as that is done in parallel, all reads except the first will be cached in RAM

Portanto, neste caso, o GNU parallel round padroniza as expressões regulares de regex.txt em instâncias grep paralelas, com cada grep lendo bigfile separadamente. E, como afirma a documentação acima, o cache de disco provavelmente garante que bigfile seja lido do disco apenas uma vez.

A minha pergunta é a seguinte: a abordagem acima parece ser melhor do que a outra que envolve a obtenção de% GNU parallel round robin records de bigfile em paralelo grep instâncias que lêem regexp.txt , algo como

cat bigfile |  parallel --pipe -L1000 --round-robin grep -f regexp.txt -

Por que isso seria? Como eu vejo isso assumindo o cache de disco em execução, bigfile e regexp.txt seriam cada um lidos do disco uma vez em qualquer um dos casos. A principal diferença que eu posso pensar é que a segunda abordagem envolve significativamente mais dados sendo passados por pipes.

    
por iruvar 03.10.2014 / 17:25

1 resposta

2

É devido ao GNU Parallel - o canal é lento.

cat bigfile |  parallel --pipe -L1000 --round-robin grep -f regexp.txt -

atinge o máximo de 100 MB / s.

No exemplo da página man, você também encontrará:

parallel --pipepart --block 100M -a bigfile grep -f regexp.txt

que se aproxima do mesmo, mas atinge o máximo de 20 GB / s em um sistema de 64 núcleos.

parallel --pipepart --block 100M -a bigfile -k grep -f regexp.txt

deve fornecer exatamente o mesmo resultado que grep -f regexp.txt bigfile

    
por 03.10.2014 / 19:06