3 ms·
The problem of resizing all these images is an "embarrassingly parallel" one, right? You don't care about how fast any individual image is resized, only how fas
by lars512 16y ago
The problem of resizing all these images is an "embarrassingly parallel" one, right? You don't care about how fast any individual image is resized, only how fast they're resized in aggregate, and each image is a nice small chunk of work.
The author spends time tuning the number of workers and the number of OpenMP processes per worker for GraphicsMagick on his 16-core machines. Isn't this type of tuning a waste of time? Even using just two cores instead of one seems to introduce inefficiency. Wouldn't he have been better off just using 16 workers, each compiled without OpenMP so that it would run serially (and more efficiently)?
- mahmud 16y agoYou really nailed it. Yes, yes and yes! This is the sort of stupid batch task that can be done with a shell-script using all the machines in the office after hours. Cut out the middle ware, cut down the threads and fancy IPC, and hunker down with good ole minimal number of processes on a bunch of machines. Heck, they might even see a big win if they use a different "server" memory management algorithm that's more tailored to batch, not-so-responsive applications.
- tange 16y agoLike this (if you have GNU Parallel http://www.gnu.org/software/parallel/ http://www.gnu.org/software/parallel/ installed) to run on multiple computers: find images | parallel -j+0 –trc {.}.out -S server1,server2,: “do_stuff {} > {.}.out” Watch the intro video for GNU Parallel: http://www.youtube.com/watch?v=OpaiGYxkSuQ http://www.youtube.com/watch?v=OpaiGYxkSuQ