| |
| |
| |
| 4.46, pavlinux (ok), 15:51, 25/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 >> А накой вам?
> Дык это, натой чтобы закомпилить свой кернель под такую железяку. Благо их
> как грязи развелось таких, армовских и мипсовых. И недорогие. И мелкие.
> Вплот до штук со спичечный коробок размерами, и при том -
> полноценный комп с линухом по сути. Это ж прикольно, а? :)
Я собственна о том, что покупая МИПС/АРМ уже надо знать шо таке кросс-компиляция
| | |
|
|
|
| |
| 2.5, andrewlap (?), 15:30, 20/03/2011 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +2 +/– |
> А какие-нибудь performance тесты не проводили? Есть ли какой-нибудь реальный смысл во
> всем этом?
Тесты не проводились, в интернете о подобных тестах ничего нет. Я раньше на Gentoo сидел, там можно было всю систему так откомпилировать, но там в репозитории пакеты нестабильные, и частенько что нибудь падало, и я пересел на дебиан, а теперь вот на ubuntu, но в этих дистрибах ничего подобного нет, с apt-build-ом у меня не сложилось, и судя по отзывам ни у кого он нормально не работает, а в заднице свербило, ведь в gcc можно указать отпции компиляции под процессор, а ubuntu и debian пакеты компиляются с опцией i386 или в лучшем случае i686. Теоретически при указании gcc компиляции кода под заданный проц. код должен получаться быстрее. Но никто тестами пока это не подтвердил, потому что непонятно что тестировать и как. Судя по всему прирост будет не во всех задачах. Я сижу на таком откомпиленном ядре, в принципе тачила мощная так что ей пофик на каком ядре работать.
Но спросите любого гентушника - он вам ответит что gentoo работает процентов на 15 быстрее. Скорее всего эти проценты взяты с потолка, и гентушники в них свято верят, иначе если не верить в это, зачем же тогда компилять всю систему?
| | |
| |
| |
| 4.44, User294 (ok), 15:44, 25/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
 > Не факт что при этом не добавится трудновоспроизводимых глюков.
Регулярно вижу криворуких уродов (с понятно какой системой), которые сперва как ввинтят флагов для "адской оптимизации" на целых два этажа, со всей дури, чтобы выжать еше 3% скорости vs -O2, а потом идут и со всей дури плакаются в багтрекеры: "в вашей программе баг!". Хотя на самом деле баг в 80% случаев сугубо в мозгах дятла который ввинтил свой трехэтажный малопротестированный набор фич оптимизации и резонно поимел неочевидные глюки. Связанные с тем что такую дикую этажерку флагов оптимизации никто до него вообще не тестировал и компилер оказывается изредка в такой ситуации генерит слегка глючный код, перемудрив с оптимизацией. Не, ну ладно б еще авторам гцц баги писали, если уж так принципиально чтобы эта этажерка все-таки полетела и не глючила именно с таким набором флагов, так ведь нет, за что-то мозг выносят ни в чем не виноватым авторам постороннего софта. Которые ни разу не виноваты в том что у очередного пионера жопа просила приключений, елки.
| | |
| 4.54, bircoph (ok), 21:22, 04/04/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 > Думаю перекомпиляция ядра в производительности заметно не добавит. Вот пересборка glibc,
> GTK, QT думаю даст процентов 10-15. Не факт что при этом
> не добавится трудновоспроизводимых глюков.
Гентушники тихо хохочут в сторонке. Грамотная пересборка всей системы даёт от 10% до 250% (двести пятьдесят, это не опечатка), в зависимости от приложения. Из багов, вызванных сборкой из исходников, за три года не нескольких разных системах поймал только один.
| | |
|
|
| |
| 3.36, Вова (?), 11:02, 23/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Проводили, и не раз. Естественно, толку никакого.
> Задрачивание флагов компиляции, сборка монолита "без лишних модулей" и без initrd -
> на обычном десктопе это гентушно-юношеский максимализм. С возрастом проходит.
Я вполне себе юн и свеж, а под гентой уже более 5 лет, и так и думал, как и вы, про флаги компиляции. Но вот попался один бд-рип ("baraka", не суть важно), и встроенная видяйка на базе geforce 8200 - не тянула, vdpau ругалось. Воткнул видимокарту на базе gt210 - помогло, но не полностью. Добавил в юсе флаги sse, sse2, реемергнул ффмпег, мплеер, влц - без изменений. Емергнул ворлд с этими новыми флагами (newuse) (потратилось сутки на мои 520 пакетов), о Чудо! Всё акей, никаких подёргиваний, красиво. Отрицательный момент - не могу сказать какой именно пакет сыграл свою роль.
| | |
| |
| 4.37, pavel_simple (ok), 20:21, 23/03/2011 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 >[оверквотинг удален]
>> на обычном десктопе это гентушно-юношеский максимализм. С возрастом проходит.
> Я вполне себе юн и свеж, а под гентой уже более 5
> лет, и так и думал, как и вы, про флаги компиляции.
> Но вот попался один бд-рип ("baraka", не суть важно), и встроенная
> видяйка на базе geforce 8200 - не тянула, vdpau ругалось. Воткнул
> видимокарту на базе gt210 - помогло, но не полностью. Добавил в
> юсе флаги sse, sse2, реемергнул ффмпег, мплеер, влц - без изменений.
> Емергнул ворлд с этими новыми флагами (newuse) (потратилось сутки на мои
> 520 пакетов), о Чудо! Всё акей, никаких подёргиваний, красиво. Отрицательный момент
> - не могу сказать какой именно пакет сыграл свою роль.
а ведь мог почеловечески перекодировать фильм в mpeg2
| | |
| 4.47, Аноним (-), 18:26, 25/03/2011 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Кстати да. Правда на 720p, но и на более слабом проце... vdpau, как оказалось, не завелось... А я и не заметил. Хотя это более идеологический вопрос, пожалуй. Меня вот коробит, что у меня тут sse2, sse3, ну и вообще весь такой из себя проц..., а собрано всё под generic amd64.... ( Это если ось 64 битная... А так и под i386 вообще.
| | |
|
|
| 2.31, crypt (??), 11:34, 22/03/2011 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
> А какие-нибудь performance тесты не проводили? Есть ли какой-нибудь реальный смысл во всем этом?
Когда я н лет назад развлекался пересборкой ядра, то не стряпал в дцатый раз посты, как собрать ядро под линукс, а как раз тесты и проводил. Вроде разница была заметна на глаз. +/- 20-30 секунд при 3х минутной распаковке архива. Хотя было давно и уже толком не помню.
Наверное, топики про пересборку ядра, взломом вайфай ... (что там еще?) никогда не умрут.%(
| | |
|
| |
| 2.10, andrewlap (?), 21:43, 20/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
Вот сейчас проверял у меня ps af | grep cc1 выдаёт следующее:
\_ /usr/lib/gcc/i686-linux-gnu/4.4.5/cc1 -quiet -nostdinc -I/usr/src/linux-source-2.6.35/arch/x86/include -Iinclude -Iubuntu/include -D__KERNEL__ -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(apic_noop) -DKBUILD_MODNAME=KBUILD_STR(apic_noop) -isystem /usr/lib/gcc/i686-linux-gnu/4.4.5/include -include include/generated/autoconf.h -MD arch/x86/kernel/apic/.apic_noop.o.d arch/x86/kernel/apic/apic_noop.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase apic_noop.c -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=core2 -mtune=generic -maccumulate-outgoing-args -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -auxbase-strip arch/x86/kernel/apic/.tmp_apic_noop.o -g -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wno-format-security -Wno-sign-compare -Wframe-larger-than=1024 -Wdeclaration-after-statement -Wno-pointer-sign -p -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -freg-struct-return -ffreestanding -fstack-protector -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-strict-overflow -fconserve-stack -fstack-protector -o -
то есть как вы можете наблюдать опции -march=i686 -mtune=core2 проставлены. У меня процессор core 2 duo, и эти опции компилятор автоматически поставил вместо -march=native
видимо лучше жёстко проставить -march=core2 для более лучшей оптимизации, ибо как извесно опции -march=i686 -mtune=core2 выдают код который будет работать на процессорах от pentiumpro(i686) и выше, при жёстком указании -march=core2 будет выдавать код чисто для core2
| | |
| |
| 3.12, pavlinux (ok), 23:02, 20/03/2011 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
> и эти опции компилятор автоматически поставил вместо -march=native
Сам придумал?
native
This selects the CPU to tune for at compilation time
by determining the processor type of the compiling
machine. Using -mtune=native will produce code
optimized for the local machine under the constraints
of the selected instruction set. Using -march=native
will enable all instruction subsets supported by the
local machine (hence the result might not run on
different machines).
-fno-omit-frame-pointer, тоже само поменялось?
| | |
| |
| |
| 5.17, pavlinux (ok), 23:34, 20/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> Не понял чо не так?
> Поправьте если лучше знаете.
> Насчёт -fno-omit-frame-pointer не в курсе, не специалист
Долго рассказывать. Хотите поменять флаги компиляции ядра?!
Тогда меняйте их:
Глобальные, в основном Makefile (где-то в районе 230 строки)
HOSTCFLAGS=
HOSTCXXFLAGS=
Тут низя писать флаги оптимизации под конкретный процессор !!!
можно типа -06/-O99, -frecord-gcc-switches, -g0 -funroll-all-loops
-ftree-vectorize -fno-inline-functions-called-once
-fmerge-all-constants, ну и так далее...
---
Для оптимизации под конкретный процессор надо менять в arch/x86/Makefile (под 32 бита в arch/x86/Makefile_32.cpu)
там найти свой проц, после строки export BITS есть тройка ifeq-else-endif
Дописывать можно к последнему KBUILD_CFLAGS
Тут можно всё, кроме FPU/SSE/MMX/3DNOW, -mcmodel=kernel не менять!!!
| | |
| |
| 6.19, andrewlap (?), 00:01, 21/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
> Глобальные, в основном Makefile (где-то в районе 230 строки)
> HOSTCFLAGS=
> HOSTCXXFLAGS=
> Тут низя писать флаги оптимизации под конкретный процессор !!!
> можно типа -06/-O99, -frecord-gcc-switches, -g0 -funroll-all-loops
> -ftree-vectorize -fno-inline-functions-called-once
> Для оптимизации под конкретный процессор надо менять в arch/x86/Makefile (под 32 бита
> Тут можно всё, кроме FPU/SSE/MMX/3DNOW, -mcmodel=kernel не менять!!!
вот жесть то! можот ну его нафик?
| | |
|
|
|
| |
| |
| 5.16, Аноним (-), 23:29, 20/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
у меня -march выставляет только в зависимости от опции в конфиге "Processor family", а опции из CFLAGS не применяются. проверял с export CFLAGS="-march=native -O3", в итоге выходило -march=(то что я выбрал в конфиге, пробовал несколько вариантов k8 и x86-64, а native должен дать amdfam10) и -O2
| | |
| |
| 6.18, pavlinux (ok), 23:42, 20/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> у меня -march выставляет только в зависимости от опции в конфиге "Processor
> family", а опции из CFLAGS не применяются. проверял с export CFLAGS="-march=native
> -O3", в итоге выходило -march=(то что я выбрал в конфиге, пробовал
> несколько вариантов k8 и x86-64, а native должен дать amdfam10) и
> -O2
Да не использует ядро переменную CFLAGS из окружения.
Проверить легко - надо задать неправильные флаги:
export CFLAGS="-mtune=shit -march=govno"
---
Хотите заменить, тогда задаёте
# export HOSTCFLAGS="-O99 -mtune=native -funroll-all-loops"
# export KBUILD_CFLAGS="-O99 -mtune=native -funroll-all-loops"
# make -e menuconfig
# make -e
Целиком менять не надо, скопируйте старые HOSTCFLAGS и KBUILD_CFLAGS
и добавьте или замените нужное. Так как make -e перепишет полностью
эту переменную из Makefile вашими.
Если всё поломаете, сами виноваты. :)
| | |
|
|
|
| 3.48, Аноним (-), 18:38, 25/03/2011 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Кстати, gcc 4.5 (может и в более ранних версиях) выдаёт чуть больше оптимизаций, чем просто подстраивание march под ваш проц. Там что-то типа cach-line-size и что-то ещё в этом роде. Сейчас под рукой нет. Конфетка, вобщем. Кстати, собирать _только_ едро с march=native и проч. не вижу особо смысла без пересборки, хотя бы, мира. Там то уж оптимизации побольше подразгуляются, ИМХО.
| | |
|
|
| 1.24, suseuser (?), 17:36, 21/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Компиляция ядра дает выигрыш в том случае, когда вы выбираете нужные драйверы, службы и т.д., а удаляете не нужные. В этом случае ядро становится компактным без лишнего, не нужного ВАМ кода. В остальных случаях ядро компилят с включением каких-то специализированных патчей, например, для протокола SPICE. И в том и в другом случае напортачить можно на раз, поэтому если нужна производительность - отказывайтесь от универсальных дистрибутивов в пользу заточенных под определенную задачу
| | |
| |
| 2.25, andrewlap (?), 17:49, 21/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Я в это не верю.
Сейчас в дистрибутивах ядро весит не более 10 Мб, при этом обычно разработчики дистрибутивов включают в ядро самое необходимое, а доп опции компилируют модулями, которые подключаются автоматически, если обнаруживается соответствующее оборудование или ПО либо при указании вручную в соотвествующих конфигах.
Я потрачу несколько дней чтобы убрать всё ненужное из ядра, и что бы оно при этом компилялось, что бы оно полегчало пусть на 1 МБ? Оно мне надо? У меня памяти несколько Гигов, своп вообще не юзается, я таких ядер десятками в памяти держать могу.
| | |
|
| 1.51, Андрей (??), 17:30, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
И ещё: регулярно исполбзую make-kpkg, но пока не удалось после нанесения очередного patch-2.6.xx.x пересобрать пакет без полного предшествующего make-kpkg clean. А нужно-то было бы всего несколько (пропатченных) файлов перекомпилить, вместо всего ядра. Или есть у make-kpkg где-то такая фича, чтобы гибче было?
| | |
|
