Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-24 Thread Samuli Suominen

On 04/23/2012 10:40 PM, Chí-Thanh Christopher Nguyễn wrote:

Matt Turner schrieb:

It's not that they're not supported, just that libjpeg-turbo doesn't
have optimized routines for them. It'll still run fine. (Check the
keywords, you'll see that it's stabilized.)


And on those platforms it will run equally fast or faster or slower?


Best regards,
Chí-Thanh Christopher Nguyễn



based on what i've seen on mailinglists wrt libjpeg-turbo upstream:

mostly equally, but due to later non-assembly improvements in IJG's 
jpeg, in some cases, a bit slower at least in 1.2.0 release of libjpeg-turbo
but nothing anyone should be worried over about, as those changes are 
reviewed and/or in process of being reviewed and backported on as needed 
basis



(almost left this message unsent because i'm totally lazy to dig up the 
references for above, sorry)


- Samuli



[gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Samuli Suominen

I don't really think this is necessary, but some people seem to.

Looks fine?

- Samuli
Title: The default JPEG implementation is libjpeg-turbo
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*

libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
SIMD instructions to accelerate baseline JPEG compression/decompression by
about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
has numerous enhancements.

All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo

From here on out media-libs/jpeg:0 is only used as a fallback and at the time
of writing this news item, libjpeg-turbo has no known bugs that would require
using it.


Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Ulrich Mueller
 On Mon, 23 Apr 2012, Samuli Suominen wrote:

 I don't really think this is necessary, but some people seem to.
 Looks fine?

 Title: The default JPEG implementation is libjpeg-turbo

Too long. GLEP 42 allows a maximum of 44 characters only.

 Author: Samuli Suominen ssuomi...@gentoo.org
 Content-Type: text/plain
 Posted: 2012-04-23
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Installed: =media-libs/jpeg-8*

 libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
 SIMD instructions to accelerate baseline JPEG compression/decompression by
 about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
 has numerous enhancements.

I'd suggest to use our standard names for these architectures, i.e. x86,
amd64, and arm.

 All users are recommended to migrate:

 # emerge -C media-libs/jpeg:0
 # emerge -1 media-libs/libjpeg-turbo

 From here on out media-libs/jpeg:0 is only used as a fallback and at the time
 of writing this news item, libjpeg-turbo has no known bugs that would require
 using it.

Maybe avoid the word From at the beginning of the line. eselect news
will escape it properly, but it looks somewhat ugly.

And please wrap the body text at 72 chars (GLEP 42 says so).

Ulrich



Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Samuli Suominen

On 04/23/2012 01:43 PM, Ulrich Mueller wrote:

On Mon, 23 Apr 2012, Samuli Suominen wrote:



I don't really think this is necessary, but some people seem to.
Looks fine?



Title: The default JPEG implementation is libjpeg-turbo


Too long. GLEP 42 allows a maximum of 44 characters only.


Author: Samuli Suominenssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*



libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
SIMD instructions to accelerate baseline JPEG compression/decompression by
about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
has numerous enhancements.


I'd suggest to use our standard names for these architectures, i.e. x86,
amd64, and arm.


All users are recommended to migrate:



# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo



 From here on out media-libs/jpeg:0 is only used as a fallback and at the time
of writing this news item, libjpeg-turbo has no known bugs that would require
using it.


Maybe avoid the word From at the beginning of the line. eselect news
will escape it properly, but it looks somewhat ugly.

And please wrap the body text at 72 chars (GLEP 42 says so).


Thanks Ulrich. See attachment as draft #2.
Title: The default JPEG implementation
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*

libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2,
and NEON SIMD instructions to accelerate baseline JPEG
compression/decompression by about 2-4x on amd64, arm and x86
platforms. It is based on libjpeg/SIMD but has numerous enhancements.

All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo

media-libs/jpeg:0 will be left in tree as a fallback implementation
in case libjpeg-turbo will become unmaintained or suffers from issues
caused by, for example, upgrading the toolchain.


Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Richard Yao
On 04/23/12 06:16, Samuli Suominen wrote:
 I don't really think this is necessary, but some people seem to.
 
 Looks fine?
 
 - Samuli

What is the plan for platforms that are not supported by libturbo?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Matt Turner
On Mon, Apr 23, 2012 at 7:58 AM, Richard Yao r...@cs.stonybrook.edu wrote:
 What is the plan for platforms that are not supported by libturbo?

It's not that they're not supported, just that libjpeg-turbo doesn't
have optimized routines for them. It'll still run fine. (Check the
keywords, you'll see that it's stabilized.)



Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Samuli Suominen

On 04/23/2012 02:58 PM, Richard Yao wrote:

On 04/23/12 06:16, Samuli Suominen wrote:

I don't really think this is necessary, but some people seem to.

Looks fine?

- Samuli


What is the plan for platforms that are not supported by libturbo?



Matt's reply is accurate.



Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Walter Dnes
On Mon, Apr 23, 2012 at 02:22:53PM +0300, Samuli Suominen wrote

 All users are recommended to migrate:
 
 # emerge -C media-libs/jpeg:0
 # emerge -1 media-libs/libjpeg-turbo

  How about mentioning revdep-rebuild in the instructions?

-- 
Walter Dnes waltd...@waltdnes.org



Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Chí-Thanh Christopher Nguyễn
Matt Turner schrieb:
 It's not that they're not supported, just that libjpeg-turbo doesn't
 have optimized routines for them. It'll still run fine. (Check the
 keywords, you'll see that it's stabilized.)

And on those platforms it will run equally fast or faster or slower?


Best regards,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

2012-04-23 Thread Mike Frysinger
On Monday 23 April 2012 15:19:31 Walter Dnes wrote:
 On Mon, Apr 23, 2012 at 02:22:53PM +0300, Samuli Suominen wrote
 
  All users are recommended to migrate:
  
  # emerge -C media-libs/jpeg:0
  # emerge -1 media-libs/libjpeg-turbo
 
   How about mentioning revdep-rebuild in the instructions?

no need as they should be ABI forward compatible (if you consider turbo to be 
the superset)
-mike


signature.asc
Description: This is a digitally signed message part.