jpeg SIMD (MMX) success!

[aklettke]

Knniggett,

Actually, I was able to build and successfully implement the shared library on Debian using nasm 2.03, although my box does have glibc-2.7.

Anyway, it can't hurt just to TRY the compile by just using "make". The new shared libraries will be in the newly-created .libs/ directory, and you can test them out to your heart's content.

[knight-of-ni]

I failed to previously mention that I tried to compile it anyway.
The configure script fails when it tests for certain functionality of nasm.

What I will likely try next is to force the upgrade to nasm 2.05 w/o satisfying the glibc-2.7 dependency. I'm not optimistic it will work, but I believe it to be worth a shot.

I'm open to any other ideas...

[knight-of-ni]

UPDATE:
I downloaded nasm-0.99.06 x86_64 rpm from the nasm website. This particular version is old enough to not have the glibc-2.7 dependency, but more importantly it is new enough to allow the configure script to run w/o an error.

The modified libjpeg libraries are now configured and successfully compiled on my 64bit CentOS system! I will test them on a future date.

Thanks aklettke for letting us about these libraries.

[knight-of-ni]

Me again...
I took the opportunity to install the modified jpeg libraries on my system today. Initially everything appeared to work, and the overall system load went from ~.57 down to ~.12 on my quad core system.

Upon closer inspection, however, I noticed that thumbnails were no longer visible in Zoneminder (everything else appeared to work). That's when I looked azt /var/log/messages and saw the following errors:

Code: Select all

53 bauerhaus kernel: jpegtopnm[10083]: segfault at 0000000051f72490 rip 00002ac0d5ec4144 rsp 0000000051f72490 error 4
Feb  3 10:07:53 bauerhaus kernel: jpegtopnm[10087]: segfault at 000000007f57d780 rip 00002aba89416144 rsp 000000007f57d780 error 4
Feb  3 10:07:53 bauerhaus kernel: jpegtopnm[10091]: segfault at 000000006be49290 rip 00002b0413c7a144 rsp 000000006be49290 error 4
Feb  3 10:07:53 bauerhaus kernel: jpegtopnm[10095]: segfault at 0000000086bbde30 rip 00002abd0930b144 rsp 0000000086bbde30 error 4
Feb  3 10:07:53 bauerhaus kernel: jpegtopnm[10099]: segfault at 00000000332d0d20 rip 00002ac71651f144 rsp 00000000332d0d20 error 4
Feb  3 10:07:53 bauerhaus kernel: jpegtopnm[10103]: segfault at 000000009d84ba30 rip 00002b82859c1144 rsp 000000

After seeing those, I went ahead and reinstalled the original jpeg libraries which made the the errors go away and the thumbnails return.

I don't know if this is because I compiled with nasm .99 instead of 2.05 or perhaps because I'm not using Intel cpus???

I'm running CentOS 5.4 which is supposed to be a binary equivalent of REHL 5.4.

Don't know. Anyway, unless someone has got any suggestions, I'm as far as I can get for the moment.

[knight-of-ni]

Eureka! Got it.

But before I show the steps I took to roll my own, you probably just want to read this thread as the author now has precompiled binaries available for both rpm and deb based systems:
http://www.zoneminder.com/forums/viewto ... 0023#60023

If you are interested in doing things the hard way, here are the steps I took to compile on my 64bit CentOS system:

• 1) Download boost-1.34.1-13.fc9.src.rpm from any Fedora 9 repository
  2) Rebuild it by issuing this command as root: rpmbuild --rebuild boost-1.34.1-13.fc9.src.rpm
  3) Install the newly created rpm (look here for it: /usr/src/redhat/RPMS)
  4) Download the nasm 2.07 source rpm from the nasm website: http://www.nasm.us/pub/nasm/releasebuilds/2.07/linux/
  5) IMPORTANT: Verify the package "texinfo" is installed on your system as the next step will fail w/o it.
  6) Issue this command as root: rpmbuild --rebuild nasm-2.07-1.src.rpm
  7) Now install that rpm.
  8) Download the source tarball from here: http://sourceforge.net/projects/libjpeg-turbo/files/
  9) Run .confgure
  10) Now run "make rpm"
  11) Install the newly created rpm. Files will be installed under /usr/local (i.e. your original libjpeg files under /usr will not be overwritten)

[johnnytolengo]

is it there some easy guide how to install mmx in ubuntu 32bit?



thanks.

Jt

[knight-of-ni]

The author now has .deb files available for download on the libjpeg-turbo project website. That will be your best bet.

[ghetss261]

GREAT...
THANK YOU...

[bb99]

For anyone who can't implement this you can always download RDMelin's ZMLinuxOS live CD which implements mmx and see how he did it and the difference it makes. The CD is still available at Linuxtracker.org under the Zoneminder category.

[watou]

I know that ZM is now using libjpeg-turbo 1.0.0 (installed from libjpeg-turbo_1.0.0_amd64.deb) instead of the standard libjpeg on my AMD64 system, but I do not see any performance improvement.

Anyone else running Ubuntu 10.4 on an AMD64 have the same or different results?

[knight-of-ni]

I haven't tried the .deb file myself, but I would expect it to operate the same as when compiling from source.... namely, it installs itself under its own folder and doesn't overwrite your existing libjpeg library. Consequently, if you want to use the libjpeg-turbo library instead of the default, you have to tell your application (i.e. zoneminder) to do so.

Are you sure you have done that?

You may want to check out this thread if you have not already:
http://www.zoneminder.com/forums/viewto ... highlight=

I'm in the middle of a Ubuntu 10.04 AMD64 build. I was going to compile from source, but I can try the deb file first andsee what happens.

[watou]

Thank you, knnniggett.

I assume the Ubuntu package zoneminder_1.24.2-2build3_amd64.deb was built to dynamically link to libjpeg? Not finding a way to alter the LD_LIBRARY_PATH for ZoneMinder to put /opt/libjpeg-turbo/lib before /usr/lib, I put the libjpeg-turbo file /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0 in place of the one at /usr/lib, and there is no performance difference (I stopped ZM, did the file switch, ldconfig, restarted ZM, and rebooted on another occasion).

I verified that zma and zmc are 64-bit binaries, and that both the standard and turbo libjpeg.so files are 64-bit as well. I made no changes to any 32-bit libraries.

Did I brute-force the wrong file? Is the ZM .deb built by statically linking to libjpeg? Just not sure why I'm not seeing a difference in CPU consumption.

My system's uname -a output:

Linux getaway 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux

[knight-of-ni]

I don't have a 64bit Ubuntu machine in front of me at the moment to verify, but I think your library path should read /opt/libjpeg-turbo/lib64 not /opt/libjpeg-turbo/lib.

According to the readme file, here is the recommended way to test libjpeg-turbo:

export LD_LIBRARY_PATH=/opt/libjpeg-turbo/{lib}:$LD_LIBRARY_PATH

where {lib} can be lib, lib32, lib64, or lib/64, depending on the O/S and
architecture. I think it is lib64 for your case.

Execute the statement above just prior to starting zoneminder from a command prompt.

You might want to get your system back to a known good state prior to doing this.

[watou]

Thanks again for the suggestions.

I added /opt/libjpeg-turbo/lib64 to the front of my shell's LD_LIBRARY_PATH, but my shell had no LD_LIBRARY_PATH to begin with, and I also wonder if this would have any effect when issuing a start or restart with sudo /etc/init.d/zoneminder start , since the service's process chain does not include my shell process.

After doing this I did not see any change in processor usage in either zma or zmc.

When you get your Ubuntu/AMD64 system running, I would be curious to learn what your "before/after" results are.

Regards, watou

[Geoff]

I might be having a similar problem. I'm running Ubuntu 10.04 64-bit. I installed "libjpeg-turbo_1.0.0_amd64.deb" from here, added the line "export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64:$LD_LIBRARY_PATH" to /etc/init.d/zoneminder as specified in this thread, and restarted zoneminder. But it doesn't seem to have any effect on my CPU load. Maybe I installed the wrong package? I have an Intel processor.