DevHeads.net

About mtune=atom

Hi,

I've read on <a href="http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_variables" title="http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_variables">http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and...</a>
that mtune=atom. Just because I'm curious, why? :)

Thanks in advance!

Comments

Re: About mtune=atom

By Kevin Kofler at 01/24/2011 - 11:07

Sergio Belkin wrote:
Because everything that's not an Atom should be using x86_64 these days
(unless it's ancient, in which case you can't be aiming at performance that
much or you'd have already bought a newer, much faster CPU ;-) ).

Kevin Kofler

Re: About mtune=atom

By Ian Pilcher at 01/25/2011 - 10:18

On 01/24/2011 10:07 AM, Kevin Kofler wrote:
I can't wait to try that on my brand new fanless VIA C7 board. ;-)

Re: About mtune=atom

By Gilboa Davara at 01/25/2011 - 01:38

On Mon, 2011-01-24 at 17:07 +0100, Kevin Kofler wrote:
... Let alone that fact that even my meager ATOM 330 based ASUS 1201N
netbook is x86_64 capable. (And runs F14/x86_64 quite nicely)

- Gilboa

Re: About mtune=atom

By drago01 at 01/24/2011 - 10:43

On Mon, Jan 24, 2011 at 3:32 PM, Sergio Belkin < ... at gmail dot com> wrote:
Why not?

It is the only 32bit only CPU still being sold, and it does not seem
to hurt others anyway (and most of them should use x86_64 anyway),

Re: About mtune=atom

By John Reiser at 01/24/2011 - 12:25

On 01/24/2011 07:43 AM, drago01 wrote:
There are plenty of machines with 32-bit only CPUs (such as early Celeron,
Pentium socket 478, even some Core Duos [Apple Mini]) which run Fedora very well.
Many are less than 5 years old. In the US, that means the depreciation rules
of tax law strongly encourage their continued use.

Actually many of them should be using the new x86_32 software architecture,
which is the 64-bit instruction set (thus 16 "general" registers, SSE, ...)
but with integers, longs, and pointers all 32 bits. The upper 32 bits
of any user address are 0, and not stored in RAM (except the return address
of CALL.) This gives a measurable benefit on boxes with low RAM.

Re: About mtune=atom

By Adam Williamson at 01/25/2011 - 02:20

On Mon, 2011-01-24 at 09:25 -0800, John Reiser wrote:
IIRC, when we stopped supporting i586, someone kindly ran some tests of
the various -mtune options, and atom optimization turned out to work
best for almost all the processors tested - it's not _just_ good for
Atoms. I could probably drag that post out of the archives if I weren't
a lazy good-for-nothing, but I am, so, what you get is my
probably-faulty memory. =)

Re: About mtune=atom

By Matthew Miller at 01/24/2011 - 18:53

On Mon, Jan 24, 2011 at 09:25:45AM -0800, John Reiser wrote:
This seems like it might be useful in many virtual machine setups. Can you
quantify "measurable"?

Re: About mtune=atom

By John Reiser at 01/24/2011 - 19:43

On 01/24/2011 03:53 PM, Matthew Miller wrote:
"Measurable" means 1% or more. Obviously this depends on the workload.
All code gets 16 general registers and the first six integer/pointer
arguments passed in registers. Apps get guaranteed MMX and SSE.
Kernel gets to tend small processes only, and no big ones.
The catch is that not all the pieces exist today.

Re: About mtune=atom

By Matthew Miller at 01/24/2011 - 20:11

On Mon, Jan 24, 2011 at 04:43:47PM -0800, John Reiser wrote:
1% or more _what_? Performance gain?

Re: About mtune=atom

By John Reiser at 01/24/2011 - 20:30

On 01/24/2011 05:11 PM, Matthew Miller wrote:
1% reduction in CPU time per process; or, 1% increase in processes/hr;
or, 1% decrease in delay along some external user-critical path; or,
1% increase in number of simultaneous processes before complaints; ...

Re: About mtune=atom

By Matthew Miller at 01/24/2011 - 22:17

On Mon, Jan 24, 2011 at 05:30:49PM -0800, John Reiser wrote:
Yeah, I get what 1% faster means. I was asking if that's what you meant, as
opposed to some other 1% benefit. (Less memory, for example.)

Although, pedantically, I have to point out that the 1%s you list are not
all synonymous.

Re: About mtune=atom

By Kevin Kofler at 01/25/2011 - 02:02

Matthew Miller wrote:
Indeed, a 1% reduction in CPU time per process is a 1.0101…% increase in
processes/hr. ;-) But that's being very pedantic. ;-)

Kevin Kofler

Re: About mtune=atom

By Matthew Miller at 01/25/2011 - 08:48

On Tue, Jan 25, 2011 at 08:02:35AM +0100, Kevin Kofler wrote:
Yeah that. :) But also, it's a very, very rare job where a 1% reduction in
CPU time results in a linear increase in processes/hr.

1% CPU gain is the kind of benefit where you do it if it's easy, but if it
gets in the way of _anything_ else, you shrug and eat it.

Re: About mtune=atom

By Jakub Jelinek at 01/24/2011 - 12:47

On Mon, Jan 24, 2011 at 09:25:45AM -0800, John Reiser wrote:
Except that such a model is only barely supported in binutils, the support
for it in gcc is pre-alpha state on a branch and there is no kernel nor
glibc support.

Jakub

Re: About mtune=atom

By Bill Nottingham at 01/24/2011 - 12:55

Jakub Jelinek (<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>) said:
Am I missing something, or would this also be binary-incompatible? If so,
that's very very very much not worth the effort.

Bill

Re: About mtune=atom

By Kevin Kofler at 01/25/2011 - 02:06

Bill Nottingham wrote:
+1

I don't think having another Fedora build for x86_64 machines is worth the
effort. (And it definitely doesn't make sense to replace the true 64-bit
build with this. Some people need true 64-bit.)

Kevin Kofler

[*] the x86_32 ABI on the x86_64 ISA

Re: About mtune=atom

By Jakub Jelinek at 01/24/2011 - 13:08

On Mon, Jan 24, 2011 at 12:55:59PM -0500, Bill Nottingham wrote:
Yes, it is ABI incompatible, not sure what made hjl start with that now
and trying to push x86_64 into Irixy shape with 3 multilibs instead of 2.
I vaguely remember we've talked about it a decade ago and decided it was not
worth the effort.

Jakub

Re: About mtune=atom

By Richard W.M. Jones at 01/24/2011 - 12:45

On Mon, Jan 24, 2011 at 09:25:45AM -0800, John Reiser wrote:
There's even plenty "still being sold". How about VIA, itx, and tons
of other small/embedded stuff that isn't Atom.

*However* optimizing for 32 bit surely has to be a waste of effort
these days. People who want performance should be using 64 bit
machines. For everyone else it's good enough that Fedora can still be
used. Optimizing for Atom alone is justified because Netbooks are
used interactively. So I think the Fedora flags are just right in
this case.

Rich.

Re: About mtune=atom

By Peter Robinson at 01/24/2011 - 13:08

On Mon, Jan 24, 2011 at 5:45 PM, Richard W.M. Jones < ... at redhat dot com> wrote:
Yes, like the 2 million XO-1s using geode processors (that with the
move to i686 it was decided (no idea if it was board or FESCo) the
XO-1 was something they wanted to support in Fedora, and the other
millions of XO-1.5s that will be deployed in the coming year or two
which run on VIA processors.

That's fine IMO as long as it still runs reasonably on the other 32
bit platforms. Also all the nettop 1st gen atom processors are x86-64
and the 2nd gen atom netbook/nettop (N4xx/N5xx/D5xx) processors are
x86-64 now too [1]. So in most cases its just first gen netbooks plus
the devices based on z series, the later having issues anyway as they
don't have an open and supported driver for their GPU.

Peter

[1] <a href="http://en.wikipedia.org/wiki/Atom_processor#History" title="http://en.wikipedia.org/wiki/Atom_processor#History">http://en.wikipedia.org/wiki/Atom_processor#History</a>

Re: About mtune=atom

By Przemek Klosowski at 01/24/2011 - 12:36

On 01/24/2011 12:25 PM, John Reiser wrote:
Some early Xeons did not have the 'lm' capability, either.

Re: About mtune=atom

By drago01 at 01/24/2011 - 12:30

On Mon, Jan 24, 2011 at 6:25 PM, John Reiser < ... at bitwagon dot com> wrote:
Does not contradict what I said "still being sold" ... I didn't say
they do not exist.

Ignoring netbooks/nettops boxes with "low RAM" aren't being sold either ;)