Re: [GM-core] Need Linux volunteer for OpenMP testing

On Thu, 28 Aug 2008, Boudewijn Rempt wrote:
>
> I've got a simple Core2duo laptop with 2gb ram running 2.6.25 in 64bits modus,
> which should qualify :-). Plus, GraphisMagick has saved me a lot of time in
> the development of Krita. What should I do?

Since I (and most of the world outside of supercomputer research 
institutions) do not have extensive experience with the behavior of 
OpenMP, I have started the integration of OpenMP into GraphicsMagick 
so that it can be applied to any simple algorithm which transforms 
pixels in a position-independent way, or using similar x,y positions 
in the several images involved.  The 'threshold' algorithm is an 
excellent example of this.  I am saving some of the more exotic 
algorithms (the ones that immediately come to mind) for later after 
the behavior of OpenMP is well understood.

I have been rewriting existing algorithms to use an execution 
framework I call "pixel iterators".  The algorithms are then comprised 
of simple functions and the tuning for OpenMP can then be done via the 
framework.

The GraphicsMagick NEWS file 
(http://www.graphicsmagick.org/www/NEWS.html) lists most of the 
algorithms that I have already given the treatment in the "Performance 
Improvements" section.

I am initially interested in how effective various hardware and 
operating systems are with executing OpenMP.  I use Sun's Solaris as 
my main development environment, which is one of the best available 
for multithreading.   By understanding the relative level of overhead, 
I can understand how much work should be divided up for each thread.

GraphicsMagick includes a 'benchmark' subcommand which may be used to 
measure the amount of time that any other subcommand takes to execute 
repeatedly for a specified duration or a specified number of 
iterations.  So you could measure the time for a 'convert' command 
like:

   gm benchmark -duration 10 convert infile.jpg -normalize outfile.jpg

or

   gm benchmark -iterations 100 convert infile.jpg -normalize outfile.jpg

When timing an operation it is best to consider the overhead from 
reading files so if the input is from a file, the operation can simply 
be specified multiple times so that most of the execution time is from 
the operation rather than reading the file.

GCC 4.2 (or later) is needed in order to support OpenMP on Linux. 
GraphicsMagick will use OpenMP by default if it is available.  GCC's 
OpenMP will allocate as many threads as you have processor cores by 
default.  According to OpenMP standard, you can specify the number of 
threads to use via the OMP_NUM_THREADS environment variable.

Here is an example of using the benchmark facility to test how OpenMP 
accellerates (hopefully!) an algorithm:

% for threads in 1 2 3 4
do
echo "Threads $threads"
OMP_NUM_THREADS=$threads gm benchmark -duration 10 convert -size 1024x768 \
   -type truecolor 'xc:#F00' -operator all threshold 50% null:
done
Threads 1
Results: 1677 iter 9.99s user 10.00s total 167.70 iter/s (167.87 iter/s cpu)
Threads 2
Results: 2211 iter 18.29s user 10.00s total 221.10 iter/s (120.89 iter/s cpu)
Threads 3
Results: 2599 iter 26.38s user 10.00s total 259.90 iter/s (98.52 iter/s cpu)
Threads 4
Results: 2612 iter 33.71s user 10.00s total 261.20 iter/s (77.48 iter/s cpu)

>From this example, we see that there was a speedup by adding threads, 
but that with four cores, we fell far short of a linear speedup (1.56X 
rather than 4X).  By testing with wider image we see more efficiency 
which leads me to believe that this algorithm will run faster if each 
thread is given more work to do per iteration.  This particular 
algorithm is difficult to speed up since it has little work to do but 
if we can speed this one up, then we can speed up anything else.

It is easy to become discouraged when trying to speed up algorithms 
which do almost no work, but it is encouraging to see that when just a 
tiny bit more work is added (in this case pixel values are divided by 
two, and then multiplied by two) we are seeing much better behavior 
for a 3.5X speedup on a 4 core system:

% for threads in 1 2 3 4
do
echo "Threads $threads"
OMP_NUM_THREADS=$threads gm benchmark -duration 10 convert \
   -size 10240x256 -type truecolor xc:#F00 -operator all divide 2.0 \
   -operator all multiply 2.0 null:
done
Threads 1
Results: 128 iter 10.02s user 10.03s total 12.76 iter/s (12.77 iter/s cpu)
Threads 2
Results: 245 iter 19.44s user 10.00s total 24.50 iter/s (12.60 iter/s cpu)
Threads 3
Results: 246 iter 19.93s user 10.01s total 24.58 iter/s (12.34 iter/s cpu)
Threads 4
Results: 444 iter 36.42s user 10.00s total 44.40 iter/s (12.19 iter/s cpu)

As a first step to contributing toward testing, you should make sure
that you can build GraphicsMagick 1.3 from development sources
(preferably from CVS) with OpenMP and observe that it is working.

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/