Там бОльшая часть позволяет выбрать модули ядра: дрова и фс.
С дефолтными настройками (у дистрибутовов) ядро такое получается:

Без сжатия будет мегабайт 7. Если поиграешься с модулями, то получишь ядро меньше на мегабайт, что с того? Да, ещё можно сэкономить место на диске за счёт модулей:

Мне не критично +/- 50 мб, думаю, что и бОльшинству пользователей тоже.

Конечно, есть довольно интересные настройки. Но для обычного использования они не нужны (в общем-то их ещё больше в /proc/sys/xxx), а дефолтные вполне позволяют комфортно работать.

Теперь о прикладном софте. Повышение производительности достигается в общем случае за счёт двух возможностей: оптимизации кода и использования использования аппаратных инструкций (SSEx, например). Наборы инструкций включать при компиляции безопасно, но часто бесполезно, так как они не используются в коде. Флаги оптимизации, как уже сказали выше, довольно небезопасны и могут приводить к серьёзным глюкам. Неплохой пример — использование volatile в Си/С++.
Многие опенсурсные проекты просят не использовать флаги оптимизации при сборке.

У меня, например, всегда пересобран только mplayer и некоторые его зависимости. Так как по умолчанию там ограниченный набор мультимедийных инструкций (SSE1-2 или SSE1-3), а вот код может использовать очень много аппаратного добра.
Ещё последнее время приходиться на работе собирать ядро линукса (нужны определённые фитчи и дополнительные патчи).

Сорри за оффтопик, но мне вот интересно, почему в линуксовом мире не особо принято:
1. Вынести все процессорозависимые функции в отдельную либу.
2. При старте приложения расставить указатели в одной таблице - чтобы использовать то, что доступно на данном процессоре (для остального - ручные реализации)
3. При линковке это всё инлайнить, конечно (скорее всего)

Да, очевидно, размер будет больше. Да, очевидно, это незначительно проигрывает непосредственной сборке под нужный набор инструкций. Но зато имеем универсальный бинарник, который работает (если он может активно юзать какие-то векторные и пр. инструкции) гораздо быстрее (на среднестатистическом компе), чем "обычный".

Любитель, это жесткий офф-топик. Это карается лоботомией.
Попросите одмина стереть ваш и мой комменты, а свой вопрос вынесите в отдельный топик. там и покуролесим.

Обычно так и делают. А при компиляции в зависимости от флагов решают, что компановать.


А зачем?


Если нормально собрать обычный, то он будет так же шустро работать. Только не будет всякого хлама в коде, который в рантайме определяет библиотеки и подгружает их.

Что значит нормально собрать? Если самому собрать с нужными флагами - это всё очевидно и неинтересно. Речь об использовании готовых бинарников.


Ну и в итоге:
1. Либо собирай сам
2. Либо распространять кучу вариантов бинарей


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

ну уже давно 2.6.36 , да и размер мне так же не важен.


Так то да, но приятнее решать самостоятельно, что не нужно, вот об этом и речь )


CFLAGS="-O3 -march=native -mtune=native -pipe" # -msse4.1 -fipa-cp -ftree-loop-linear"
~amd64 KDE desctop , как часы. На ноуте использую О3, на десктопе О2, так как при сборке Кед из транка требуется некая осторожность.
Возможно производительности это сильно не прибавляет, но как знать... 

Могу подытожить - я выбираю этот дистр, так как мне всё это интересно, а в этой системе всё достаточно прозрачно и элегантно, чем больше у меня опыта тут, тем больше моя система будет подходить именно мне, а не дяде Ване. У меня уже есть даже заготовка своей так сказать Stage4 с почти собранным KDE-Live, вот тут действительно лотерея, но на случай слётов есть OpenBox. 

Ну так 99% софта под Linux и распространяется либо в виде исходников, либо в виде уже собранных пакетов в составе некоторого конкретного дистрибутива. Причины, пожалуй, исторические - когда-то весь софт поставлялся вместе с компьютером, и другие варианты были попросту нерациональны.

да, я всё прекрасно понимаю - что исторически сложилось...


Объективно - source based дистрами мало кто пользуется (во время своего юзания линукса - у самого прижилась только джента, но это ничего не значит). А дистрибутива - обычно один по x64, другой под i586 (в лучшем случае - 686). Разве встречается больше вариаций?

Для одной версии одного дистрибутива - нет (бывает, конечно, но редко), но уже для разных версий варианты могут быть разными (например, из-за разных версий используемых библиотек). Для разных дистрибутивов отличия еще заметнее.

Сорри конечно, но аффтарам, которые пишут софт, чудом работающий исключительно с определённым набором флагов лучше сразу отрывать руки.

Кстати, насчет кода оптимированного под конкретное железо - многие мультимедиа либы так и делают (тот же mplayer например), а в не-мультимедиа это никому и не нужно.

в каких-то версиях gcc в CFLAGS присутствует скрытый дефект: -ffast-math, который оборачиваектся для нас -funsafe-math-optimizations -fno-math-errno http://www.freebsd.org/cgi/query-pr.cgi?pr=137869

AFAIR в mplayer-е для этого куча асм-овых либ. А я говорю, чтобы это всё либо компилятор генерил, либо была статическая либа в рантайме компилера.

А как же не x86 архитектуры? Всё равно во время компиляции приходится решать, что компановать. Тот же mplayer имеет оптимизации для ряда платформ:



На мой взгляд, зачастую это проблема компилятора, а не человека.
Рекомендации не использовать -O3 были в документации по KDE3, если мне не изменяет память. Вот кутяшный пример уже наших дней: http://www.qtforum.org/article/27474/qt-cr...ease-build.html