Mail Archives: cygwin/2007/06/28/15:42:32
Mike Marchywka wrote:
> This doesn't have anything to do with cygwin but it can be an important
> point.
> Some compilers or applications , I think Intel IIRC, can figure out which
> processor you have
> at run time and pick which code to run- obviously the exe size gets large
> but
> if you need speed it can be helpful. I've thrown in assembly code that needs
> certain fpu's and its great as long as you have a fall back or diagnostics
> and don't
> fail with an unexplained invalid instruction of "core dump."
Recent versions of gcc have -march=native, when tells the compiler to
detect the architecture of the machine it's running on do the equivalent
-march= of that. However this happens at compile time, not at runtime,
so this is not a substitute for the common practice of compiling several
different architecture-specific versions of performance sensitive code
and then detecting at runtime which to call.
There is also -mtune=generic which is the new default tuning. This is a
tweaked scheduler model that is meant to provide balanced performance on
a wide array of common modern architectures, i.e.
pentium4/prescott/nocona/core2/k8. As I understand it, this is not so
much specific to any one arch, it's just a better default compromise
that reflects the current modern state of the field better than the old
-mtune=i386. Being a "tune" and not an "arch" it doesn't affect
instruction set selection, i.e. the code that gcc outputs by default
should still should run fine on any 386 class machine, unless either the
user gave overriding options or the compiler was built with an -march
override (configure --with-arch=foo).
But both of these are too new to be in Cygwin's gcc 3.4.x so this is
kind of off-topic.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -