31–37 of 37 posts
Earlier quoted context omitted.
make requires a Makefile, whereas one can pass parameters directly to parallel. There also seems to be a few more options revolving around job success/failure and how to react -- a) ignore failed jobs and report how many at the end, b) cleanly exit as soon as a job fails and c) stop all jobs as soon as one fails.
Those (a) (b) and (c) points sound like strengths of make, to me.
Earlier quoted context omitted.
Well, the example(at least the first one) in that video is bit skewed. First, he runs gzip and then immediately runs 'parallel gzip' without dropping disk caches. So in the later case the bottleneck would be CPU rather than disk IO(everything read from disk cache in the RAM). IMO I expect for the work that is IO bound we won't see any significant improvement using parallel or anything similar.
Ideas for next video are most welcome. The ideal task: 1. Is single threaded 2. Takes a lot of CPU 3. Is a task that everyone can understand and relate to and which is close to a real world scenario I have loads of examples meeting requirement 1+2. It is 3 that is the hard part. Post them to parallel@gnu.org
Ah, one of these again. I wrote a simpler one a couple of years ago ( http://code.google.com/p/spawntool/ ) myself. All it does is read commands from stdin, one per line, and keep a desired number of processes running until all command lines are exhausted. Simple. I wrote my own because I got tired of all kinds of substitution and quoting issues with xargs. With spawn I only need to generate the shell commands and in…
Earlier quoted context omitted.
parallel is intended to work on arbitrary commands.
So is make.
Earlier quoted context omitted.
As I understand it, xargs only runs on the local machine; GNU parallel can run on remote machines as well. So parallel is the cluster-friendly version of xargs's -P.
Yep. There also is dxargs which looks very useful http://www.semicomplete.com/blog/geekery/distributed-xargs.h...
Earlier quoted context omitted.
Ideas for next video are most welcome. The ideal task: 1. Is single threaded 2. Takes a lot of CPU 3. Is a task that everyone can understand and relate to and which is close to a real world scenario I have loads of examples meeting requirement 1+2. It is 3 that is the hard part. Post them to parallel@gnu.org
How about doing something with imagemagick or mencoder? I think video encoding/decoding gives a nice balance between disk and cpu usage.
$ ls *.png |wc -l
3580
$ time ls|sed 's/\(.*\)\..*/\1/'|parallel convert {}.png {}.ppm
ls --color 0.00s user 0.01s system 63% cpu 0.016 total
sed 's/\(.*\)\..*/\1/' 0.01s user 0.00s system 39% cpu 0.025 total
parallel convert {}.png {}.ppm 97.39s user 61.87s system 890% cpu 17.883 total
$ time ls|sed 's/\(.*\)\..*/\1/'|xargs -I {} convert {}.png {}.ppm
ls --color 0.01s user 0.00s system 63% cpu 0.016 total
sed 's/\(.*\)\..*/\1/' 0.01s user 0.00s system 39% cpu 0.025 total
xargs -I {} convert {}.png {}.ppm 93.08s user 47.88s system 38% cpu 6:10.88 total