Switching to libjpeg-turbo?

ngoonee · 2010-07-16 16:12:57

Janax wrote:

ngoonee wrote:
Labello wrote:
would it be possible to somehow slowly migrate one package after another to *-turbo? so one package makes a start and pulls in *-turbo as dependency while the old libjpeg remains on the machine side-by-side with the faster one?
I don't think it works that way. Well yes, you could link against some new .so name, but having two side-by-side would just be confusing and a waste of space.
Seems to me that space shouldn't be much of an issue:
<snipped>
Granted, I don't have the size of libjpeg-turbo, as it's not installed, but unless it's significantly bigger, then <1MiB to keep this older version would only be a concern on the most frugal of setups.

If its unnecessary or otherwise undesirable (both of which seem to be to be the case here) any space is a waste of space .

What apps would best benefit from this libjpeg-turbo? Best way to push this through would be to have a libjpeg-turbo in the AUR along with a few apps which showcase its awesomeness.

wonder · 2010-07-16 16:26:36

you can't compile an app against libjpeg-turbo and the others to still link to the newer one. that app will crash if is using some packages that is linking to other version. (hint luxrender and wxgtk and his statically libpng 1.2) http://bugs.archlinux.org/task/19216

all or none

bananaoomarang · 2010-07-16 16:31:41

I'm not a big fan of this. I still remember the last libjpeg recompile fest… Which apps actually would benifit noticibly from this? 400% speed increace sounds amazing but it's a jpeg library for Heavan's sake. I say wait for fedora 14 and look at their increaces compared to our speed THEN consider this.

mythus · 2010-07-16 17:53:17

I personally think that having everyone have to deal with all the headaches for a change from the newer libjpeg that arch uses noww to the older libjpeg with the turbo patch/modification just for the increased speed in dealing with jpeg files is silly. I for one have no issue dealing with jpeg files and I have a feeling that the speed increase would seem almost negligible for me. I have a feeling that this would only be of a large benifit to those who use and deal with jpegs on a daily basis.

That said, what is stopping you from recompiling your system using abs to use the libjpeg-turbo? That way you can have fun with it and save the rest of us from having to mess with such a messy 'upgrade'...

I still remember the fun times of the last libjpeg upgrade *shudders*...

Allan · 2010-07-16 22:15:29

I am not going to touch this until at least libjpeg-9 is release at which point we will need the big rebuild anyway. But I will have to access how much of an impact the lost feature of downgrading to being compatible with a 12 year old release has. There are quite a few new features being added in the "old" libjpeg.

bananaoomarang · 2010-07-17 19:34:49

Allan wrote:

I am not going to touch this until at least libjpeg-9 is release at which point we will need the big rebuild anyway. But I will have to access how much of an impact the lost feature of downgrading to being compatible with a 12 year old release has. There are quite a few new features being added in the "old" libjpeg.

Well if we are having a rebuild then anyway, just wait for libjpeg-9 but what the heck we're arguing about a JPEG library. Does anyone need speed increaces here in a jpeg library? If so, you're probably in the minority, recompile your own system.

Kale · 2010-07-23 06:10:35

I did some speed testing on 32-bit Atom laptop with 10mpix image:

                         version 6b  27-Mar-1998       version 8b  16-May-2010       Libjpeg-turbo 1.0.0       
djpeg                            1.34 sec                     1.43 sec                   0.47 sec       
djpeg -dct fast                  1.25 sec                     1.39 sec                   0.44 sec
djpeg -dct float                 1.62 sec                     1.57 sec                   0.51 sec
djpeg -fast                      1.01 sec                     1.05 sec                   0.41 sec
djpeg -scale 1/2                 0.64 sec                     0.60 sec                   0.37 sec
djpeg -scale 1/4                 0.42 sec                     0.34 sec                   0.33 sec
djpeg -scale 1/8                 0.22 sec                     0.28 sec                   0.23 sec
                          
cjpeg -q 92                      1.48 sec                    1.75 sec                    0.52 sec
cjpeg -optimize -q 92            1.72 sec                    1.98 sec                    0.76 sec
cjpeg -progressive -q 92         3.40 sec                    3.53 sec                    2.46 sec
cjpeg -dct float -optimize -q 92 1.93 sec                    2.04 sec                    0.80 sec
cjpeg -dct fast -q 92            1.37 sec                    1.68 sec                    0.51 sec

Libjepg-turbo seems to be about 2-3 times faster than libjepg in most of the cases.

bananaoomarang wrote:

Does anyone need speed increaces here in a jpeg library? If so, you're probably in the minority, recompile your own system.

1.4 sec to decode 10mpix JPEG is slow IMO.

Allan · 2010-07-23 06:40:59

Just as an FYI, the developer said that libjpeg-turbo-1.1 aims to be compatibe with libjpeg-8b which is what we are currently using.

markg85 · 2010-08-12 21:30:45

Allan wrote:

Just as an FYI, the developer said that libjpeg-turbo-1.1 aims to be compatibe with libjpeg-8b which is what we are currently using.

Could you post a link where you've read that? Can't find that in the libjpeg-turbo mailing list..
I wonder if there is a libpng alternative that's faster... ^_^

Last edited by markg85 (2010-08-12 21:37:47)

Vamp898 · 2010-08-13 13:08:46

i maybe try it on my Gentoo partition^^ after installing the libjpeg-turbo package a revdep-rebuild should rebuild all needed packages.

But how can i benchmark the speed?

Allan · 2010-08-13 23:18:52

markg85 wrote:

Allan wrote:
Just as an FYI, the developer said that libjpeg-turbo-1.1 aims to be compatibe with libjpeg-8b which is what we are currently using.
Could you post a link where you've read that? Can't find that in the libjpeg-turbo mailing list..
I wonder if there is a libpng alternative that's faster... ^_^

Look in the sourceforge bug tracker under feature requests.

cf8 · 2010-11-29 21:09:57

So. Now libjpeg-turbo-svn is compatible with libjpeg-8. I've switched to it already. Works like a charm for now.

Allan · 2010-11-30 00:09:48

Completely? I hear reports that there are a lot of crashes. In particular chromium.

Anyway, I am going to put it in [testing] to check this once the next release is made.

ngoonee · 2010-11-30 01:46:34

libjpeg rebuild. Should be as fun as the last one

jarryson · 2010-11-30 02:49:35

i already use libjpeg-turbo for a while, compiled with "--prefix=/usr --with-jpeg8" and replaced libjpeg completely, and everything seems fine.

bangkok_manouel · 2010-11-30 03:06:02

last i checked, building firefox against libjpeg-turbo resulted in a "dead" binary so i had to use mozilla libjpeg. it defeated the point of faster porn.

jarryson · 2010-11-30 03:35:41

i am using libjpeg-turbo and firefox 3.6.12 witch compiled myself

i did a test too:
1.download http://media.xiph.org/BBB/BBB-1080-png/ … _01065.png
2.use gimp to resize it to about 5000x2813 and save it to ppm format
3.use the following commands

for i in {1..50}; do /usr/bin/time -f %e cjpeg big_buck_bunny_01065.ppm > /dev/null; done
for i in {1..50}; do /usr/bin/time -f %e djpeg big_buck_bunny_01065.jpg > /dev/null; done

i have to copy the result by hand cause i don't know how to save them to a file or a value. and then calculate them.

the result is(the total time):
arch official libjpeg: djpeg 47.98s ejpeg 70.48
turbo libjpeg: djpeg 13.64 ejpeg 20.67

and my cpu is AMD turion MT-34, 1.8Ghz witch is very old. i am using libjpeg-turbo and replaced libjpeg completely.

AugustePop · 2010-11-30 06:10:25

According to libjpeg-turbo's home page, it is "a derivative of libjpeg for x86 and x86-64 processors which uses SIMD instructions (MMX, SSE2, etc.)" IIUC, this means libjpeg-turbo is simply a rewrite of libjpeg in some functions with explicit assembly code optimizations.

If we set our CFLAGS in makepkg.conf to include "-march=native -mtune=native -O3" and recompile libjpeg from abs, will this achieve a similar speed boost as libjpeg-turbo?

If libjpeg-turbo is going to enter some of the official repository, it will be compiled against all i686 CPUs, will it be still possible to use the assemblies included in the libjpeg-turbo source?

EDIT: I tried the CFLAGS switch and get similar results. Seems it is more than a simple compiler switch...

Last edited by AugustePop (2010-11-30 06:54:07)

jarryson · 2010-11-30 07:44:15

of course it would not be related to CFLAGS or something, compiler optimization won't result such big different.

Neuro · 2011-02-15 12:23:39

I just installed libjpeg-turbo from AUR to replace libjpeg and I must say, that the speed increase in digikam is tremendous. Especially processing large pictures (12mpx). viewing them and generating thumbnails is instantaneous.

Other stuff, including Firefox (4.0beta11), work without problems.

kokoko3k · 2011-02-15 13:24:01

Just tried libjpeg-turbo-1.0.90-1 from aur.
Gwenview, firefox and chromium 'seems' to work without issue.
Hoping there will be no surprise and not to forgot what have i done in the case something will go wrong

Lothium · 2011-02-15 13:24:13

Ok this sounds really great. And you can use all your other applications without recompiling them and get performance improvements?

Best regards!

Edit: Ok, I also installed it from AUR, restarted and all seems to work fine atm. If I recognize any errors, I'll post it here.

Last edited by Lothium (2011-02-15 13:57:44)

Allan · 2011-02-15 21:00:48

Once the stable libjpeg-turbo-1.1 is released, I will be putting this in [testing] to replace libjpeg.

wonder · 2011-02-15 21:12:27

Allan wrote:

Once the stable libjpeg-turbo-1.1 is released, I will be putting this in [testing] to replace libjpeg.

since when we are using forks?

Allan · 2011-02-15 21:20:45

Is that a serious question? From the top of my head, since procinfo-ng, util-linux-ng, syslog-ng, libreoffice, openjdk6, cloog-ppl, man-db, mlocate...

Basically any time it is the better option.

Arch Linux

#26 2010-07-16 16:12:57

Re: Switching to libjpeg-turbo?

#27 2010-07-16 16:26:36

Re: Switching to libjpeg-turbo?

#28 2010-07-16 16:31:41

Re: Switching to libjpeg-turbo?

#29 2010-07-16 17:53:17

Re: Switching to libjpeg-turbo?

#30 2010-07-16 22:15:29

Re: Switching to libjpeg-turbo?

#31 2010-07-17 19:34:49

Re: Switching to libjpeg-turbo?

#32 2010-07-23 06:10:35

Re: Switching to libjpeg-turbo?

#33 2010-07-23 06:40:59

Re: Switching to libjpeg-turbo?

#34 2010-08-12 21:30:45

Re: Switching to libjpeg-turbo?

#35 2010-08-13 13:08:46

Re: Switching to libjpeg-turbo?

#36 2010-08-13 23:18:52

Re: Switching to libjpeg-turbo?

#37 2010-11-29 21:09:57

Re: Switching to libjpeg-turbo?

#38 2010-11-30 00:09:48

Re: Switching to libjpeg-turbo?

#39 2010-11-30 01:46:34

Re: Switching to libjpeg-turbo?

#40 2010-11-30 02:49:35

Re: Switching to libjpeg-turbo?

#41 2010-11-30 03:06:02

Re: Switching to libjpeg-turbo?

#42 2010-11-30 03:35:41

Re: Switching to libjpeg-turbo?

#43 2010-11-30 06:10:25

Re: Switching to libjpeg-turbo?

#44 2010-11-30 07:44:15

Re: Switching to libjpeg-turbo?

#45 2011-02-15 12:23:39

Re: Switching to libjpeg-turbo?

#46 2011-02-15 13:24:01

Re: Switching to libjpeg-turbo?

#47 2011-02-15 13:24:13

Re: Switching to libjpeg-turbo?

#48 2011-02-15 21:00:48

Re: Switching to libjpeg-turbo?

#49 2011-02-15 21:12:27

Re: Switching to libjpeg-turbo?

#50 2011-02-15 21:20:45

Re: Switching to libjpeg-turbo?

Board footer