Re: [arch-dev-public] i686 and SSE2

2016-09-28 Thread Daniel Micay via arch-dev-public
On Wed, 2016-09-28 at 21:12 +0200, Bartłomiej Piotrowski wrote:
> On 2016-09-28 05:10, Allan McRae wrote:
> > 
> > The most pressing issue is #1.  So lets get back to the issue of the
> > increasing amount of software requiring SSE2.  How do we solve this?
> 
> I thought about it, and I lean toward dropping i686 completely. The
> only
> thing that SSE2 requirement will do is even further decrease of i686
> users.
> 
> Because we will deprecate i686 eventually, I don't think we should
> beat
> around the bush. There is no benefit of switching to i786 in terms of
> time spent for building packages. Even our completely old pkgstats
> data
> say that 8.53% use 32 bit Arch, while only 4.21% of submissions came
> from systems with amd64-incompatible CPU. It's just not worth the
> hassle.
> 
> Bartłomiej

Marking it as deprecated everywhere with a timeline to officially
dropping it as a first tier architecture would be nice. Can give people
enough time to work out a way of doing automated builds, even official
ones if there are developers / trusted users interested in doing it. It
isn't going to get automated away without making it clear that it will
be dropped at a certain date whether or not that's implemented.

Very few of us are actually testing on i686 anymore. It might as well
all be automated by the people still interested in it.

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


Re: [arch-dev-public] i686 and SSE2

2016-09-28 Thread Bartłomiej Piotrowski
On 2016-09-28 05:10, Allan McRae wrote:
> The most pressing issue is #1.  So lets get back to the issue of the
> increasing amount of software requiring SSE2.  How do we solve this?

I thought about it, and I lean toward dropping i686 completely. The only
thing that SSE2 requirement will do is even further decrease of i686 users.

Because we will deprecate i686 eventually, I don't think we should beat
around the bush. There is no benefit of switching to i786 in terms of
time spent for building packages. Even our completely old pkgstats data
say that 8.53% use 32 bit Arch, while only 4.21% of submissions came
from systems with amd64-incompatible CPU. It's just not worth the hassle.

Bartłomiej



signature.asc
Description: OpenPGP digital signature


Re: [arch-dev-public] i686 and SSE2

2016-09-28 Thread Andreas Radke
Am Wed, 28 Sep 2016 13:10:30 +1000
schrieb Allan McRae :

> It would be "simple" to add an SSE2 detection hook into the filesystem
> package that aborts any pacman transaction attempting to install a
> list of packages on i686 systems without SSE2 support.  Is that a
> viable solution?
> 
> Any other suggestions?
> 
> Allan

Is there a list of the "increasing amount" of packages that require
SSE2? If this is still limited to a few packages I'd be fine with such
a SSE2 blocking hook for the time until we drop that architecture.

-Andy


pgpC50P2tkusE.pgp
Description: Digitale Signatur von OpenPGP


Re: [arch-dev-public] i686 and SSE2

2016-09-27 Thread Allan McRae
Just to summarise what I have taken from discussion surrounding this so
it does not stagnate:

1) Changing i686 to either i686 + SSE or i786 is not seen to be a good idea

2) There are suggestions we look into providing something more optimised
than x86_64, but it not clear what platform(s) people are looking to
support.

3) Autobuilding more the optimised platforms would be great, but runs
into the same issue we have with database signing and security of such a
key.



The most pressing issue is #1.  So lets get back to the issue of the
increasing amount of software requiring SSE2.  How do we solve this?

It would be "simple" to add an SSE2 detection hook into the filesystem
package that aborts any pacman transaction attempting to install a list
of packages on i686 systems without SSE2 support.  Is that a viable
solution?

Any other suggestions?

Allan


Re: [arch-dev-public] i686 and SSE2

2016-09-21 Thread Tobias Powalowski via arch-dev-public
I agree with Andreas here.

greetings
tpowa

2016-09-20 19:38 GMT+02:00 Andreas Radke :

> Am Mon, 19 Sep 2016 23:30:35 +0200
> schrieb Sven-Hendrik Haase :
>
> > This would probably be a good time to get a fully automated building
> > setup going. We certainly have the hardware for it now.
>
> +1
>
> > >> Another option could be to keep i686 and x86_64 as is, and
> > >> introduce new architectures with automatically built optimised
> > >> packages for i686 + SSE2 or SSE3, and for x86_64 + SSE4.2 or AVX.
> > >> This is something similar to your option #4, but keeps the
> > >> compatibility with all existing systems.
> > >
> > > Yes!
>
> If we want to limit our offer to two binary architectures I'm for
> x86_64 maybe with SSE3 enabled (kicks out oldest Athlon XPs) and keep
> i686 with least features needed for full compatibility. I could even
> live with i586 for fallback. Though I'd prefer to
> fully drop 32bit and rather leave it up to the community if they want
> to keep it alive any longer.
>
> -Andy
>



-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org


Re: [arch-dev-public] i686 and SSE2

2016-09-20 Thread Andreas Radke
Am Mon, 19 Sep 2016 23:30:35 +0200
schrieb Sven-Hendrik Haase :

> This would probably be a good time to get a fully automated building
> setup going. We certainly have the hardware for it now.

+1

> >> Another option could be to keep i686 and x86_64 as is, and
> >> introduce new architectures with automatically built optimised
> >> packages for i686 + SSE2 or SSE3, and for x86_64 + SSE4.2 or AVX.
> >> This is something similar to your option #4, but keeps the
> >> compatibility with all existing systems.  
> >
> > Yes!

If we want to limit our offer to two binary architectures I'm for
x86_64 maybe with SSE3 enabled (kicks out oldest Athlon XPs) and keep
i686 with least features needed for full compatibility. I could even
live with i586 for fallback. Though I'd prefer to
fully drop 32bit and rather leave it up to the community if they want
to keep it alive any longer.

-Andy


pgpogRIjpYHj1.pgp
Description: Digitale Signatur von OpenPGP


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Allan McRae
On 20/09/16 04:30, Ike Devolder via arch-dev-public wrote:
> Someone mentioned AVX2, but it seems there is still a patch needed for
> glibc. Solus added it very recently https://dev.solus-project.com/T503
> and they have taken it from Clear Linux.

Nothing needs done for glibc to use AVX.  It already does when present.

Allan


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Sven-Hendrik Haase
This would probably be a good time to get a fully automated building
setup going. We certainly have the hardware for it now.

On Mon, Sep 19, 2016 at 11:12 PM, Gaetan Bisson  wrote:
> [2016-09-19 20:57:01 +0200] Balló György via arch-dev-public:
>> 2016-09-19 15:34 GMT+02:00 Allan McRae :
>> >
>> > If we limit our choice based on your CPU, then we need to limit based on
>> > the other CPU mentioned in this thread.
>> >
>> > That should not be a consideration at all. What we need to do is think
>> > about what make our distribution worthy of being a distribution.
>> > Original the selling points were rolling release, vanilla packages and
>> > optimised binaries.  We have lost the latter.  Do we want to get it back?
>> >
>>
>> Another option could be to keep i686 and x86_64 as is, and introduce new
>> architectures with automatically built optimised packages for i686 + SSE2
>> or SSE3, and for x86_64 + SSE4.2 or AVX. This is something similar to your
>> option #4, but keeps the compatibility with all existing systems.
>
> Yes!
>
> And I vote to put you in charge of the legacy platforms so the rest of
> us can focus on building software that uses more than half of the
> transistors >90% of us own. Besides, you'll do a much better job at it
> than me, given it's been nearly five years I last tested an i686 binary.
>
> So I say we create a new architecture that includes all extensions
> available on >90% of currently available hardware, make that our primary
> architecture, and let people interested in legacy platforms figure out
> the rest of the plan.
>
> Cheers.
>
> --
> Gaetan


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Gaetan Bisson
[2016-09-19 20:57:01 +0200] Balló György via arch-dev-public:
> 2016-09-19 15:34 GMT+02:00 Allan McRae :
> >
> > If we limit our choice based on your CPU, then we need to limit based on
> > the other CPU mentioned in this thread.
> >
> > That should not be a consideration at all. What we need to do is think
> > about what make our distribution worthy of being a distribution.
> > Original the selling points were rolling release, vanilla packages and
> > optimised binaries.  We have lost the latter.  Do we want to get it back?
> >
> 
> Another option could be to keep i686 and x86_64 as is, and introduce new
> architectures with automatically built optimised packages for i686 + SSE2
> or SSE3, and for x86_64 + SSE4.2 or AVX. This is something similar to your
> option #4, but keeps the compatibility with all existing systems.

Yes!

And I vote to put you in charge of the legacy platforms so the rest of
us can focus on building software that uses more than half of the
transistors >90% of us own. Besides, you'll do a much better job at it
than me, given it's been nearly five years I last tested an i686 binary.

So I say we create a new architecture that includes all extensions
available on >90% of currently available hardware, make that our primary
architecture, and let people interested in legacy platforms figure out
the rest of the plan.

Cheers.

-- 
Gaetan


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Balló György via arch-dev-public
2016-09-19 15:34 GMT+02:00 Allan McRae :

> On 19/09/16 23:14, Balló György via arch-dev-public wrote:
> > 2016-09-19 7:02 GMT+02:00 Allan McRae :
> >
> >> This goes beyond just adding SSE2 support.
> >>
> >> Years ago, Arch Linux was "optimised for modern processors".  These were
> >> the days when every other distro was using i386 and we had a blazingly
> >> fast i686 port.  Now every other distro uses i686 while we have sat
> >> still.  Even major software developments are starting to require SSE2.
> >> It is time we moved forward.
> >>
> >> How can we achieve this?  I see several options:
> >>
> >> 1) Do "nothing".  Add a hook to the filesystem package that detects
> >> whether a system has SSE2 support and blocks installation of certain
> >> packages.
> >>
> >> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
> >>
> >> 3) Move our minimum CPU to something less than 20 years old  (even i786
> >> would get us SSE2+3 instructions and is 15 years old)
> >>
> >> 4) We add more modern CPU builds  (and set them automatically building
> >> once the base architecture is updated).
> >>
> >>
> >> I am in favour of #3 for our 32-bit support.  And that would be end of
> >> line as far as 32 bit support in this distribution goes.
> >>
> >>
> >> (We may want to consider #4 for our x86_64, but that is another
> >> conversation).
> >>
> >> Allan
> >>
> >
> >
> > I would not be happy with #3, because I still have two 13 years old
> systems
> > with NetBurst-based CPUs without SSE3 support. But of course I don't use
> > them in everyday use.
> >
>
> If we limit our choice based on your CPU, then we need to limit based on
> the other CPU mentioned in this thread.
>
> That should not be a consideration at all. What we need to do is think
> about what make our distribution worthy of being a distribution.
> Original the selling points were rolling release, vanilla packages and
> optimised binaries.  We have lost the latter.  Do we want to get it back?
>

Another option could be to keep i686 and x86_64 as is, and introduce new
architectures with automatically built optimised packages for i686 + SSE2
or SSE3, and for x86_64 + SSE4.2 or AVX. This is something similar to your
option #4, but keeps the compatibility with all existing systems.

--
György Balló
Trusted User


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Ike Devolder via arch-dev-public
On Mon, Sep 19, 2016 at 07:38:09PM +0200, Ike Devolder wrote:
> > 
> > If we limit our choice based on your CPU, then we need to limit based on
> > the other CPU mentioned in this thread.
> > 
> > That should not be a consideration at all. What we need to do is think
> > about what make our distribution worthy of being a distribution.
> > Original the selling points were rolling release, vanilla packages and
> > optimised binaries.  We have lost the latter.  Do we want to get it back?
> > 
> > Allan
> 
> Yes we want it back. I also have systems without SSE4 and if Arch is no
> longer usable on those I'll use distributions for 'older' hardware on
> those.
> 
> But for our day-to-day workhorses I would love optimized binaries.
> 
> -- 
> Ike

Someone mentioned AVX2, but it seems there is still a patch needed for
glibc. Solus added it very recently https://dev.solus-project.com/T503
and they have taken it from Clear Linux.

-- 
Ike


signature.asc
Description: PGP signature


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Ike Devolder via arch-dev-public
On Mon, Sep 19, 2016 at 11:34:07PM +1000, Allan McRae wrote:
> On 19/09/16 23:14, Balló György via arch-dev-public wrote:
> > 2016-09-19 7:02 GMT+02:00 Allan McRae :
> > 
> >> This goes beyond just adding SSE2 support.
> >>
> >> Years ago, Arch Linux was "optimised for modern processors".  These were
> >> the days when every other distro was using i386 and we had a blazingly
> >> fast i686 port.  Now every other distro uses i686 while we have sat
> >> still.  Even major software developments are starting to require SSE2.
> >> It is time we moved forward.
> >>
> >> How can we achieve this?  I see several options:
> >>
> >> 1) Do "nothing".  Add a hook to the filesystem package that detects
> >> whether a system has SSE2 support and blocks installation of certain
> >> packages.
> >>
> >> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
> >>
> >> 3) Move our minimum CPU to something less than 20 years old  (even i786
> >> would get us SSE2+3 instructions and is 15 years old)
> >>
> >> 4) We add more modern CPU builds  (and set them automatically building
> >> once the base architecture is updated).
> >>
> >>
> >> I am in favour of #3 for our 32-bit support.  And that would be end of
> >> line as far as 32 bit support in this distribution goes.
> >>
> >>
> >> (We may want to consider #4 for our x86_64, but that is another
> >> conversation).
> >>
> >> Allan
> >>
> > 
> > 
> > I would not be happy with #3, because I still have two 13 years old systems
> > with NetBurst-based CPUs without SSE3 support. But of course I don't use
> > them in everyday use.
> > 
> 
> If we limit our choice based on your CPU, then we need to limit based on
> the other CPU mentioned in this thread.
> 
> That should not be a consideration at all. What we need to do is think
> about what make our distribution worthy of being a distribution.
> Original the selling points were rolling release, vanilla packages and
> optimised binaries.  We have lost the latter.  Do we want to get it back?
> 
> Allan

Yes we want it back. I also have systems without SSE4 and if Arch is no
longer usable on those I'll use distributions for 'older' hardware on
those.

But for our day-to-day workhorses I would love optimized binaries.

-- 
Ike


signature.asc
Description: PGP signature


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Allan McRae
On 19/09/16 23:14, Balló György via arch-dev-public wrote:
> 2016-09-19 7:02 GMT+02:00 Allan McRae :
> 
>> This goes beyond just adding SSE2 support.
>>
>> Years ago, Arch Linux was "optimised for modern processors".  These were
>> the days when every other distro was using i386 and we had a blazingly
>> fast i686 port.  Now every other distro uses i686 while we have sat
>> still.  Even major software developments are starting to require SSE2.
>> It is time we moved forward.
>>
>> How can we achieve this?  I see several options:
>>
>> 1) Do "nothing".  Add a hook to the filesystem package that detects
>> whether a system has SSE2 support and blocks installation of certain
>> packages.
>>
>> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
>>
>> 3) Move our minimum CPU to something less than 20 years old  (even i786
>> would get us SSE2+3 instructions and is 15 years old)
>>
>> 4) We add more modern CPU builds  (and set them automatically building
>> once the base architecture is updated).
>>
>>
>> I am in favour of #3 for our 32-bit support.  And that would be end of
>> line as far as 32 bit support in this distribution goes.
>>
>>
>> (We may want to consider #4 for our x86_64, but that is another
>> conversation).
>>
>> Allan
>>
> 
> 
> I would not be happy with #3, because I still have two 13 years old systems
> with NetBurst-based CPUs without SSE3 support. But of course I don't use
> them in everyday use.
> 

If we limit our choice based on your CPU, then we need to limit based on
the other CPU mentioned in this thread.

That should not be a consideration at all. What we need to do is think
about what make our distribution worthy of being a distribution.
Original the selling points were rolling release, vanilla packages and
optimised binaries.  We have lost the latter.  Do we want to get it back?

Allan


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Balló György via arch-dev-public
2016-09-19 7:02 GMT+02:00 Allan McRae :

> This goes beyond just adding SSE2 support.
>
> Years ago, Arch Linux was "optimised for modern processors".  These were
> the days when every other distro was using i386 and we had a blazingly
> fast i686 port.  Now every other distro uses i686 while we have sat
> still.  Even major software developments are starting to require SSE2.
> It is time we moved forward.
>
> How can we achieve this?  I see several options:
>
> 1) Do "nothing".  Add a hook to the filesystem package that detects
> whether a system has SSE2 support and blocks installation of certain
> packages.
>
> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
>
> 3) Move our minimum CPU to something less than 20 years old  (even i786
> would get us SSE2+3 instructions and is 15 years old)
>
> 4) We add more modern CPU builds  (and set them automatically building
> once the base architecture is updated).
>
>
> I am in favour of #3 for our 32-bit support.  And that would be end of
> line as far as 32 bit support in this distribution goes.
>
>
> (We may want to consider #4 for our x86_64, but that is another
> conversation).
>
> Allan
>


I would not be happy with #3, because I still have two 13 years old systems
with NetBurst-based CPUs without SSE3 support. But of course I don't use
them in everyday use.

So I'm in favour of #2, requiring SSE and SSE2 would be OK for me.


- model name: Intel(R) Celeron(R) CPU 2.10GHz
- flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts eagerfpu

- model name: Intel(R) Celeron(R) CPU 1.80GHz
- flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts eagerfpu

--
György Balló
Trusted User


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Christian Hesse
Allan McRae  on Mon, 2016/09/19 19:34:
> On 19/09/16 19:05, Christian Hesse wrote:
> > Bartłomiej Piotrowski  on Fri, 2016/09/16
> > 21:44:  
> >> Actually, why don't raise the bar higher? SSE2 has been introduced in
> >> 2001 – that's 15 years to upgrade one's hardware and given my sad
> >> experiences with computers, I find it hard to believe anyone has that
> >> old PC that happens to run Arch.  
> > 
> > I do. Running Arch Linux on a bunch of informational room displays...
> > These are based on Geode CPUs and I am pretty sure no SSE2 is available.
> > (Taking a look at /proc/cpuinfo these devices do not even feature SSE...
> > The CPU identifies itself as i586.)

This is buggy hardware... SSE is available ('gcc -O3 -msse -mno-sse2'
produces functional output), SSE2 is not ('gcc -O3 -msse2' breaks with
illegal instruction).

> > That said I will be able to handle that myself. ;)
> > Possibly I will have to do local rebuilds of webkitgtk2 to make surf run
> > on these devices from time to time.  
> 
> If we adopt SSE2 in any form, you will need to rebuild your entire
> system to use it.  It will be used in optimizations everywhere.

Well, that could cause some headache for me... :-p

In the end it depends on what code is optimized by gcc. Would SSE2 code be
used by that much packages?

We could just keep i686 as-is for maximum compatibility. Let's take a
realistic look at the things: Most users run i686, so why bother and optimize
i686 - just to save some CPU cycles for a minority?
(I would even wast CPU cycle rebuilding a bunch of packages... pacman tells
me the effected boxes have 399 packages installed.)

So better raise requirements for x86_64. All x86_64 (and most overall) users
will benefit. Older AMD CPUs (or really old Intel ones?) without SSE4 could
still run i686 then - so nobody is forced to run anything else than Arch
Linux. ;)
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpPTh5r8KrqC.pgp
Description: OpenPGP digital signature


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Florian Pritz via arch-dev-public
On Monday, September 19, 2016 7:34:23 PM CEST Allan McRae wrote:
> If we adopt SSE2 in any form, you will need to rebuild your entire
> system to use it.  It will be used in optimizations everywhere.

Just for the record: I also run 2 geode boxes as media players and I'd like to 
keep them running on Arch if possible, but I'll manage.

I'm not really sure why we want to even invest time in making all i686 
packages use more features. Most of our users run x86_64 already so maybe we 
should think about increasing feature support there since that will have a 
bigger impact. Having some packages use SSE is fine by me and apparently 
that's what we are doing right now. If I understood the initial mail 
correctly, webkit already uses SSE and just crashes when used on a system that 
doesn't support it. Apparently my mediaplayers don't use any software like 
that. I think that's also what Christian was referring to.

Also I guess we'll run into similar problems with x86_64 since we don't know 
if those people use early or recent CPUs and I believe we already use all 
features that were supported by early ones.

About javascript being massively slower in webkit: Is that compared to 
the SSE version or compared to the non-SSE version that has been there before?

Florian

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


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Allan McRae
On 19/09/16 19:05, Christian Hesse wrote:
> Bartłomiej Piotrowski  on Fri, 2016/09/16 21:44:
>> Actually, why don't raise the bar higher? SSE2 has been introduced in
>> 2001 – that's 15 years to upgrade one's hardware and given my sad
>> experiences with computers, I find it hard to believe anyone has that
>> old PC that happens to run Arch.
> 
> I do. Running Arch Linux on a bunch of informational room displays...
> These are based on Geode CPUs and I am pretty sure no SSE2 is available.
> (Taking a look at /proc/cpuinfo these devices do not even feature SSE... The
> CPU identifies itself as i586.)
> 
> That said I will be able to handle that myself. ;)
> Possibly I will have to do local rebuilds of webkitgtk2 to make surf run on
> these devices from time to time.

If we adopt SSE2 in any form, you will need to rebuild your entire
system to use it.  It will be used in optimizations everywhere.

A


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Christian Hesse
Bartłomiej Piotrowski  on Fri, 2016/09/16 21:44:
> Actually, why don't raise the bar higher? SSE2 has been introduced in
> 2001 – that's 15 years to upgrade one's hardware and given my sad
> experiences with computers, I find it hard to believe anyone has that
> old PC that happens to run Arch.

I do. Running Arch Linux on a bunch of informational room displays...
These are based on Geode CPUs and I am pretty sure no SSE2 is available.
(Taking a look at /proc/cpuinfo these devices do not even feature SSE... The
CPU identifies itself as i586.)

That said I will be able to handle that myself. ;)
Possibly I will have to do local rebuilds of webkitgtk2 to make surf run on
these devices from time to time.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpBvmHcZB2qu.pgp
Description: OpenPGP digital signature


Re: [arch-dev-public] i686 and SSE2

2016-09-19 Thread Sven-Hendrik Haase
I favor 3) as well. Seems rather easy to implement and I don't really
think we need to support architecture that old.

On Mon, Sep 19, 2016 at 7:02 AM, Allan McRae  wrote:
> This goes beyond just adding SSE2 support.
>
> Years ago, Arch Linux was "optimised for modern processors".  These were
> the days when every other distro was using i386 and we had a blazingly
> fast i686 port.  Now every other distro uses i686 while we have sat
> still.  Even major software developments are starting to require SSE2.
> It is time we moved forward.
>
> How can we achieve this?  I see several options:
>
> 1) Do "nothing".  Add a hook to the filesystem package that detects
> whether a system has SSE2 support and blocks installation of certain
> packages.
>
> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
>
> 3) Move our minimum CPU to something less than 20 years old  (even i786
> would get us SSE2+3 instructions and is 15 years old)
>
> 4) We add more modern CPU builds  (and set them automatically building
> once the base architecture is updated).
>
>
> I am in favour of #3 for our 32-bit support.  And that would be end of
> line as far as 32 bit support in this distribution goes.
>
>
> (We may want to consider #4 for our x86_64, but that is another
> conversation).
>
> Allan


Re: [arch-dev-public] i686 and SSE2

2016-09-18 Thread Allan McRae
This goes beyond just adding SSE2 support.

Years ago, Arch Linux was "optimised for modern processors".  These were
the days when every other distro was using i386 and we had a blazingly
fast i686 port.  Now every other distro uses i686 while we have sat
still.  Even major software developments are starting to require SSE2.
It is time we moved forward.

How can we achieve this?  I see several options:

1) Do "nothing".  Add a hook to the filesystem package that detects
whether a system has SSE2 support and blocks installation of certain
packages.

2) Add SSE2 to our optimisations and require "i686 + SSE2"

3) Move our minimum CPU to something less than 20 years old  (even i786
would get us SSE2+3 instructions and is 15 years old)

4) We add more modern CPU builds  (and set them automatically building
once the base architecture is updated).


I am in favour of #3 for our 32-bit support.  And that would be end of
line as far as 32 bit support in this distribution goes.


(We may want to consider #4 for our x86_64, but that is another
conversation).

Allan


Re: [arch-dev-public] i686 and SSE2

2016-09-17 Thread Connor Behan via arch-dev-public
On 16/09/16 03:57 PM, Daniel Micay wrote:
> On Fri, 2016-09-16 at 21:44 +0200, Bart?omiej Piotrowski wrote:
>> Actually, why don't raise the bar higher? SSE2 has been introduced in
>> 2001 ? that's 15 years to upgrade one's hardware and given my sad
>> experiences with computers, I find it hard to believe anyone has that
>> old PC that happens to run Arch.
>>
>> We used to advertise ourselves as optimized for modern processors. Our
>> "i786" really should include SSE3. For the same reason I would not
>> complain about requiring SSE4 instructions for amd64.
>>
>>> I also wish we had some data on SSE2 support across i686 machines.
>>> Perhaps
>>> we should upgrade pkgstats to record *all* the cpuflags? We would
>>> gain data
>>> for future decisions, too.
>> pkgstats seems to have lots of old data. It would be beneficial to
>> start
>> the statistics from scratch and include kernel modules as well to see
>> if
>> our config isn't overloaded.
>>
>> Bart?omiej
> I think it does include kernel modules. It's why it doesn't work
> properly with linux-grsec since it can't obtain that without root and
> then doesn't collect statistics on installs with grsecurity. It might
> just not be published.
What's the point of mandating SSE2 support when 95% of apps don't really
benefit from it? The few people getting SIGILL from firefox and chromium
will certainly mind it much more when they get it from everything. I
would just make an installation hook that reads cpuinfo and warns
non-SSE2 users that they are installing something too modern.


signature.asc
Description: OpenPGP digital signature


Re: [arch-dev-public] i686 and SSE2

2016-09-16 Thread Daniel Micay via arch-dev-public
On Fri, 2016-09-16 at 21:44 +0200, Bartłomiej Piotrowski wrote:
> Actually, why don't raise the bar higher? SSE2 has been introduced in
> 2001 – that's 15 years to upgrade one's hardware and given my sad
> experiences with computers, I find it hard to believe anyone has that
> old PC that happens to run Arch.
> 
> We used to advertise ourselves as optimized for modern processors. Our
> "i786" really should include SSE3. For the same reason I would not
> complain about requiring SSE4 instructions for amd64.
> 
> > 
> > I also wish we had some data on SSE2 support across i686 machines.
> > Perhaps
> > we should upgrade pkgstats to record *all* the cpuflags? We would
> > gain data
> > for future decisions, too.
> 
> pkgstats seems to have lots of old data. It would be beneficial to
> start
> the statistics from scratch and include kernel modules as well to see
> if
> our config isn't overloaded.
> 
> Bartłomiej

I think it does include kernel modules. It's why it doesn't work
properly with linux-grsec since it can't obtain that without root and
then doesn't collect statistics on installs with grsecurity. It might
just not be published.

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


Re: [arch-dev-public] i686 and SSE2

2016-09-16 Thread Bartłomiej Piotrowski
Actually, why don't raise the bar higher? SSE2 has been introduced in
2001 – that's 15 years to upgrade one's hardware and given my sad
experiences with computers, I find it hard to believe anyone has that
old PC that happens to run Arch.

We used to advertise ourselves as optimized for modern processors. Our
"i786" really should include SSE3. For the same reason I would not
complain about requiring SSE4 instructions for amd64.

> I also wish we had some data on SSE2 support across i686 machines. Perhaps
> we should upgrade pkgstats to record *all* the cpuflags? We would gain data
> for future decisions, too.

pkgstats seems to have lots of old data. It would be beneficial to start
the statistics from scratch and include kernel modules as well to see if
our config isn't overloaded.

Bartłomiej



signature.asc
Description: OpenPGP digital signature