[SOLVED] -march=native as configure option?

[NicolasRobidoux]

Wouldn't it be a good idea to have -march=native be on by default when building from source? http://en.gentoo-wiki.com/wiki/Safe_Cflags

[NicolasRobidoux]

Of course I can get it with

Code: Select all

CFLAGS="-march=native" ./configure

It just appears to me that this would be a good thing to have happen by default (with a check for recent enough gcc).

(How many people who don't know what they are doing cross-compile?).

[magick]

Look for a patch for the gcc arch option by sometime tomorrow. Thanks.

[NicolasRobidoux]

@magick: I imagine you know about this already, but just in case: configure may need to check whether gcc is recent enough to have native as a recognized -march option. (I'm not a configure expert...)

[NicolasRobidoux]

I also have no idea whether this may mess things up for distro package maintainers (who should be able to immediately recognize that this is vanilla is not what they want, if vanilla is -march=native).

One way to avoid such problems (if there are any: I'm out of my comfort zone here) is to suggest the use of CFLAGS="-march=native" ./configure in the documentation http://www.imagemagick.org/script/advan ... lation.php and elsewhere, explaining that if you are planning to use the binaries on a machine with a different chip set (if you are planning to cross-compile) you should not use this.

Also, it may be good to add a note in the documentation to the effect that if you are running ImageMagick on a busy server you may want to compile with --disable-openmp. (See, e.g., http://dlcware.blogspot.com/2010/12/ima ... y-bad.html.) It's the

If you have one big job and lots of workers, put all workers on the job. But if you have lots of jobs, give one job to each worker so that they don't waste time coordinating.

principle. (This rule of thumb is sometimes mitigated by another one having to do with workers sharing limited workspace or tools, but if the memory requirements of the individual tasks are moderate and GPUs are not heavily involved this amendment should not apply. You want to avoid jobs being swapped in and out.)

(I don't claim to be a big expert here: These are just suggestions.)

[magick]

By default the gcc arch option is not included on the command line. You can set it with "configure --with-gcc-arch=native".

[NicolasRobidoux]

@magick: Makes complete sense.

Thank you!

[NicolasRobidoux]

@magick:

If I understand correctly, you implemented --with-gcc-arch through AX_GCC_ARCHFLAG.

Without an argument, AX_GCC_ARCHFLAG sets the optional argument PORTABLE? to [yes], in which case -mtune is used instead of -march so that although the code is optimized for the native chip, it is still portable.

Unfortunate side effect: chip-specific instruction sets are NOT used.

I thought that changing AX_GCC_ARCHFLAG in configure.ca to

Code: Select all

AX_GCC_ARCHFLAG([no])

would be enough, but it is not.

I think that it is because, in the file ax_gcc_archflag.m4, if test "x[]m4_default([$1],yes)" = xyes turns out to be true. I don't know quite enough about m4 to quickly figure out where this is set, or whether this has something to do with AX_GCC_ARCHFLAG requiring AX_CHECK_COMPILE_FLAG, AX_GCC_X86_CPUID, or whatever.

In any case,

Code: Select all

CFLAGS="-march=native" ./configure

and

Code: Select all

./configure --with-gcc-arch=native

do not produce equivalent CFLAGS, whether or not I tweak configure.ac.

Could you please fix this? (Or else, could you let me know that you'd rather I dig myself?)

(Apologies if I am missing something, for example that on my chip, a core2, it is somehow not preferable to use -march.)

[magick]

We'll have a patch in the Subversion trunk in about an hour. Thanks.