Re: [csw-maintainers] New ImageMagick
Hi, On Thu, Sep 11, 2014 at 07:40:04PM +0200, Laurent Blume wrote: > On 11/09/2014 17:17, Kester Habermann wrote: > [snip] > >I've already reported this upstream, but no one has confirmed the problem: > >http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf > > Have you tried with some other tool using libtiff, just to make sure > it's specific to ImageMagick? I can display these images with xv and gimp. The only thing that is broken is imagemagick. Downgrading imagemagick to an older version (without changing anything else) fixed the problem. > That's a mistake of mine, I think I some point I pushed a stub for > the .so.1 libs, and that was wrong. I hadn't realized it had had > some effect. I need to find a way to rebuild that version. Can you > open a bug report on it to prod me? Done (Id: 5204). Regards Kester
Re: [csw-maintainers] New ImageMagick
On 11/09/2014 17:17, Kester Habermann wrote: [snip] I've already reported this upstream, but no one has confirmed the problem: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf Have you tried with some other tool using libtiff, just to make sure it's specific to ImageMagick? A completely unrelated issue also involving ImageMagick, it is actually more an emacs issue. GNU emacs can actually display images inline. Some images formats (likes fits are displayed using ImageMagick). It appears that the version of ImageMagick was changed without rebuilding emacs. This causes emacs to crash when opening an image file: $ emacs file.fits ld.so.1: emacs-24.3-athena: fatal: libMagickWand-6.Q16HDRI.so.1: open failed: No such file or directory ld.so.1: emacs-24.3-athena: fatal: relocation error: file /opt/csw/bin/emacs-24.3-athena: symbol MagickWandGenesis: referenced symbol not found killed emacs Note: DISPLAY has to be set to see the problem. ldd also shows the problem: kester@unstable10s [unstable10s]:~ > ldd -ur /opt/csw/bin/emacs | grep "not found" libMagickWand-6.Q16HDRI.so.1 => (file not found) libMagickCore-6.Q16HDRI.so.1 => (file not found) symbol not found: MagickGetException (/opt/csw/bin/emacs-24.3-athena) That's a mistake of mine, I think I some point I pushed a stub for the .so.1 libs, and that was wrong. I hadn't realized it had had some effect. I need to find a way to rebuild that version. Can you open a bug report on it to prod me? Laurent
Re: [csw-maintainers] New ImageMagick
Hello, I encountered a problem with ImageMagick, it would be great if someone could see if they can replicate the problem. The version of ImageMagick in Kiel (6.7.3) does not have the bug, I first noticed this witj the version in Bratislava (6.8.8) 16-bit greyscale images (fits or tiff) are not handled properly on Solaris/SPARC which is big endian. On Solaris/x86 (little endian) and Linux/x86 there is no problem. Also 8-bit greyscale images are not affected. I habe no idea if the issue is actually related to endianness. As it works on Solaris/x86, I conclude that it is not Solaris specific. To reproduce the problem: - view a 16-bit greyscale image (fits or tiff) using display - convert a a 16-bit greyscale image to a 8-bit format (e. g. as png) and view it In my case the fits-image is displayed (or converted to) completely black and the tiff-image to grey noise. I've already reported this upstream, but no one has confirmed the problem: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf A completely unrelated issue also involving ImageMagick, it is actually more an emacs issue. GNU emacs can actually display images inline. Some images formats (likes fits are displayed using ImageMagick). It appears that the version of ImageMagick was changed without rebuilding emacs. This causes emacs to crash when opening an image file: $ emacs file.fits ld.so.1: emacs-24.3-athena: fatal: libMagickWand-6.Q16HDRI.so.1: open failed: No such file or directory ld.so.1: emacs-24.3-athena: fatal: relocation error: file /opt/csw/bin/emacs-24.3-athena: symbol MagickWandGenesis: referenced symbol not found killed emacs Note: DISPLAY has to be set to see the problem. ldd also shows the problem: kester@unstable10s [unstable10s]:~ > ldd -ur /opt/csw/bin/emacs | grep "not found" libMagickWand-6.Q16HDRI.so.1 => (file not found) libMagickCore-6.Q16HDRI.so.1 => (file not found) symbol not found: MagickGetException (/opt/csw/bin/emacs-24.3-athena) Regards Kester
Re: [csw-maintainers] New ImageMagick
On 2013-09-07 8:17 PM, Joerg Schilling wrote: > Laurent Blume wrote: > >> On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi??ski wrote: >>> 2013/7/17 Laurent Blume Even with using -xO5, Studio is still about 10% slower than GCC4.8. >>> >>> Interesting. I'm curious what would be the GCC vs Studio benchmarks on >>> SPARC. >> >> Yes, me too. I still have a plan to run my bench on the M3000 at work, >> There's one box that's just for that. > > AFAIK, -fast is more than -xO5 > > did you test that? I tried -native (included in -fast). Studio crashed. GCC won by being about ∞× faster. Laurent ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] New ImageMagick
Laurent Blume wrote: > On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi??ski wrote: > > 2013/7/17 Laurent Blume > >> Even with using -xO5, Studio is still about 10% slower than GCC4.8. > > > > Interesting. I'm curious what would be the GCC vs Studio benchmarks on > > SPARC. > > Yes, me too. I still have a plan to run my bench on the M3000 at work, > There's one box that's just for that. AFAIK, -fast is more than -xO5 did you test that? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] New ImageMagick
On 2013-09-07 3:48 PM, Maciej (Matchek) Bliziński wrote: > 2013/7/17 Laurent Blume >> Even with using -xO5, Studio is still about 10% slower than GCC4.8. > > Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. Yes, me too. I still have a plan to run my bench on the M3000 at work, There's one box that's just for that. Laurent ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] New ImageMagick
2013/7/17 Laurent Blume > Even with using -xO5, Studio is still about 10% slower than GCC4.8. Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] New ImageMagick
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: GCC4SOS12U3 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 maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::. ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
