[arch-dev-public] i686 and SSE2

newer
[arch-dev-public] Signoff report...

older
[arch-dev-public] Signoff report...

Jan Alexander Steffens

16 Sep 2016 16 Sep '16

10:19 a.m.

I recently ran into a problem again because Rust understands "i686" to imply up to SSE2; "i586" is supposed to be used for older processors. The Firefox build system now uses "i586", our Rust only has "i686", and our i686 as GCC understands it is something in-between Rust's interpretations. We also have other packages that require SSE2 on i686; I recall WebkitGTK; removing SSE2 support here would mean removing the JIT, increasing compatibility but slowing down JavaScript massively. I've also heard that Go, Ruby and Chromium are similarly affected. I brought this up with Allan and he was in support of "upgrading" our i686 to include SSE2. Are you in favor? Would "-march=pentium-m" be best way of doing this? It seems simple, but are there other effects we don't want? Perhaps "-march=pentium-m -mtune=generic" or "-march=i686 -mtune=generic -msse -msse2" would work better. Should we leave the situation as-is? I.e. only some functionality requires SSE2. There's no way to tell until you run into a SIGILL. Should we enforce no SSE2 on i686? Can we even do that? 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.

Show replies by date

Bartłomiej Piotrowski

16 Sep 16 Sep

9:44 p.m.

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

Daniel Micay

9:57 p.m.

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.

Connor Behan

18 Sep 18 Sep

12:06 a.m.

On 16/09/16 03:57 PM, Daniel Micay 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

On Fri, 2016-09-16 at 21:44 +0200, Bart?omiej Piotrowski wrote: 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.

Allan McRae

19 Sep 19 Sep

7:02 a.m.

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

Sven-Hendrik Haase

10:42 a.m.

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

Balló György

3:14 p.m.

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

Allan McRae

3:34 p.m.

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

Ike Devolder

7:38 p.m.

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

Ike Devolder

8:30 p.m.

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

Allan McRae

20 Sep 20 Sep

12:53 a.m.

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

Balló György

19 Sep 19 Sep

8:57 p.m.

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

Gaetan Bisson

11:12 p.m.

[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

Sven-Hendrik Haase

11:30 p.m.

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

Andreas Radke

20 Sep 20 Sep

7:38 p.m.

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.

...

...
...
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

21 Sep 21 Sep

9:56 a.m.

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 tpowa@archlinux.org

Allan McRae

28 Sep 28 Sep

5:10 a.m.

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

Andreas Radke

7:19 p.m.

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

Bartłomiej Piotrowski

9:12 p.m.

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

Daniel Micay

9:54 p.m.

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.

Christian Hesse

19 Sep 19 Sep

11:05 a.m.

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/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Allan McRae

11:34 a.m.

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

Florian Pritz

12:22 p.m.

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

Christian Hesse

12:40 p.m.

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/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

2765

Age (days ago)

2777

Last active (days ago)

List overview

Download

23 comments

13 participants

participants (13)

Allan McRae
Andreas Radke
Balló György
Bartłomiej Piotrowski
Christian Hesse
Connor Behan
Daniel Micay
Florian Pritz
Gaetan Bisson
Ike Devolder
Jan Alexander Steffens
Sven-Hendrik Haase
Tobias Powalowski