Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Клуб юнуксоидов > Флаги компиляции в опенсурс софте

Автор: powerfox 22.10.2010, 23:41

Цитата(A5uKa @  22.10.2010,  13:17 ) а как же весь menuconfig при настройке ядра ?  Там бОльшая часть позволяет выбрать модули ядра: дрова и фс. С дефолтными настройками (у дистрибутовов) ядро такое получается: Код fox@Crypta2:~> du -sh /boot/vmlinux-2.6.34-12-desktop.gz  5.2M    /boot/vmlinux-2.6.34-12-desktop.gz Без сжатия будет мегабайт 7. Если поиграешься с модулями, то получишь ядро меньше на мегабайт, что с того? Да, ещё можно сэкономить место на диске за счёт модулей: Код fox@Crypta2:~> du -sh /lib/modules/2.6.34-12-desktop/ 97M     /lib/modules/2.6.34-12-desktop/ Мне не критично +/- 50 мб, думаю, что и бОльшинству пользователей тоже. Конечно, есть довольно интересные настройки. Но для обычного использования они не нужны (в общем-то их ещё больше в /proc/sys/xxx), а дефолтные вполне позволяют комфортно работать. Теперь о прикладном софте. Повышение производительности достигается в общем случае за счёт двух возможностей: оптимизации кода и использования использования аппаратных инструкций (SSEx, например). Наборы инструкций включать при компиляции безопасно, но часто бесполезно, так как они не используются в коде. Флаги оптимизации, как уже сказали выше, довольно небезопасны и могут приводить к серьёзным глюкам. Неплохой пример — использование http://en.wikipedia.org/wiki/Volatile_variable в Си/С++. Многие опенсурсные проекты просят не использовать флаги оптимизации при сборке. У меня, например, всегда пересобран только mplayer и некоторые его зависимости. Так как по умолчанию там ограниченный набор мультимедийных инструкций (SSE1-2 или SSE1-3), а вот код может использовать очень много аппаратного добра. Ещё последнее время приходиться на работе собирать ядро линукса (нужны определённые фитчи и дополнительные патчи).

Автор: Любитель 23.10.2010, 09:15

Цитата(powerfox @  22.10.2010,  23:41 ) У меня, например, всегда пересобран только mplayer и некоторые его зависимости. Так как по умолчанию там ограниченный набор мультимедийных инструкций (SSE1-2 или SSE1-3), а вот код может использовать очень много аппаратного добра. Ещё последнее время приходиться на работе собирать ядро линукса (нужны определённые фитчи и дополнительные патчи).  Сорри за оффтопик, но мне вот интересно, почему в линуксовом мире не особо принято: 1. Вынести все процессорозависимые функции в отдельную либу. 2. При старте приложения расставить указатели в одной таблице - чтобы использовать то, что доступно на данном процессоре (для остального - ручные реализации) 3. При линковке это всё инлайнить, конечно (скорее всего) Да, очевидно, размер будет больше. Да, очевидно, это незначительно проигрывает непосредственной сборке под нужный набор инструкций. Но зато имеем универсальный бинарник, который работает (если он может активно юзать какие-то векторные и пр. инструкции) гораздо быстрее (на среднестатистическом компе), чем "обычный".

Автор: bilbobagginz 23.10.2010, 09:22

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

Автор: powerfox 23.10.2010, 14:43

Цитата(Любитель @  23.10.2010,  10:15 ) 1. Вынести все процессорозависимые функции в отдельную либу. Обычно так и делают. А при компиляции в зависимости от флагов решают, что компановать. Цитата(Любитель @  23.10.2010,  10:15 ) Но зато имеем универсальный бинарник А зачем? Цитата(Любитель @  23.10.2010,  10:15 ) который работает (если он может активно юзать какие-то векторные и пр. инструкции) гораздо быстрее (на среднестатистическом компе), чем "обычный".  Если нормально собрать обычный, то он будет так же шустро работать. Только не будет всякого хлама в коде, который в рантайме определяет библиотеки и подгружает их.

Автор: Любитель 23.10.2010, 16:07

Цитата(powerfox @  23.10.2010,  14:43 ) Если нормально собрать обычный, то он будет так же шустро работать. Что значит нормально собрать? Если самому собрать с нужными флагами - это всё очевидно и неинтересно. Речь об использовании готовых бинарников. Цитата(powerfox @  23.10.2010,  14:43 ) А при компиляции в зависимости от флагов решают, что компановать. Ну и в итоге: 1. Либо собирай сам 2. Либо распространять кучу вариантов бинарей Цитата(powerfox @  23.10.2010,  14:43 ) Только не будет всякого хлама в коде, который в рантайме определяет библиотеки и подгружает их.  Подгрузку ооочень редко делают (это уже вручную как раз несколько вариантов под разные процы). На практике статическая линковка и лишние 100-200 килобайт (условно - если честно, точно не знаю сколько) и маппинг нужных функций.

Автор: A5uKa 25.10.2010, 07:51

Цитата Там бОльшая часть позволяет выбрать модули ядра: дрова и фс. С дефолтными настройками (у дистрибутовов) ядро такое получается: Код fox@Crypta2:~> du -sh /boot/vmlinux-2.6.34-12-desktop.gz  5.2M    /boot/vmlinux-2.6.34-12-desktop.gz ну уже давно 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.

Автор: Фантом 25.10.2010, 10:00

Цитата(Любитель @  23.10.2010,  16:07 ) Ну и в итоге: 1. Либо собирай сам 2. Либо распространять кучу вариантов бинарей Ну так 99% софта под Linux и распространяется либо в виде исходников, либо в виде уже собранных пакетов в составе некоторого конкретного дистрибутива. Причины, пожалуй, исторические - когда-то весь софт поставлялся вместе с компьютером, и другие варианты были попросту нерациональны.

Автор: Любитель 26.10.2010, 14:49

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

Автор: Фантом 26.10.2010, 14:55

Цитата(Любитель @  26.10.2010,  14:49 ) А дистрибутива - обычно один по x64, другой под i586 (в лучшем случае - 686). Разве встречается больше вариаций?  Для одной версии одного дистрибутива - нет (бывает, конечно, но редко), но уже для разных версий варианты могут быть разными (например, из-за разных версий используемых библиотек). Для разных дистрибутивов отличия еще заметнее.

Автор: nickless 27.10.2010, 16:44

Цитата(powerfox @  22.10.2010,  22:41 ) Многие опенсурсные проекты просят не использовать флаги оптимизации при сборке Сорри конечно, но аффтарам, которые пишут софт, чудом работающий исключительно с определённым набором флагов лучше сразу отрывать руки. Кстати, насчет кода оптимированного под конкретное железо - многие мультимедиа либы так и делают (тот же mplayer например), а в не-мультимедиа это никому и не нужно.

Автор: gcc 27.10.2010, 23:02

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

Автор: Любитель 28.10.2010, 12:57

Цитата(nickless @  27.10.2010,  16:44 ) стати, насчет кода оптимированного под конкретное железо - многие мультимедиа либы так и делают (тот же mplayer например), а в не-мультимедиа это никому и не нужно. AFAIR в mplayer-е для этого куча асм-овых либ. А я говорю, чтобы это всё либо компилятор генерил, либо была статическая либа в рантайме компилера.

Автор: powerfox 30.10.2010, 14:12

Цитата(Любитель @  28.10.2010,  13:57 ) А я говорю, чтобы это всё либо компилятор генерил, либо была статическая либа в рантайме компилера.  А как же не x86 архитектуры? Всё равно во время компиляции приходится решать, что компановать. Тот же mplayer имеет оптимизации для ряда платформ: Цитата Most of time-critical parts are optimized for Intel/AMD (MMX/MMX2/SSE/SSE2/3DNow!/3DNowEx), PowerPC G4 (Altivec), SPARC (VIS), ARM  PDAs and the Sony Playstation 2. Цитата(nickless @  27.10.2010,  17:44 ) Сорри конечно, но аффтарам, которые пишут софт, чудом работающий исключительно с определённым набором флагов лучше сразу отрывать руки. На мой взгляд, зачастую это проблема компилятора, а не человека. Рекомендации не использовать -O3 были в документации по KDE3, если мне не изменяет память. Вот кутяшный пример уже наших дней: http://www.qtforum.org/article/27474/qt-creator-customize-optimization-flags-for-release-build.html Цитата QMAKE_CFLAGS_RELEASE    = -O2 -march=nocona -mtune=nocona I have compiled with core2, but that was unstable. In the end I have used nocona option.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)