On Tue, Oct 20, 2015 at 2:16 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Mon, 2015-10-19 at 11:59 -0700, Andre McCurdy wrote: >> Use 'atom' as an alias for the first generation Intel Atom CPUs. >> --- >> meta/conf/machine/include/tune-atom.inc | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/meta/conf/machine/include/tune-atom.inc >> b/meta/conf/machine/include/tune-atom.inc >> index 5e1bb74..24cd676 100644 >> --- a/meta/conf/machine/include/tune-atom.inc >> +++ b/meta/conf/machine/include/tune-atom.inc >> @@ -1,2 +1,2 @@ >> -# Atom tunings are the same as core2 for now... >> -require conf/machine/include/tune-core2.inc >> +# Alias for the first generation of Intel Atom CPUs. >> +require conf/machine/include/tune-bonnell.inc > > This is actually pretty nasty to anyone who uses package feeds or > packages since all of a sudden, the system rebuilds with a completely > different package architecture. Not sure we can take this change for > that reason.
OK. I was thinking the comment in tune-atom.inc "Atom tunings are the same as core2 FOR NOW..." gave people fair warning that tune-atom.inc might not remain an alias for tune-core2.inc forever, but no problem to drop this patch. Another approach might be to drop tune-atom.inc altogether. Atom is now ambiguous in terms of defining a CPU architecture and it hasn't been a documented gcc x86 tuning option since gcc 4.8 https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/x86-Options.html#x86-Options > I'd also like to understand how much of a difference these specific > tunes actually give. I know the Intel people have been trying to focus > on a smaller number of tunes that work well on the majority of platforms > rather than micro optimising the tunes. > > Are there some benchmark numbers or other analysis which shows these > tunes as being more effective? Not that I'm aware of. My own tests suggest that the benefits of bonnell -vs- core2 tuning on a first generation Atom are pretty unspectacular (maybe ~0 to 5 % performance increase and ~5% increase in code size). I don't have a Silvermont board. This patch set was more about enabling further experiments though, so if solid benchmark improvements are a prerequisite then this patch set isn't ready to merge. > > Cheers, > > Richard > > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
