On 14/08/2013 16:23, Paul Hartman wrote:
On Wed, Aug 14, 2013 at 12:18 AM, Pandu Poluan <pa...@poluan.info
<mailto:pa...@poluan.info>> wrote:
I know that the (theoretical) best performance is to use
-march=native , but since the processors of the HP servers are not
exactly the same as the Dell's, I'm concerned that compiling with
-march=native will render the VMs unable to migrate between the
different hosts.
I use -mtune=native rather than -march=native, that way I can use some
advanced processor features if they are available, but my system will
still run if moved to a different host.
That's not how -mtune works. If -march is unspecified, it will default
to the lowest common denominator for the platform which prevents the use
of any distinguished processor features. For an amd64 install, that
would be "-march=x86-64".
Instead, -mtune affects everything that -march doesn't. Though it
doesn't affect the instructions that *can* be used, it may effect which
of the allowed instructions are used and how. For instance, gcc includes
processor pipeline descriptions for different microarchitectures so as
to emit instructions in a way that tries to avoid pipeline hazards:
http://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html
If performance matters, a better approach is to look at what
-march=native enables and manually specify all options that are common
between the hosts. Further, if the host CPU microarchitecture varies
then I would suggest adding -mtune=generic so as not to make potentially
erroneous assumptions in the course of applying that type of
optimisation. Indeed, -mtune=generic is the default if neither -march
nor -mtune are specified.
Regarding qemu, the main thing is never to use a feature that would
incur costly emulation on the host side.
--Kerin
