Hello all,
Since we discussed that not long ago, and I've got a few thousands pics
I want to integrate in a gallery, I've done a little benchmarking with
ImageMagick.
The conclusion is that I'm going to switch this to GCC4.8, as the
performance is remarkably better, at least on AMD64.
Here's the details:
The system is based on an old CPU:
Intel(r) Core(tm)2 Quad CPU Q9550 @ 2.83GHz
I run this command on a bunch of high rez pics, a couple of times to
ensure the results are consistent:
export OMP_NUM_THREADS=x
ptime \
bash -c "for i in _MG_10*.JPG; do
/opt/csw/bin/convert "$i" -sharpen 0x1.0 -resize 80% png:/dev/null
done"
Here are the results, using the current build as the reference (100).
Lower values are faster, and real is of course what matters most to the
user:
GCC4 SOS12U3 SOS12U3 -xO5
2 threads 3 threads *4 threads* *2 threads* 3 threads 4 threads 2
threads 3 threads 4 threads
real 06:48,3 05:08,9 *04:30,9* *09:12,0* 06:46,8 05:48,5
07:21,3 05:37,5 04:58,2
user 11:18,7 11:34,3 *12:03,7* *15:58,2* 16:15,1 16:46,2
12:17,0 12:34,5 13:08,7
sys 00:38,2 00:44,7 *00:49,1* *00:39,3* 00:45,1 00:50,4 00:38,0
00:45,4 00:49,9
73,98 55,96 *49,08* *100,00* 73,70 63,14 79,95
61,14 54,02
70,84 72,46 *75,53* *100,00* 101,77 105,02 76,91
78,74 82,32
97,20 113,63 *124,88* *100,00* 114,58 128,22 96,70
115,30 126,89
An important thing here: the default number of threads for Studio is 2,
while for GCC4, it is the number of available cores.
It means that for a casual user on a 4-core system like mine, the
immediate difference is really huge: the real time spent with GCC is
less than half that of Studio.
Even with using -xO5, Studio is still about 10% slower than GCC4.8.
I tried to build using -native with SOS12U3: it crashed on an assertion
failed.
I also tried -O3 with GCC, but the results were about the same or even
somewhat slower, so I didn't push it.
I'll put packages on experimental soon, I would be /very/ interested if
somebody could run a similar test on sparc hardware to compare
performance (I might be able to do it on an M3000 with 16 cores).
As for the ABI practicality: at this point, there's nothing depending on
the C++ ImageMagick library, so it won't break anything. Future
dependent packages should follow suit.
Laurent
Studio OpenMP variables:
http://docs.oracle.com/cd/E24457_01/html/E21996/aewcb.html
GCC:
http://gcc.gnu.org/onlinedocs/libgomp/OMP_005fNUM_005fTHREADS.html
On 15/07/13 15:34, Laurent Blume wrote:
Hello all,
I'm pushing ImageMagick 6.8.6-5.
There are a few things of note:
- I dropped DPS support: it's not a must-have, and it depends on a
really obsolete feature of Solaris
- the libs are now named like this: libMagickCore-6.Q16HDRI.so.1.0.0,
that's because HDR is enabled (it already was), I don't think it should
be a problem if it is linked to correctly. It also allow to have a
non-HDR version if it becomes needed
Cheers,
Laurent
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
