Hi all,

I've faced an issue (#557550) which is much probably caused by a CPU which
doesn't support SSE2 instructions. I'm not sure about the best way to address
this. Any suggestion will be very welcome. Actually I can see the following
workarounds:

1) consider that most of CPUs support this flag, so tell the reporter to
compile the package by him/herself.

2) remove this specific flag during package building, ending with a
non-optimized software available for all users.

3) create a specific -sse2 (or -non-sse2) package.

4) ask the upstream to code runtime checks before using SSE2 specific
instructions (is that possible?).

For now, my choice is #1.

Btw, there is an old proposal [0] related to this subject but I have no ideia
how it's going.

[0] http://lists.debian.org/debian-devel/2003/06/msg01714.html


--
--------------------------------------------------------------------------------
.'`. Tiago Bortoletto Vaz GPG : 1024D/A504FECA
: :' : http://tiagovaz.org XMPP : tiago at jabber.org
`. `' tiago at {tiagovaz,debian}.org IRC : tiago at OFTC
`- Debian GNU/Linux - The Universal OS http://www.debian.org
--------------------------------------------------------------------------------

On 04.04.2010 22:29, Tiago Bortoletto Vaz wrote:

Hi all,

I've faced an issue (#557550) which is much probably caused by a CPU which
doesn't support SSE2 instructions. I'm not sure about the best way to address
this. Any suggestion will be very welcome. Actually I can see the following
workarounds:

1) consider that most of CPUs support this flag, so tell the reporter to
compile the package by him/herself.

Quite bad.




2) remove this specific flag during package building, ending with a
non-optimized software available for all users.

<have a look at the end of my mail>



3) create a specific -sse2 (or -non-sse2) package.

Sounds like too much work.



4) ask the upstream to code runtime checks before using SSE2 specific
instructions (is that possible?).

AFAIK it is possible.



For now, my choice is #1.

This is a bad decision.


The only architecture where you can assume, that all CPUs support MMX
and SSE{2} is amd64. So you can enable the optimizing flags only on this
arch.

I am also handling it this way in my packages.

--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer

E-Mail: pmatthaei@debian.org
patrick@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BB90113.2080600@debian.org">http://lists.debian.org/4BB90113.2080600@debian.org

Tiago Bortoletto Vaz <tiago@debian.org> writes:
> 1) consider that most of CPUs support this flag, so tell the reporter to
> compile the package by him/herself.

This is not acceptable and would make your package rc-buggy. Even though
it's called i386 and in fact only supports i486, we are not in a state
where we want to ditch support for all pre-Pentium 3 CPUs.

> 2) remove this specific flag during package building, ending with a
> non-optimized software available for all users.
>
> 3) create a specific -sse2 (or -non-sse2) package.
>
> 4) ask the upstream to code runtime checks before using SSE2 specific
> instructions (is that possible?).
>
> For now, my choice is #1.

It's not an option, so you will need to do something else.

Marc
--
BOFH #441:
Hash table has woodworm

On 04/04/10 16:29, Tiago Bortoletto Vaz wrote:

Hi all,

I've faced an issue (#557550) which is much probably caused by a CPU which
doesn't support SSE2 instructions. I'm not sure about the best way to address
this. Any suggestion will be very welcome. Actually I can see the following
workarounds:

1) consider that most of CPUs support this flag, so tell the reporter to
compile the package by him/herself.

2) remove this specific flag during package building, ending with a
non-optimized software available for all users.

3) create a specific -sse2 (or -non-sse2) package.

4) ask the upstream to code runtime checks before using SSE2 specific
instructions (is that possible?).


5) Build twice, install both binaries in /usr/lib/package, and ship a
wrapper script that calls the appropriate binary depending on the CPU flags.


Saludos,
Felipe Sateler



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: hpb1i7$e9b$1@dough.gmane.org">http://lists.debian.org/hpb1i7$e9b$1@dough.gmane.org

On Sun, 2010-04-04 at 17:29 -0300, Tiago Bortoletto Vaz wrote:
> Hi all,
>
> I've faced an issue (#557550) which is much probably caused by a CPU which
> doesn't support SSE2 instructions. I'm not sure about the best way to address
> this. Any suggestion will be very welcome. Actually I can see the following
> workarounds:
>
> 1) consider that most of CPUs support this flag, so tell the reporter to
> compile the package by him/herself.

This is the wrong answer; we officially support CPUs dating back to 486.

> 2) remove this specific flag during package building, ending with a
> non-optimized software available for all users.
>
> 3) create a specific -sse2 (or -non-sse2) package.

Both acceptable.

> 4) ask the upstream to code runtime checks before using SSE2 specific
> instructions (is that possible?).
[...]

This is the best. Also there are libraries like liboil that implement
various common functions that can benefit from SIMD extensions and that
automatically select the right version at run-time. Perhaps this
package can use that?

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

On Sun, Apr 04, 2010 at 10:53:09PM +0100, Ben Hutchings wrote:
> On Sun, 2010-04-04 at 17:29 -0300, Tiago Bortoletto Vaz wrote:
> > Hi all,
> >
> > I've faced an issue (#557550) which is much probably caused by a CPU which
> > doesn't support SSE2 instructions. I'm not sure about the best way to address
> > this. Any suggestion will be very welcome. Actually I can see the following
> > workarounds:
> >
> > 1) consider that most of CPUs support this flag, so tell the reporter to
> > compile the package by him/herself.
>
> This is the wrong answer; we officially support CPUs dating back to 486.
>
> > 2) remove this specific flag during package building, ending with a
> > non-optimized software available for all users.
> >
> > 3) create a specific -sse2 (or -non-sse2) package.
>
> Both acceptable.
>
> > 4) ask the upstream to code runtime checks before using SSE2 specific
> > instructions (is that possible?).
> [...]
>
> This is the best. Also there are libraries like liboil that implement
> various common functions that can benefit from SIMD extensions and that
> automatically select the right version at run-time. Perhaps this
> package can use that?

Thanks Ben and all others who showed me I was choosing the wrong way here. I
liked the idea of building an extra non-sse2 binary until the upstream
(hopefully) starts using a liboil(-like) library. If things go well I'll
document somewhere for future reference.

Regards,

--
--------------------------------------------------------------------------------
.'`. Tiago Bortoletto Vaz GPG : 1024D/A504FECA
: :' : http://tiagovaz.org XMPP : tiago at jabber.org
`. `' tiago at {tiagovaz,debian}.org IRC : tiago at OFTC
`- Debian GNU/Linux - The Universal OS http://www.debian.org
--------------------------------------------------------------------------------