Why -mtune=atom?

[Ralf Corsepius]

On 03/12/2015 06:16 PM, Florian Weimer wrote:
>
> I looked at GCC, and -mtune=atom is actually -mtune=bonnell, and there
> is now -mtune=silvermont.  Bay Trail and Avoton/Rangeley, the current
> SoC families, belong to Silvermont, not Bonnell.
Well, to reach the largest possible user-groups, you need to compromise 
and balance the trade-offs.

So far. -mtune=atom seems to have worked well, with many users probably 
not even having noticed it.

That said, to me this would mean, you'd have to prove the other -mtune= 
options provide a measurable performance increase on those cpus/SoC 
without breaking backward compatibility on older HW.

As far as the switch to -mtune=atom is concerned, I don't know if was 
measureable, but it wasn't user-sensible on Atoms nor on i686s.

> (And no, i686 binaries aren't just for enthusiasts.  I expect that users
> who run 32-bit software with them on x86_64 installations are also
> important.)
I do not agree. On the user-side, i686 binaries on x86_64 are a band-aid 
to help out on x86_64s in those rare occasions, when x86_64 binaries are 
not available (In most cases proprietary SW)

The major difference to users on real i686-cpus, is real i686-cpus 
typically are low-end CPUs, which - in comparison to x86_64-CPUs - 
suffer from lack of cpu-power. I.e. there a performance boost may play a 
different, more significant role than for i686-binaries on x86_64.

Ralf