Re: OpenMP test report updated

On Mon, 17 Nov 2008, Nguyen Vu Hung wrote:

> From your test results, I can see that Solaris 
> multicores give the best "speedup". Have you( or anyone) tested GM' 
> OpenMP speed up on Solaris 8 coressystems like T5440?

Part of the reason could be that I do most of my development and 
tuning under Solaris.  The AIX system seems to do pretty well.  I 
expect that Linux four core would work quite well since GCC's GOMP 
(OpenMP implementation) is likely well tuned for Linux.

I do plan to test on a SPARC T2, 8 core, 64 thread system.  It should 
be very interesting.  I expect that the algorithms will do well but 
file reading and writing performance will be poor since most of it is 
still single threaded (PNM and DPX readers are multi-threaded).  This 
sort of hardware would be rather poor for dealing with JPEG files 
since libjpeg is not multi-threaded.

> "-gamma 1.6"' speedup is nearly 1.0 for G5 and Intel's CPUs. 
> "-border 6x6" speedup = 1.0 on Xeon. "-channel red" speedup = 1.0 on 
> Xeon. "-fill none -stroke gold -draw 'polygon 400,200 1100,800 
> 100,300'"speedup = 1.0 on Xeon. "-fill blue -stroke gold -draw 
> 'Bezier 400,200 1100,800 100,300'"speedup = 1.0 on Xeon. 
> "-monochrome" speedup = 1.0 on Xeon. "-normalize" speedup ~ 1.0 on 
> Xeon.

> Can you make another table that compare the speedup of different platforms?

That would certianly be interesting to someone planning to chose a 
type of system.

I must mention that a new build option is implemented for 1.3.1 which 
intentionally disables OpenMP for algorithms which get slower on 
systems with weak threading libraries.  The new FreeBSD and OS-X 
timings were done with these problematic algorithms set to single 
threaded.  Otherwise the algorithms actually get slower as threads are 
added.  That should explain some algorithms with speedup of '1.0' on 
some systems, but real speedup on others.  Also, there are algorithms 
included in the timings which have no OpenMP at all, which currently 
includes the drawing operations you listed.

> This is a good idea giving users more control over the codes.Though 
> the image quality vs time trade-off in JPEG is every easy to notice 
> if we increase/decrease the JPEG quality withlibjpeg's 
> jpeg_set_quality().

Selection of the DCT algorithm does not have noticeable impact on 
visual quality.  It does influence how long encoding the file takes, 
but that is rather CPU dependent.  On my Opteron system, using the 
libjpeg default shaved almost two seconds off of writing a JPEG file. 
Two seconds is eons compared to much of the internal processing.

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=/