1

I'm learning GNU parallel and tried the following:

$ for i in {1.txt,2.txt}; do time wc -l $i; done
100 1.txt

real    0m0.010s
user    0m0.000s
sys     0m0.010s
10000012 2.txt

real    0m0.069s
user    0m0.050s
sys     0m0.018s

I then reran the above command with parallel, but it slowed things down. Why?

$ for i in {1.txt,2.txt}; do time parallel --nonall wc -l $i; done
100 1.txt

real    0m0.325s
user    0m0.192s
sys     0m0.042s
10000012 2.txt

real    0m0.305s
user    0m0.220s
sys     0m0.043s
  • Walk through the tutorial, then you will have a much better understanding of what GNU Parallel can do: gnu.org/software/parallel/parallel_tutorial.html – Ole Tange Jan 19 '14 at 12:39
  • 2
    Aside from your improper usage as noted by others, running jobs like this in parallel via any method is not likely to produce results you want. For starters you need jobs that take longer to run than the overhead introduced by parallelizing them. – casey Jan 19 '14 at 14:28
  • GNU Parallel is a 7820 line perl script. 0.3 seconds of startup overhead sounds reasonable. – Peter Cordes Aug 28 '15 at 3:58
5

In your case you're calling it from a for loop so you aren't really running anything in parallel. All you're doing is adding the overhead of calling parallel in the second example, but it's still only running the files through in a single fashion.

Example

This might help you see what's going on.

without parallel

$ time for i in {1..2}; do sleep 2;done

real    0m4.004s
user    0m0.001s
sys 0m0.002s

with parallel

$ time for i in {1..2}; do parallel "sleep 2" < /dev/null;done

real    0m4.574s
user    0m0.245s
sys 0m0.089s

An alternative

You could call parallel like this instead.

$ time parallel --gnu time wc -l ::: 1.txt 2.txt 

real    0m0.007s
user    0m0.001s
sys 0m0.000s
1000 1.txt

real    0m0.003s
user    0m0.000s
sys 0m0.001s
1000 2.txt

real    0m0.207s
user    0m0.120s
sys 0m0.052s

Here we can see there is overhead in having to call `parallel with the 3rd time grouping showing the "overall" amount of time taken to run the entire parallel command.

References

  • @user13107 You should pose questions as questions and not as comments, not many people apart from are going to read your comment-question. – Timo Jan 19 '14 at 8:34
  • @Timo corrected – user13107 Jan 19 '14 at 9:02
1

Thanks to this post, I understood why I was loosing time with parallel on a similar job. I hope my findings help more people!

In this example, I use both for and parallel to: - do 100000 operations to the power of 10 - do 10 operations to the power of 1000000

Results clearly confirm what Casey mentions: "you need jobs that take longer to run than the overhead introduced by parallelizing them". The for loop has the upper hand for the 100000 small operations, while parallel has the upperhand for the ^1000000

$ time for i in $(seq 100000); do echo "$i^10"|bc>/dev/null; done
real    1m19.859s
user    0m4.788s
sys     0m24.204s

$ time seq 100000|parallel "echo {}^10|bc>/dev/null"
real    2m31.269s
user    1m43.833s
sys     1m40.089s

$ time for i in $(seq 10); do echo "$i^1000000"|bc>/dev/null; done
real    1m54.729s
user    1m54.690s                                                                                                                                                                                                                                                                           
sys     0m0.023s                                                                                                                                                                                                                                                                            

$ time seq 10|parallel "echo {}^1000000|bc>/dev/null"
real    0m27.950s                                                                                                                                                                                                                                                                           
user    2m28.476s                                                                                                                                                                                                                                                                           
sys     0m0.047s 

As you can see, the user time is much higher using parallel (overhead)... but the real time gets much better, effectively getting the results faster (by a factor of 4)

These are not the results of extensive testing, but might help you understand the kind of operations where the use of parallel will be beneficial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.