common flags for 2 cpu?
I'm in need of some expert advise about CFLAGS. I'm going to install
Gentoo in two systems, an Atom 330 and a P4 prescott. Since compiling lots of stuff in an Atom is less than joyful, I intend to do almost all compilation on the prescott and produce binary packages to use on the Atom. So, something like CFLAGS="-march=native ..." is out. I know I could set CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer", but I would like to extract a bit more juice from the hw, while still keeping stable systems. So, I thought of setting CFLAGS for both systems as -march=i686, plus the flags that are pulled by -march=native in both systems, plus some other flags: -march=i686 -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 -pni -mtrr This is what is pulled by -march=native, using gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 Prescott: -march=prescott -mno-cx16 -mno-sahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=prescott Atom: -march=atom -mcx16 -msahf -mmovbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom Flags supported (from cat /proc/cpuinfo|grep flags): Prescott: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid xtpr Atom: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm Some questions: 1) Is this strategy right? If so, any other flags to add? (or any flags to remove from the list?) 2) The --param flags are the ones of the computer that will do the compiling. I'm guessing the produced binaries are compatible with cpu with different --param flags. Is this right? TIA Jorge Almeida |
common flags for 2 cpu?
Am 17.08.2012 10:58, schrieb Jorge Almeida:
> I'm in need of some expert advise about CFLAGS. I'm going to install > Gentoo in two systems, an Atom 330 and a P4 prescott. Since compiling > lots of stuff in an Atom is less than joyful, I intend to do almost > all compilation on the prescott and produce binary packages to use on > the Atom. So, something like > CFLAGS="-march=native ..." is out. I know I could set > CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer", but I would like > to extract a bit more juice from the hw, while still keeping stable > systems. So, I thought of setting CFLAGS for both systems as > -march=i686, plus the flags that are pulled by -march=native in both > systems, plus some other flags: > [...] > > This is what is pulled by -march=native, using gcc -march=native -E -v > - </dev/null 2>&1 | grep cc1 > > Prescott: > -march=prescott -mno-cx16 -mno-sahf -mno-movbe -mno-aes -mno-pclmul > -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi > -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 > -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=16 > --param l1-cache-line-size=64 --param l2-cache-size=1024 > -mtune=prescott > > Atom: > -march=atom -mcx16 -msahf -mmovbe -mno-aes -mno-pclmul -mno-popcnt > -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 > -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt > -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=24 --param > l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom > [...] > > Some questions: > > 1) Is this strategy right? If so, any other flags to add? (or any > flags to remove from the list?) > > 2) The --param flags are the ones of the computer that will do the > compiling. I'm guessing the produced binaries are compatible with cpu > with different --param flags. Is this right? > > TIA > > Jorge Almeida > 1) Yes. But as you can see, -march=prescott is basically a subset of atom. In fact, before there was a -march=atom option, prescott was the best flag for atoms. I think you can avoid some hassle by simply enabling "-march=prescott --param l1-cache-line-size=64 --param l2-cache-size=512". 2) Yes, the param flags do not affect compatibility. Using the lower value will probably be better but this is just an educated guess. Regards, Florian Philipp |
common flags for 2 cpu?
On Fri, Aug 17, 2012 at 2:53 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 17.08.2012 10:58, schrieb Jorge Almeida: >> >> 1) Is this strategy right? If so, any other flags to add? (or any >> flags to remove from the list?) >> >> 2) The --param flags are the ones of the computer that will do the >> compiling. I'm guessing the produced binaries are compatible with cpu >> with different --param flags. Is this right? >> >> TIA >> >> Jorge Almeida >> > > 1) Yes. But as you can see, -march=prescott is basically a subset of > atom. In fact, before there was a -march=atom option, prescott was the > best flag for atoms. I think you can avoid some hassle by simply > enabling "-march=prescott --param l1-cache-line-size=64 --param > l2-cache-size=512". > > 2) Yes, the param flags do not affect compatibility. Using the lower > value will probably be better but this is just an educated guess. > What about: CFLAGS="-O2 -pipe -fomit-frame-pointer -march=prescott -mtune=atom --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024" If prescott were exactly a subset of atom, this would yield the best of both worlds. Can it still be safe? I read in http://forums.gentoo.org/viewtopic-t-895104.html : atom Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. Does this mean that these flags are pulled by -mtune=atom, or do we need to ask for them explicitly? The WiKi shows how to find which flags are pulled by -march=native, but not the other cases. Thanks Jorge Almeida |
common flags for 2 cpu?
Am 17.08.2012 19:57, schrieb Jorge Almeida:
> On Fri, Aug 17, 2012 at 2:53 PM, Florian Philipp <lists@binarywings.net> wrote: >> Am 17.08.2012 10:58, schrieb Jorge Almeida: >>> >>> 1) Is this strategy right? If so, any other flags to add? (or any >>> flags to remove from the list?) >>> >>> 2) The --param flags are the ones of the computer that will do the >>> compiling. I'm guessing the produced binaries are compatible with cpu >>> with different --param flags. Is this right? >>> >>> TIA >>> >>> Jorge Almeida >>> >> >> 1) Yes. But as you can see, -march=prescott is basically a subset of >> atom. In fact, before there was a -march=atom option, prescott was the >> best flag for atoms. I think you can avoid some hassle by simply >> enabling "-march=prescott --param l1-cache-line-size=64 --param >> l2-cache-size=512". >> >> 2) Yes, the param flags do not affect compatibility. Using the lower >> value will probably be better but this is just an educated guess. >> > > What about: > > CFLAGS="-O2 -pipe -fomit-frame-pointer -march=prescott -mtune=atom --param > l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024" > > If prescott were exactly a subset of atom, this would yield the best of both > worlds. Can it still be safe? > > I read in http://forums.gentoo.org/viewtopic-t-895104.html : > atom > Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 > instruction set support. > > Does this mean that these flags are pulled by -mtune=atom, or do we need to > ask for them explicitly? The WiKi shows how to find which flags are pulled by > -march=native, but not the other cases. > > Thanks > > Jorge Almeida > Oh, sorry, I didn't think of the second generation atoms. I guess your newer atom is a bit more different from prescott than the one I talked about. Anyway, using -march=prescott is still viable. It just means you lose a bit more in terms of usable SSE extensions on your atom. Your CFLAGS look good to me. They won't pull in anything that your prescott cannot handle. Regards, Florian Philipp |
common flags for 2 cpu?
On Fri, Aug 17, 2012 at 10:05 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 17.08.2012 19:57, schrieb Jorge Almeida: >> I read in http://forums.gentoo.org/viewtopic-t-895104.html : >> atom >> Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 >> instruction set support. >> >> Does this mean that these flags are pulled by -mtune=atom, or do we need to >> ask for them explicitly? The WiKi shows how to find which flags are pulled by >> -march=native, but not the other cases. >> >> Thanks >> >> Jorge Almeida >> > > Oh, sorry, I didn't think of the second generation atoms. I guess your > newer atom is a bit more different from prescott than the one I talked > about. Anyway, using -march=prescott is still viable. It just means you > lose a bit more in terms of usable SSE extensions on your atom. > > Your CFLAGS look good to me. They won't pull in anything that your > prescott cannot handle. > Does -march=prescott not ensure that the prescott will work even if unsupported flags are added? Of, course such flags wouldn't be of use by the prescott, but the atom might be able to use them. Can you confirm this? Thanks, Jorge Almeida |
common flags for 2 cpu?
Am Freitag, 17. August 2012, 22:34:45 schrieb Jorge Almeida:
> Does -march=prescott not ensure that the prescott will work even if > unsupported flags are added? no every flag on its own. If you set a flag it is your responsibility to check that they actually work. -- #163933 |
| All times are GMT. The time now is 01:28 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.