[arch-dev-public] Processor Generation++

[eliott]

On 3/18/08, Paul Mattal <paul at mattal.com> 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.