[gentoo-user] Re: gentoo on the i7

[Kerin Millar]

On 11/04/2010 12:27, Mick wrote:
> On Sunday 11 April 2010 11:43:26 zeerak.w@×××××.com wrote:
>> On Sun, Apr 11, 2010 at 03:20:50AM +0100, Kerin Millar wrote:
>>> On 10/04/2010 23:06, luis jure wrote:
>>>> hello list,
>>>>
>>>> after many years without a hardware upgrade, i'll be receiving my new
>>>> computer next week: intel i7 920 cpu, 6 GB ram, asus p6t mobo.
>>>>
>>>> i'm pretty excited, i imagine that at first i'll be shocked at the
>>>> difference with the ancient machine i'm using now.
>>>>
>>>> now my question: searching a bit for the best compilation flags for
>>>> this processor, i found this at gentoo-wiki:
>>>>
>>>> CHOST="x86_64-pc-linux-gnu"
>>>> CFLAGS="-march=core2 -msse4 -mcx16 -msahf -O2 -pipe"
>>>> CXXFLAGS="${CFLAGS}"
>>>> (http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel)
>>>>
>>>> on the other hand, a thread at http://forums.gentoo.org says that the
>>>> wiki page is outdated, and that -march=native should do the job without
>>>> any further tweaks like -msse4 etc.
>>>
>>> That is correct; -march=native will indeed do the job. The CFLAGS
>>> example you cite is clearly an interpretation of the flags that the
>>> native target would result in anyway.
>>>
>>> With respect to my Intel Xeon E3113, -march=native appears to equate to:
>>>
>>> -march=core2 -mtune=core2 -msahf -msse4.1 --param l1-cache-size=32
>>> --param l1-cache-line-size=64
>>>
>>> In short, use "native" and let the compiler take care of the details.
>>>
>>> Cheers,
>>>
>>> --Kerin
>>
>> There's a thread in Installing Gentoo where a dev (can't remember which),
>>   that says native isn't the best option, but the best option indeed is to
>>   specify your arch. See these threads:
>>   http://forums.gentoo.org/viewtopic-t-821639.html
>> http://forums.gentoo.org/viewtopic-t-821370.html
>
> OK, but:
>
> $ gcc -### -march=native -E /usr/include/stdlib.h 2>&1 | grep
> "/usr/libexec/gcc/.*cc1"
>   "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.4/cc1" "-E" "-quiet"
> "/usr/include/stdlib.h" "-D_FORTIFY_SOURCE=2" "-march=core2" "-mcx16" "-msahf"
> "--param" "l1-cache-size=32" "--param" "l1-cache-line-size=64" "-mtune=core2"
>
> the above shows that it uses smaller cache sizes than what my cpu has
> according to lshw:

Hmm. Well, as far as I'm aware, Nehalem - like my Wolfdale-based 
processor - has 64KB of L1 cache per core, with 32KB serving as an 
instruction cache and 32KB serving as a data cache. My tentative 
supposition would be that gcc is taking into account the size of the 
instruction cache. As for the cache line size, that's measured in bytes, 
and is indeed 64B on the majority of (if not all) x86 processors, 
Nehalem included.

However, the result you're getting from lshw does seem somewhat 
contradictory. gcc uses a cpuid instruction to determine the appropriate 
values, but you might also like to check using sysfs:

$ paste <(cat /sys/devices/system/cpu/cpu0/cache/index?/type) <(cat 
/sys/devices/system/cpu/cpu0/cache/index?/size) | sed -re 's/\W+/: /'

On my system that results in the following:

Data: 32K
Instruction: 32K
Unified: 6144K

> Perhaps I should stick with march=core2 and additionally be adding "--param"
> and the L0, L1, L2 cache sizes?

I would suggest to leave it alone. At least, not without raising it with 
a gcc developer or someone with a formal understanding of CPU architecture.

Cheers,

--Kerin