Am Montag, 17. März 2008 schrieb Roman Kyrylych:

2008/3/17, Simo Leone :

...

Let's start off by saying that this is just me floating an idea out there, it's not so serious (yet...).

I've been toying around with the idea of starting to build our packages with --march=pentium2 instead of i686. This would mean that our binaries would make use of the MMX instruction set, and that our packages would no longer run on PentiumPro or older processors.

My logic here is that we are comitted to being a bleeding edge distro, so I think it very much fits our philosophy to phase out older processor families when they are hardly used anymore. Intel hasn't manufactured PentiumPro's since roughly 1998. The number of users running Arch on 10-year-old boxes must be something very close to zero, so I don't think we'd be disappointing anyone. Also making use of the MMX instruction set would give our multimedia apps a boost, and might make some other software inperceptibly snappier (gogo placebo effect!).

What do you guys think?

And how do you plan to name that arch then? Still i686, pentium2 or x86_32? Having support for MMX on 32-bit architecture is nice, but shifting from i686 to pentium2 cold be not easy to archieve (especially if -arch suffix will be changed) and benefits aren't that big IMO.

My opinion on this, why to desupport something which might be still used, also we all know that x86_64 is the future and therefore i don't think the benefit is worth the trouble. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

On Mon, 2008-03-17 at 10:36 +0100, Pierre Schmitz wrote:

Am Montag, 17. März 2008 10:11:15 schrieb Tobias Powalowski:

...

My opinion on this, why to desupport something which might be still used, also we all know that x86_64 is the future and therefore i don't think the benefit is worth the trouble.

In addition to this MMX would not really boost anything. SSE would be much superior. And further more: You would only notice such improvements on heavy multimedia encoding stuff and such things you would not do on an 10 years old computer.

I believe though, that this was Simo's point. We don't have many users on 10+ year old hardware, so many of our users are doing multimedia stuff and would benefit from MMX. Before making any such change I'd take a poll on the ML, BBS, Flyspray ticket, and put a post on the frontpage pointing to all 3 asking for input on what kind of hardware people use with Arch. More than 1 PPro casualty might be too many (i.e. next -Syu "bricks" their box). Dale

On 3/18/08, Paul Mattal wrote:

Simo Leone wrote:

...

On Mon, Mar 17, 2008 at 02:26:42AM -0500, Simo Leone wrote:

...

Let's start off by saying that this is just me floating an idea out there, it's not so serious (yet...).

I've been toying around with the idea of starting to build our packages with --march=pentium2 instead of i686. This would mean that our binaries would make use of the MMX instruction set, and that our packages would no longer run on PentiumPro or older processors.

My logic here is that we are comitted to being a bleeding edge distro, so I think it very much fits our philosophy to phase out older processor families when they are hardly used anymore. Intel hasn't manufactured PentiumPro's since roughly 1998. The number of users running Arch on 10-year-old boxes must be something very close to zero, so I don't think we'd be disappointing anyone. Also making use of the MMX instruction set would give our multimedia apps a boost, and might make some other software inperceptibly snappier (gogo placebo effect!).

What do you guys think?

Ok so to summarize the rest of the thread a bit: - The technical advantage is questionable. - We might have a non-MMX user out there somewhere.

As far as the trouble to do this... it's really none. Just change the flags in makepkg.conf and the change rolls out as packages get rebuilt.

I guess I'll start a thread on the bbs for starters, and see if anyone is using a pentiumpro anymore.

Is there someone out there with a processor with big MMX tasks who can't buy a faster computer and who is likely to benefit?

I guess I'm not in favor of spending our time thinking about this or changing it unless we can point to at least one person who actually has an itch we'd be scratching. Otherwise, the change could always introduce some new problem, and why incur that extra work unless there's an existing problem we're solving?

In a similar vein: Does anyone have statistics on in what ways and how much benefit x86_64 brings over i686 on hardware that will support it? I've been using processors that support x86_64 for years, but have yet to be persuaded that there's appreciable benefit to switching. Even a 10-20% processing speedup might not persuade me, given how cheap processing power is these days.

Note: This is *not* in any way a dig against x86_64. It's a sincere invitation to provide actual facts to persuade me and others to use it; I suppose I could be missing out on significant benefit.

As far as I know, one of the biggest 'wins' for 64bit is in addressing, for anything above a 32 bit address space (more than 4gb). You have to have pae support on a 32bit proc (and enable it in the os) to hit more than 4gb, which does some type of mapping from 64 bit onto a 32 bit address space. Memory addresses have to be translated, and not a straightforward mapping. Memory access becomes a bit slower. Add to this that the mapping can be different between processes. So if you have processes sharing memory (ie for ipc), you get even more overhead as it has to be translated, then translated again, to be referenced by each site of a shared memory block. more about pae: http://en.wikipedia.org/wiki/Physical_Address_Extension 64 bit has some downsides. I think the hybrid x86_64 chips have weird pipelines to the cpu to support both 32bit and 64bit mode..where it does some weird split into two 32bit words, and uses part of each chunk to tell which mode it is in.. thus reducing you by addressible memory by some factor. Not sure about this one..not really that much of a hardware guy. Also, the word size is larger, so there is some overhead. Memory pointers take up more space, etc. So random app X might use a bit more ram on 64bit than on 32bit. *shrug* I am sure some of the above is off, and I am sure the more hardware centric folks in the audience will point out my inaccuracies.