компилирование под определенную архитектуру процессора

Как правило код, умеющий пользоваться хитрыми расширениями, переключается между реализациями динамически (кодеки всякие, криптография). Перекомпиляция не требуется.

Так же, числомолотильный код может выиграть в разы при заточке под конкретный cpu. Код общего назначения ничего обычно не выигрывает.

Как отличить код общего назначения от числомолотильного? Например gcc это какой?

Как правило, код проектов, где требуются специфические возможности процессоров, написан так, чтобы можно было задействовать этот функционал вне зависимости от опций компилятора. Например ассемблерные вставки в кодеках и плеерах, которые могут определять тип процессора и включать соответствующий функционал. Поэтому, перекомпиляция под конкретные особенности процессора не всегда даёт ощутимый прирост производительности.

Опередил

Gcc совершенно memory-bound, как и вообще любой компилятор. Арифметика ему вообще не нужна.

Или увеличение производительности можно увидеть только на определенных задачах, тогда на каких?

Софтварное декодирование видео, софтварный рендеринг. В такой софт обычно зашивают рантаймовые проверки фич cpu и код работает по-разному в зависимости от имеющихся фич.

Для твоего любимого ФМ/плеера/whatever профита нету, да.

Да тут похоже все ТредНеЧитай@СразуОтвечай :)

Дополню ораторов выше конкретным примером (вручную собранный mplayer на машине безо всяких SSE4 и AVX):

Disassembling /usr/bin/mplayer, please wait...

        MMX:         81119
        SSE:          4124
        Enh 3DNow:      15
        SSE2:        14434
        SSE3:           14
        SSSE3:         970
        SSE4A:           0
        SSE4.1:         79
        SSE4.2:          0
        AVX:          6843
        FMA:            20
        FMA4:           18


This binary was found to contain the cpuid instruction.
This could mean that the application checks if an opcode is
supported before executing it, meaning it may work even if
these instructions are not supported on the host.

В общем то не слишком ощутимо ускоряет, особенно на amd64 (архитектура относительно молодая большинство оптимизаций в отличии от i386/i568 доступны на всех процах). А вот отключение всякого мусора при сборке дает оигенный профит, в юзах мощь генты, а так и дебиан можно пересобрать средствами apt.

Про юз флаги и так понятно, меня интересовало почему компилирование под проц не дает эффекта, оказалась та же ситуация что и с -O3 для gcc, все что можно оптимизировать уже оптимизировали разработчики.

Как это «не дает эффекта»? Очень даже дает. Для числомолотильного кода. Если тебе не нужна числодробильня, то не трогай ключи компилятора.

Как отличить код общего назначения от числомолотильного?

По алгоритму. И по задаче. Криптография, скажем, типичная числомолотилка. А вот сортировка - нет.

Пусть трогает. Я вот дописываю -fstack-protector еще.

Как это «не дает эффекта»?

Я имел в виду общий случай, офисы, браузеры...

Общий случай - неинтересное говно. Там все вообще i/o bound.

Конкретных цифр не приведу, но эти оптимизации хорошо себя в теории показывают на 32-х битных системах. на 64-битах, как уже сказали выше, многое включено по умолчанию.
Спорный момент, но отдельные адепты пишут про +30% на AMD процессорах, ибо очень специфические оптимизации типа. Под Intel, принято считать, что все уже и так оптимизировано из коробки.

Не все. Профит все же есть, но он не велик.