LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 07-14-2008, 02:03 PM   #16
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928

Original Poster
Blog Entries: 2

Rep: Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301

Wow, you've really put some time into this issue, but it is interesting, all of that. I'll try to rebuild imagemagick to see if it will fix this. I don't use it too often (more often use GIMP), but maybe we will discover something

As for installing 32-bit on 64-bit, I don't really know. I know how to build for 32-bit from 64-bit, but you need plenty of compatibility libs to do that including 32-bit gcc.
 
Old 07-14-2008, 02:39 PM   #17
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197
Quote:
Originally Posted by H_TeXMeX_H View Post
I'll try to rebuild imagemagick to see if it will fix this.
I'm pretty sure just rebuilding wouldn't help. I used a Mepis build of a different version of ImageMagick than you used, yet had the same performance problem.

Then in Windows, the 64bit was faster.

The fact that 64bit was faster in Windows makes it unlikely (though not impossible) that the problem is in the source code.

That's why I think the problem is in the configure and/or make process.

If you just go through the standard build from source, I'm pretty sure you would get the same result.

I'm not sure what I would even try if I had time to rebuild from source (maybe look at the compile lines and try different compiler options, maybe try profiling).

If I knew where the bulk of the time was spent, I'm pretty good at reading the assembler code and figuring out what the compiler did wrong. I expect the only hard part of .jpg to .png conversion is doing the .png compression. But I'm not sure where to look to find the code that does .png compression.
 
Old 07-14-2008, 03:39 PM   #18
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928

Original Poster
Blog Entries: 2

Rep: Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301
Well, I rebuilt and tested imagemagick with little difference in the final times:

with Q8:
Code:
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m52.542s
user	1m52.235s
sys	0m0.283s
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m52.639s
user	1m52.272s
sys	0m0.326s
with Q32: (just wanted to see what would happen)
Code:
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m53.367s
user	1m52.507s
sys	0m0.838s
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m53.642s
user	1m52.693s
sys	0m0.894s
Q8, without X11 support (just for fun, I heard most distros were building with x support on, so I turned it off to see what would happen ... nothing)
Code:
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m52.597s
user	1m52.171s
sys	0m0.283s
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m52.595s
user	1m52.262s
sys	0m0.296s
Well, it remains unexplained. But I noticed that imagemagick needs a patch (libpng_mmx_patch_x86_64) to compile under 64-bit:
Code:
diff -Naur ImageMagick-6.2.7.orig/coders/png.c ImageMagick-6.2.7/coders/png.c
--- ImageMagick-6.2.7.orig/coders/png.c	2006-05-21 12:35:55.784852536 +0200
+++ ImageMagick-6.2.7/coders/png.c	2006-05-21 12:36:50.698504392 +0200
@@ -164,6 +164,8 @@
 #define PNG_MAX_UINT (png_uint_32) 0x7fffffffL
 #endif
 
+#undef PNG_ASSEMBLER_CODE_SUPPORTED
+
 /*
   Constant strings for known chunk types.  If you need to add a chunk,
   add a string holding the name here.   To make the code more
I'm assuming that prevents use of assembler to optimize libpng. Maybe that's reason ?

EDIT: No this is not the reason, I did not apply the patch and i got with Q16:
Code:
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m52.849s
user	1m52.346s
sys	0m0.485s
bash-3.1$ time convert mapGWtyria.jpg mapGWtyria.png

real	1m52.916s
user	1m52.370s
sys	0m0.529s

Last edited by H_TeXMeX_H; 07-14-2008 at 03:59 PM.
 
Old 07-14-2008, 06:24 PM   #19
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197
Quote:
Originally Posted by H_TeXMeX_H View Post
I'm assuming that prevents use of assembler to optimize libpng. Maybe that's reason ?
I'm pretty sure you have identified the reason. To be really sure, I'd need to check the source code for pnggccrd.c as well as figuring out how pnggcrd.c fits into Imagemagick.

Quote:
EDIT: No this is not the reason, I did not apply the patch and i got with Q16
I'm partially guessing here, but I think the assembler code is only available for 32bit x86. The patch only modified code that managed some details of the use of the asm code. I assume it covered some temporary bug (in attempting to use a nonexistent feature). In 64bit mode, apparently no one wrote the hand optimized asm code so it doesn't exist to use. The newer version of png.c specifically tests for defined(__i386__) and doesn't try to manage the asm code otherwise.

I never thought there was much hand optimized asm code in anything written for Linux. The general philosophy seems to be trust the compiler and code for portability. I guess pnggccrd is an exception.

So one more reason 32bit may be better than 64bit is someone took the time to write some hand optimized asm (of course it can go the other way as well, but probably hasn't done so much yet).

Edit: Then again, maybe I'm just confused.

My performance test from this morning didn't reproduce!

Back on the same Linux system: 3.2GHz dual core AMD, 64bit Mepis 7, ImageMagick 6.2.4 08/28/07 Q16, 64bit and 32bit builds. Same input .jpg file. Everything the same, except the results. I ran it twice each this morning with variation of under a second between the two runs. Now I ran it several times, still with variation under a second, so this isn't some random run to run variation.

This morning, 32bit was a little over 3 minutes and 64bit was a little under 4 minutes (don't have exact numbers).

Now 32bit is 155 seconds and 64bit is 125 seconds. 64 bit is faster than 32 bit, just as it was on Windows, not as you'd expect for hand optimized asm vs. c. Linux running on a 3.2GHz AMD is faster than Windows on a 2.3GHz Intel, just as I'd expect, not as I saw this morning.

So, IIUC, you are still reproducing the behavior of 32bit faster than 64bit. But I'm not.

Last edited by johnsfine; 07-14-2008 at 07:15 PM.
 
Old 07-15-2008, 03:13 AM   #20
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928

Original Poster
Blog Entries: 2

Rep: Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301
How odd, did you do anything to change it ? Or it just magically changed overnight ? This is getting confusing, perhaps I should just use a different program.
 
Old 07-15-2008, 03:39 AM   #21
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928

Original Poster
Blog Entries: 2

Rep: Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301Reputation: 1301
Hey, I think I found the answer: imagemagick is quite inefficient.

I did the conversion a different way, and it's 4 times faster than imagemagick.
Code:
bash-3.1$ time jpegtopnm mapGWtyria.jpeg | pnmtopng > map.png
jpegtopnm: WRITING PPM FILE

real	0m33.147s
user	0m32.579s
sys	0m0.508s
bash-3.1$ time jpegtopnm mapGWtyria.jpeg | pnmtopng > map.png
jpegtopnm: WRITING PPM FILE

real	0m33.050s
user	0m32.494s
sys	0m0.545s
bash-3.1$ time jpegtopnm mapGWtyria.jpeg | pnmtopng > map.png
jpegtopnm: WRITING PPM FILE

real	0m33.165s
user	0m32.572s
sys	0m0.523s
bash-3.1$ time convert mapGWtyria.jpeg mapGWtyria.png 

real	1m53.021s
user	1m52.424s
sys	0m0.496s
That's good, now I can uninstall imagemagick.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
64 bit cpu-64 bit Ubuntu-are there 32 bit app issues? sofasurfer Ubuntu 7 04-09-2014 02:02 PM
Differences in performance for 32-bit and 64-bit software exceed1 Linux - General 10 03-14-2008 04:50 PM
How to install 32-bit software in 64-bit system jshih Linux - Kernel 5 04-14-2007 12:26 PM
32 bit or 64 bit install - is 32 bit easier for a newbie? dms05 Linux - Newbie 3 05-19-2006 03:05 PM
Using 32 bit software on 64 bit Kantonix rahish Linux - Newbie 1 02-24-2006 10:27 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 02:36 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration