[gentoo-user] Lowest common denominator compile

[gentoo-user] Lowest common denominator compile

[Grant]

I have a network of very nearly identical Dell XPS 13 laptops that I
manage with a script.  The master pushes the contents of its
filesystem to the others so I only have to manage one system.  It's
worked really well over several years.  I just got a new Dell XPS 13
to serve as the master and there have been some changes that were
difficult to integrate with the network (high-res screen, /dev/sda
replaced with /dev/nvme0n0) but those problems are fixed thanks to you
guys.

Now I'm running into "trap invalid opcode" errors on the older
systems.  Can I disable some of the newer CPU instruction sets on the
master laptop when compiling to hopefully generate binaries that will
work on the older systems?  If so, could anyone point me in the right
direction?  I don't want to use distcc please.

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"

- Grant

[gentoo-user] Re: Lowest common denominator compile

[Grant]

> I have a network of very nearly identical Dell XPS 13 laptops that I
> manage with a script.  The master pushes the contents of its
> filesystem to the others so I only have to manage one system.  It's
> worked really well over several years.  I just got a new Dell XPS 13
> to serve as the master and there have been some changes that were
> difficult to integrate with the network (high-res screen, /dev/sda
> replaced with /dev/nvme0n0) but those problems are fixed thanks to you
> guys.
>
> Now I'm running into "trap invalid opcode" errors on the older
> systems.  Can I disable some of the newer CPU instruction sets on the
> master laptop when compiling to hopefully generate binaries that will
> work on the older systems?  If so, could anyone point me in the right
> direction?  I don't want to use distcc please.
>
> CHOST="x86_64-pc-linux-gnu"
> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"


Switching to -mtune=native seems to work.  Time for an emerge -e world.

- Grant

Re: [gentoo-user] Re: Lowest common denominator compile

[Alan McKinnon]

On 04/09/2017 22:16, Grant wrote:
>> I have a network of very nearly identical Dell XPS 13 laptops that I
>> manage with a script.  The master pushes the contents of its
>> filesystem to the others so I only have to manage one system.  It's
>> worked really well over several years.  I just got a new Dell XPS 13
>> to serve as the master and there have been some changes that were
>> difficult to integrate with the network (high-res screen, /dev/sda
>> replaced with /dev/nvme0n0) but those problems are fixed thanks to you
>> guys.
>>
>> Now I'm running into "trap invalid opcode" errors on the older
>> systems.  Can I disable some of the newer CPU instruction sets on the
>> master laptop when compiling to hopefully generate binaries that will
>> work on the older systems?  If so, could anyone point me in the right
>> direction?  I don't want to use distcc please.
>>
>> CHOST="x86_64-pc-linux-gnu"
>> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
> 
> 
> Switching to -mtune=native seems to work.  Time for an emerge -e world.

Also time for ansible. Why you managing a fleet of machines with a
script that won't actually differentiate properly between machines? It
will sorts mostly do it right, except when you forget something.

This is exactly the use-case ansible was designed for: declarative,
idempotent, predictable management of a fleet of machines that may or
may not be around when you feel like updating something (so it catches
up later), and needs only sshd and python to do it's magic :-)

Never mind that ansible was written with servers in mind; in terms of
management where you do $STUFF_THAT_NEEDS_MANAGING, there is no
difference between servers and laptops. A computer is still just a computer.

</me also laments the lack of poudriere on Gentoo. But that's for
another time>

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Lowest common denominator compile

[Grant]

>>> I have a network of very nearly identical Dell XPS 13 laptops that I
>>> manage with a script.  The master pushes the contents of its
>>> filesystem to the others so I only have to manage one system.  It's
>>> worked really well over several years.  I just got a new Dell XPS 13
>>> to serve as the master and there have been some changes that were
>>> difficult to integrate with the network (high-res screen, /dev/sda
>>> replaced with /dev/nvme0n0) but those problems are fixed thanks to you
>>> guys.
>>>
>>> Now I'm running into "trap invalid opcode" errors on the older
>>> systems.  Can I disable some of the newer CPU instruction sets on the
>>> master laptop when compiling to hopefully generate binaries that will
>>> work on the older systems?  If so, could anyone point me in the right
>>> direction?  I don't want to use distcc please.
>>>
>>> CHOST="x86_64-pc-linux-gnu"
>>> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
>>
>>
>> Switching to -mtune=native seems to work.  Time for an emerge -e world.
>
> Also time for ansible. Why you managing a fleet of machines with a
> script that won't actually differentiate properly between machines? It
> will sorts mostly do it right, except when you forget something.


Well I designed it around the principle that I would have the luxury
of using sufficiently identical hardware across each system so that it
wouldn't need to differentiate.  It's simple, it's one file.  I just
execute the file with certain parameters based on whether I'm cloning
the running system to a USB stick, cloning the running USB stick to
its host system, pushing the master system to another system, or
updating the running system based on the last push to it.  Worked
great until the latest iteration of XPS 13.  Even now the only
hardware differentiation it needs to make is /dev/sda or /dev/nvme0n1.
DisplaySize in xorg.conf and -mtune=native in make.conf are sufficient
to handle different screen resolutions and CPUs.


> This is exactly the use-case ansible was designed for: declarative,
> idempotent, predictable management of a fleet of machines that may or
> may not be around when you feel like updating something (so it catches
> up later), and needs only sshd and python to do it's magic :-)


ansible does sound pretty cool.  I'll check it out if I outgrow my
script but as long as I can keep using Dell XPS 13 laptops I don't
think it will have any trouble scaling.

- Grant

Re: [gentoo-user] Re: Lowest common denominator compile

[Alan McKinnon]

On 04/09/2017 22:55, Grant wrote:
>> This is exactly the use-case ansible was designed for: declarative,
>> idempotent, predictable management of a fleet of machines that may or
>> may not be around when you feel like updating something (so it catches
>> up later), and needs only sshd and python to do it's magic :-)
> 
> ansible does sound pretty cool.  I'll check it out if I outgrow my
> script but as long as I can keep using Dell XPS 13 laptops I don't
> think it will have any trouble scaling.


Allow me a few moments to convince you more :-)

Maybe you don't need it right this minute, but your current method will
become less and less workable with time, and when you feel that maybe
you ought to do it differently, you might remember this conversation.

ansible works like you do - ssh's into a host, and does what needs
doing. It figures out what to do the same way you do, by having a clear
picture of what should be and making the host that way. It's very much
like a proxy for you.

The difference comes in when you observe that with ansible you don't
have to deal with the details of HOW to do something (the shipped
modules already deal with all of that), you only concern yourself with
WHAT you want to accomplish.

If you only use ansible to basically run ssh in a for loop, then it's a
waste of the setup effort. But let's say Dell retire or change those
XPS13s dramatically. 4 of yours wear out, and you buy 8 Precisions.
Bugger, they have different hardware and the chipset running the SSDs
has a different drive. The GPU, the wifi NIC, these things all drift
with time. Then you figure you want 2 management Precisions, plus
your's, the wife's and the workshop manager's laptops need extra stuff;
and the plebs can stay the same on the XPS.

And your script gets out of hand real quick (we've all been there). How
do you detect that some is a Precision and do appropriate actions in a
nasty script? It's not easy.
Ansible does all that for you upfront out the box. It always knows what
it's working on (thanks to a module called setup) and catering for
inevitable differences is trivial to handle. With none of the downsides
to copying entire tree structures around (like copying way too many
files you didn't intend to. Like /var/run...)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Lowest common denominator compile

[Grant]

>>> This is exactly the use-case ansible was designed for: declarative,
>>> idempotent, predictable management of a fleet of machines that may or
>>> may not be around when you feel like updating something (so it catches
>>> up later), and needs only sshd and python to do it's magic :-)
>>
>> ansible does sound pretty cool.  I'll check it out if I outgrow my
>> script but as long as I can keep using Dell XPS 13 laptops I don't
>> think it will have any trouble scaling.
>
>
> Allow me a few moments to convince you more :-)
>
> Maybe you don't need it right this minute, but your current method will
> become less and less workable with time, and when you feel that maybe
> you ought to do it differently, you might remember this conversation.
>
> ansible works like you do - ssh's into a host, and does what needs
> doing. It figures out what to do the same way you do, by having a clear
> picture of what should be and making the host that way. It's very much
> like a proxy for you.
>
> The difference comes in when you observe that with ansible you don't
> have to deal with the details of HOW to do something (the shipped
> modules already deal with all of that), you only concern yourself with
> WHAT you want to accomplish.
>
> If you only use ansible to basically run ssh in a for loop, then it's a
> waste of the setup effort. But let's say Dell retire or change those
> XPS13s dramatically. 4 of yours wear out, and you buy 8 Precisions.
> Bugger, they have different hardware and the chipset running the SSDs
> has a different drive. The GPU, the wifi NIC, these things all drift
> with time. Then you figure you want 2 management Precisions, plus
> your's, the wife's and the workshop manager's laptops need extra stuff;
> and the plebs can stay the same on the XPS.
>
> And your script gets out of hand real quick (we've all been there). How
> do you detect that some is a Precision and do appropriate actions in a
> nasty script? It's not easy.
> Ansible does all that for you upfront out the box. It always knows what
> it's working on (thanks to a module called setup) and catering for
> inevitable differences is trivial to handle. With none of the downsides
> to copying entire tree structures around (like copying way too many
> files you didn't intend to. Like /var/run...)


It truly sounds great but the devil is in the details in my particular
environment.  If I feel like I'm outgrowing my script (and maybe even
if I don't) I'll dig into ansible.  How big of a duty is the
implementation?

Thanks,
Grant

Re: [gentoo-user] Re: Lowest common denominator compile

[Alan McKinnon]

On 05/09/2017 02:01, Grant wrote:
>>>> This is exactly the use-case ansible was designed for: declarative,
>>>> idempotent, predictable management of a fleet of machines that may or
>>>> may not be around when you feel like updating something (so it catches
>>>> up later), and needs only sshd and python to do it's magic :-)
>>>
>>> ansible does sound pretty cool.  I'll check it out if I outgrow my
>>> script but as long as I can keep using Dell XPS 13 laptops I don't
>>> think it will have any trouble scaling.
>>
>>
>> Allow me a few moments to convince you more :-)
>>
>> Maybe you don't need it right this minute, but your current method will
>> become less and less workable with time, and when you feel that maybe
>> you ought to do it differently, you might remember this conversation.
>>
>> ansible works like you do - ssh's into a host, and does what needs
>> doing. It figures out what to do the same way you do, by having a clear
>> picture of what should be and making the host that way. It's very much
>> like a proxy for you.
>>
>> The difference comes in when you observe that with ansible you don't
>> have to deal with the details of HOW to do something (the shipped
>> modules already deal with all of that), you only concern yourself with
>> WHAT you want to accomplish.
>>
>> If you only use ansible to basically run ssh in a for loop, then it's a
>> waste of the setup effort. But let's say Dell retire or change those
>> XPS13s dramatically. 4 of yours wear out, and you buy 8 Precisions.
>> Bugger, they have different hardware and the chipset running the SSDs
>> has a different drive. The GPU, the wifi NIC, these things all drift
>> with time. Then you figure you want 2 management Precisions, plus
>> your's, the wife's and the workshop manager's laptops need extra stuff;
>> and the plebs can stay the same on the XPS.
>>
>> And your script gets out of hand real quick (we've all been there). How
>> do you detect that some is a Precision and do appropriate actions in a
>> nasty script? It's not easy.
>> Ansible does all that for you upfront out the box. It always knows what
>> it's working on (thanks to a module called setup) and catering for
>> inevitable differences is trivial to handle. With none of the downsides
>> to copying entire tree structures around (like copying way too many
>> files you didn't intend to. Like /var/run...)
> 
> 
> It truly sounds great but the devil is in the details in my particular
> environment.  If I feel like I'm outgrowing my script (and maybe even
> if I don't) I'll dig into ansible.  How big of a duty is the
> implementation?

Implementation is easy, it's just another Python app with a config file.

Then there's some associated work around getting your SSH setup the way
you want it with the correct users and passwords and keys and enough
access control that you feel safe. Nothing new there, you likely already
have all that already. If not, well ssh isn't exactly new to you :-)

The bulk of the work is in thinking and planning what you want to
achieve. You have to have a very clear picture of the end goal so you
can build towards it; this part is exactly like thinking your way
through code you intend to write. This part depends on how complex your
stuff is and how many exceptions you have to the rule.

You're the only one that knows if the result will be worth while, so
like all new toys I suppose the best approach is to tinker with it a
bit, see if you like it, then decide if you think it worthwhile to proceed.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Lowest common denominator compile

[Grant]

>> It truly sounds great but the devil is in the details in my particular
>> environment.  If I feel like I'm outgrowing my script (and maybe even
>> if I don't) I'll dig into ansible.  How big of a duty is the
>> implementation?
>
> Implementation is easy, it's just another Python app with a config file.
>
> Then there's some associated work around getting your SSH setup the way
> you want it with the correct users and passwords and keys and enough
> access control that you feel safe. Nothing new there, you likely already
> have all that already. If not, well ssh isn't exactly new to you :-)
>
> The bulk of the work is in thinking and planning what you want to
> achieve. You have to have a very clear picture of the end goal so you
> can build towards it; this part is exactly like thinking your way
> through code you intend to write. This part depends on how complex your
> stuff is and how many exceptions you have to the rule.
>
> You're the only one that knows if the result will be worth while, so
> like all new toys I suppose the best approach is to tinker with it a
> bit, see if you like it, then decide if you think it worthwhile to proceed.


Will do, thanks Alan.

- Grant

[gentoo-user] Re: Lowest common denominator compile

[Ian Zimmerman]

On 2017-09-04 13:55, Grant wrote:

> ansible does sound pretty cool.  I'll check it out if I outgrow my
> script but as long as I can keep using Dell XPS 13 laptops I don't
> think it will have any trouble scaling.

For those dug in minimalists among us, there is also app-admin/cdist.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Re: Lowest common denominator compile

[Grant]

>> ansible does sound pretty cool.  I'll check it out if I outgrow my
>> script but as long as I can keep using Dell XPS 13 laptops I don't
>> think it will have any trouble scaling.
>
> For those dug in minimalists among us, there is also app-admin/cdist.


Have you tried ansible?

- Grant

[gentoo-user] Re: Lowest common denominator compile

[Ian Zimmerman]

On 2017-09-05 06:54, Grant wrote:

> Have you tried ansible?

ansible was in use at one of my jobs.

I feel that it is overkill for my personal use, and possibly for yours.

OTOH, your case _is_ different from mine: I don't admin PCs for other
folks to use.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Re: Lowest common denominator compile

[R0b0t1]

On Mon, Sep 4, 2017 at 3:16 PM, Grant <emailgrant@gmail.com> wrote:
>> I have a network of very nearly identical Dell XPS 13 laptops that I
>> manage with a script.  The master pushes the contents of its
>> filesystem to the others so I only have to manage one system.  It's
>> worked really well over several years.  I just got a new Dell XPS 13
>> to serve as the master and there have been some changes that were
>> difficult to integrate with the network (high-res screen, /dev/sda
>> replaced with /dev/nvme0n0) but those problems are fixed thanks to you
>> guys.
>>
>> Now I'm running into "trap invalid opcode" errors on the older
>> systems.  Can I disable some of the newer CPU instruction sets on the
>> master laptop when compiling to hopefully generate binaries that will
>> work on the older systems?  If so, could anyone point me in the right
>> direction?  I don't want to use distcc please.
>>
>> CHOST="x86_64-pc-linux-gnu"
>> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
>
>
> Switching to -mtune=native seems to work.  Time for an emerge -e world.
>

This still might fail after a sufficient amount of time, you may want
to run cpuid2cpuflags on all of the laptops. I'm not sure if there is
a way around this. You may be able to refer to the Intel ARK to look
up processor and family capabilities directly.

R0b0t1.

Re: [gentoo-user] Lowest common denominator compile

[Walter Dnes]

On Mon, Sep 04, 2017 at 12:39:02PM -0700, Grant wrote
> 
> Now I'm running into "trap invalid opcode" errors on the older
> systems.  Can I disable some of the newer CPU instruction sets on the
> master laptop when compiling to hopefully generate binaries that will
> work on the older systems?

  Yes.  You need to find out CPU_FLAGS_X86 and "-march=" values the
machines have, and use that in make.conf.  Run the commands...

cpuinfo2cpuflags-x86
gcc -c -Q -march=native --help=target | grep march=

...on the target machines.  This will tell you what "native" is and
what CPU_FLAGS_X86 values to use.

https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
lists available "march=" options, and what instruction sets they support.
E.g. my old core2 desktop shows...

[d531][waltdnes][~] cpuinfo2cpuflags-x86
CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"

[d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
  -march=                               core2


  Unless the laptops are really old, you can probably get away with...
CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"

booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
a "march=" that implements the "movbe" instruction.

booby trap 2) If you throw in any AMD-based machines proceed with care.

  Can you post the output of...
gcc -c -Q -march=native --help=target | grep march=
...for all the target machines?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Lowest common denominator compile

[Grant]

>> Now I'm running into "trap invalid opcode" errors on the older
>> systems.  Can I disable some of the newer CPU instruction sets on the
>> master laptop when compiling to hopefully generate binaries that will
>> work on the older systems?
>
>   Yes.  You need to find out CPU_FLAGS_X86 and "-march=" values the
> machines have, and use that in make.conf.  Run the commands...
>
> cpuinfo2cpuflags-x86
> gcc -c -Q -march=native --help=target | grep march=
>
> ...on the target machines.  This will tell you what "native" is and
> what CPU_FLAGS_X86 values to use.
>
> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
> lists available "march=" options, and what instruction sets they support.
> E.g. my old core2 desktop shows...
>
> [d531][waltdnes][~] cpuinfo2cpuflags-x86
> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
>
> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
>   -march=                               core2
>
>
>   Unless the laptops are really old, you can probably get away with...
> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>
> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
> a "march=" that implements the "movbe" instruction.
>
> booby trap 2) If you throw in any AMD-based machines proceed with care.
>
>   Can you post the output of...
> gcc -c -Q -march=native --help=target | grep march=
> ...for all the target machines?


Let's see how -mtune=native goes and resort to the above if necessary.
It doesn't look too bad though.

Thanks,
Grant

Re: [gentoo-user] Lowest common denominator compile

[Grant]

>>> Now I'm running into "trap invalid opcode" errors on the older
>>> systems.  Can I disable some of the newer CPU instruction sets on the
>>> master laptop when compiling to hopefully generate binaries that will
>>> work on the older systems?
>>
>>   Yes.  You need to find out CPU_FLAGS_X86 and "-march=" values the
>> machines have, and use that in make.conf.  Run the commands...
>>
>> cpuinfo2cpuflags-x86
>> gcc -c -Q -march=native --help=target | grep march=
>>
>> ...on the target machines.  This will tell you what "native" is and
>> what CPU_FLAGS_X86 values to use.
>>
>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
>> lists available "march=" options, and what instruction sets they support.
>> E.g. my old core2 desktop shows...
>>
>> [d531][waltdnes][~] cpuinfo2cpuflags-x86
>> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
>>
>> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
>>   -march=                               core2
>>
>>
>>   Unless the laptops are really old, you can probably get away with...
>> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>>
>> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
>> a "march=" that implements the "movbe" instruction.
>>
>> booby trap 2) If you throw in any AMD-based machines proceed with care.
>>
>>   Can you post the output of...
>> gcc -c -Q -march=native --help=target | grep march=
>> ...for all the target machines?
>
>
> Let's see how -mtune=native goes and resort to the above if necessary.
> It doesn't look too bad though.


emerge -e world has finished and pushed and -mtune=native seems to
have solved the issue for now.

- Grant

Re: [gentoo-user] Lowest common denominator compile

[R0b0t1]

On Tue, Sep 5, 2017 at 10:28 PM, Grant <emailgrant@gmail.com> wrote:
>>>> Now I'm running into "trap invalid opcode" errors on the older
>>>> systems.  Can I disable some of the newer CPU instruction sets on the
>>>> master laptop when compiling to hopefully generate binaries that will
>>>> work on the older systems?
>>>
>>>   Yes.  You need to find out CPU_FLAGS_X86 and "-march=" values the
>>> machines have, and use that in make.conf.  Run the commands...
>>>
>>> cpuinfo2cpuflags-x86
>>> gcc -c -Q -march=native --help=target | grep march=
>>>
>>> ...on the target machines.  This will tell you what "native" is and
>>> what CPU_FLAGS_X86 values to use.
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
>>> lists available "march=" options, and what instruction sets they support.
>>> E.g. my old core2 desktop shows...
>>>
>>> [d531][waltdnes][~] cpuinfo2cpuflags-x86
>>> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
>>>
>>> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
>>>   -march=                               core2
>>>
>>>
>>>   Unless the laptops are really old, you can probably get away with...
>>> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>>>
>>> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
>>> a "march=" that implements the "movbe" instruction.
>>>
>>> booby trap 2) If you throw in any AMD-based machines proceed with care.
>>>
>>>   Can you post the output of...
>>> gcc -c -Q -march=native --help=target | grep march=
>>> ...for all the target machines?
>>
>>
>> Let's see how -mtune=native goes and resort to the above if necessary.
>> It doesn't look too bad though.
>
>
> emerge -e world has finished and pushed and -mtune=native seems to
> have solved the issue for now.
>

You might be interested in "-march=x86-64 -mtune=generic" though this
will mean you might miss out on some optimizations.

Re: [gentoo-user] Lowest common denominator compile

[Grant]

>>>>> Now I'm running into "trap invalid opcode" errors on the older
>>>>> systems.  Can I disable some of the newer CPU instruction sets on the
>>>>> master laptop when compiling to hopefully generate binaries that will
>>>>> work on the older systems?
>>>>
>>>>   Yes.  You need to find out CPU_FLAGS_X86 and "-march=" values the
>>>> machines have, and use that in make.conf.  Run the commands...
>>>>
>>>> cpuinfo2cpuflags-x86
>>>> gcc -c -Q -march=native --help=target | grep march=
>>>>
>>>> ...on the target machines.  This will tell you what "native" is and
>>>> what CPU_FLAGS_X86 values to use.
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
>>>> lists available "march=" options, and what instruction sets they support.
>>>> E.g. my old core2 desktop shows...
>>>>
>>>> [d531][waltdnes][~] cpuinfo2cpuflags-x86
>>>> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
>>>>
>>>> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
>>>>   -march=                               core2
>>>>
>>>>
>>>>   Unless the laptops are really old, you can probably get away with...
>>>> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>>>>
>>>> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
>>>> a "march=" that implements the "movbe" instruction.
>>>>
>>>> booby trap 2) If you throw in any AMD-based machines proceed with care.
>>>>
>>>>   Can you post the output of...
>>>> gcc -c -Q -march=native --help=target | grep march=
>>>> ...for all the target machines?
>>>
>>>
>>> Let's see how -mtune=native goes and resort to the above if necessary.
>>> It doesn't look too bad though.
>>
>>
>> emerge -e world has finished and pushed and -mtune=native seems to
>> have solved the issue for now.
>>
>
> You might be interested in "-march=x86-64 -mtune=generic" though this
> will mean you might miss out on some optimizations.


If I could miss out on optimizations, what is the advantage compared
to -mtune=native?  Better compatibility across CPUs?

- Grant

Re: [gentoo-user] Lowest common denominator compile

[R0b0t1]

On Tue, Sep 5, 2017 at 10:43 PM, Grant <emailgrant@gmail.com> wrote:
>>>>>> Now I'm running into "trap invalid opcode" errors on the older
>>>>>> systems.  Can I disable some of the newer CPU instruction sets on the
>>>>>> master laptop when compiling to hopefully generate binaries that will
>>>>>> work on the older systems?
>>>>>
>>>>>   Yes.  You need to find out CPU_FLAGS_X86 and "-march=" values the
>>>>> machines have, and use that in make.conf.  Run the commands...
>>>>>
>>>>> cpuinfo2cpuflags-x86
>>>>> gcc -c -Q -march=native --help=target | grep march=
>>>>>
>>>>> ...on the target machines.  This will tell you what "native" is and
>>>>> what CPU_FLAGS_X86 values to use.
>>>>>
>>>>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
>>>>> lists available "march=" options, and what instruction sets they support.
>>>>> E.g. my old core2 desktop shows...
>>>>>
>>>>> [d531][waltdnes][~] cpuinfo2cpuflags-x86
>>>>> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
>>>>>
>>>>> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
>>>>>   -march=                               core2
>>>>>
>>>>>
>>>>>   Unless the laptops are really old, you can probably get away with...
>>>>> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>>>>>
>>>>> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
>>>>> a "march=" that implements the "movbe" instruction.
>>>>>
>>>>> booby trap 2) If you throw in any AMD-based machines proceed with care.
>>>>>
>>>>>   Can you post the output of...
>>>>> gcc -c -Q -march=native --help=target | grep march=
>>>>> ...for all the target machines?
>>>>
>>>>
>>>> Let's see how -mtune=native goes and resort to the above if necessary.
>>>> It doesn't look too bad though.
>>>
>>>
>>> emerge -e world has finished and pushed and -mtune=native seems to
>>> have solved the issue for now.
>>>
>>
>> You might be interested in "-march=x86-64 -mtune=generic" though this
>> will mean you might miss out on some optimizations.
>
>
> If I could miss out on optimizations, what is the advantage compared
> to -mtune=native?  Better compatibility across CPUs?
>

Well, having looked it up (again), -march will break backwards
compatibility while -mtune=native will not if you stay within a family
of processors. So, yes.

One of the finer points of -mtune is that is specifies processor cache
sizes. If this is set to an incorrect value you could get very poor
performance relative to leaving it unset (with -mtune=generic).

For the exact differences, try:

gcc -march=native -mtune=native -E -v - </dev/null 2>&1 | grep cc1
echo | gcc -dM -E - -march=native

Which will show you the expanded compilation flags and macro
definitions, respectively.