Ядра ветки 2.6.x более не поддерживают старые версии GCC

По поводу 3.3: http://lkml.org/lkml/2006/1/17/386

>Линус Торвальдс также посоветовал не использовать GCC версий 4.0.1 и 4.0.2, т.к. они плохо собирают код с оптимизацией -Os.

А 4.1 хорошо работает?

Баян, недели полторы уж как известно:D

> А 4.1 хорошо работает?

Последний CVS качайте и собирайте. FC5 test2 на нём уже собрана.

> Баян, недели полторы уж как известно:D

То было в -mm, а это уже в -vanilla.

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

> все остальные передрали (как всегда).

Даа....великий birdie....все с него всегда все дерут.....:-D

Ну наконец-то! :) С компиляторами нужно расставаться легко, без стонов ;-)

Ну раз birdie не слепой, то скажи дату коммита....

Это было уже в git5, я чуточку ошибся....

И отображенно было тогдаже здесь http://wiki.kernelnewbies.org/LinuxChanges

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...

Немного оффтоп, но поясните, какой плюс от применения -Os?
Допустим, будет оно меньше по размерам, что даст небольшую разницу при запуске системы, а в плане общесистемной производительности как это может сказаться?
Разве при -Os не идет оптимизация размера в ущерб скорости?

>Последний CVS качайте и собирайте. FC5 test2 на нём уже собрана.

Ага, разогнался. FC5 final поставлю тогда. Я спрашивал, если кто знает, сравнивал уже, про скорость, размер и т.п.?

> Разве при -Os не идет оптимизация размера в ущерб скорости?

Линус писал, что нынешние процессоры (видимо имелись в виду Intel P4 с дцатью конвейрами) слабоваты в предсказании ветвлений, поэтому они будут быстрее исполнять меньший по V код, нежели чуть более оптимизированный.

По моим личным тестам (исходники C/C++ + процессор AMD Athlon 64) -O2 всё же предпочтительней -Os по скорости в среднем 0,5-2%. Может быть, что на Intel P4 будет всё наоборот.

> Немного оффтоп, но поясните, какой плюс от применения -Os?

> Допустим, будет оно меньше по размерам, что даст небольшую разницу

> при запуске системы, а в плане общесистемной производительности как

> это может сказаться?

> Разве при -Os не идет оптимизация размера в ущерб скорости?

Я провел довольно прилично испытаний на эту тему. Общий итог - скомпилированное ядро с опцией -Os работает медленнее, чем с -O2. Это подтверждают и тесты mysqlbench и ab (apache benchmark).

Давно пора. Незачем делать уступки некрофилам.

> Я спрашивал, если кто знает, сравнивал уже, про скорость, размер и т.п.?

Я не рискую. Когда выйдет хотя бы 4.1-rc1, тогда поробую. Состояние GCC 4.1 (http://gcc.gnu.org/ml/gcc/2006-01/msg00476.html) таково:

6 критических ошибок (типа неверный скомпилированный код или ICE'ы на нормальном коде)

63 регрессии в состоянии open (ну там компилятор тормоз, или код медленный)

Зато в 4.1 TreeSSA на полную катушку работает, от bison'a отказались = читай должен более быстрый код компилировать.

Надо сказать, что 4.0.2 до сих пор во многих случаях хуже, чем 3.4.5. По идее, 4.1 должен стать лучше, чем 3.4.5.

> Общий итог - скомпилированное ядро с опцией -Os работает медленнее, чем с -O2.

На сколько?

> Я провел довольно прилично испытаний на эту тему.

Чипсет, оперативка (производитель, объём, частота), процессор (тип, поддержка SSE2/x64, реальная частота)?

>Зато в 4.1 TreeSSA на полную катушку работает, от bison'a отказались = читай должен более быстрый код компилировать.

1) -O2/O3 - достаточно иле еще чего включать нужно?

2) Использование профилировщика дает заметный прирост производительности? 2 раза нужно собирать?

> На сколько?

Вот допустим полный пакет тестов mysql-benchmark ядро скомпилированное с опцией -O2 проходит за 1792 секунды, а с опцией -Os за 1865 секунд. В принципе показатель небольшой, но показатель.

По показанию ab - ядро собранное с опцией -O2 - 2635 запросов в секунду обрабатывает апач, с опцией -Os - 2598.

А чем бизон плох?

У меня 2.6.15 на -Os часто повисало. GCC 3.4.4 А вообще, если посмотреть ассемблер, то c -Os получается самый толковый код. А если нужна скорость, то -O3, но не факт, что не будет глючить

> Чипсет, оперативка (производитель, объём, частота), процессор (тип,

> поддержка SSE2/x64, реальная частота)?

1. gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) (RHEL4)

2. linux-2.6.15

3. Memory: 1035148k/1048256k available (1871k kernel code, 12356k reserved, 593k data, 156k init, 130752k highmem)

4. CPU: L2 cache: 1024K, CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 01, CPU: L2 cache: 1024K

5. Intel 865 Chipset

6. ata_piix, ata1: dev 0 ATA-6, max UDMA/133, 234441648 sectors: LBA48

ничего не разогнано, всё штатное.

Ура!!!

А чего шапка такая идиотская? Из неё следует, что 2.6.11, например уже не соберется с GCC < 3.3.0

ммм... на лоре разучились не только русскому языку, но и здравому смыслу и логике, судя по таким вот новостям.

Кстати все тесты СУБД показывают резкое возрастание производительности, если сменить дефолтовый io scheduler с anticipatory на deadline. CFQ в 2.6.15 использовать крайне не рекомендуется и Эндрю Мортоном и Коном Коливасом из-за slab corruptions. Скоро обещают пофиксить, но 2.6.16-rc1 ещё с глючным cfq.

Может для пущей оптимизации в Дженту при bootstrap'e собирать gcc 2.95, потом им 3.0, потом им 3.3? А им уже ядро...

> Может для пущей оптимизации в Дженту при bootstrap'e собирать gcc 2.95, потом им 3.0, потом им 3.3? А им уже ядро.

А ядром что собирать? :D

> А ядром что собирать? :D

2.95 ;)

> поясните, какой плюс от применения -Os?

уменьшается размер кода, а значит больше шансов что он будет влезать в кеш процессора, и процессору реже придется обращатся в далекую медленную RAM память.
Могут быть случаи когда этот фактор дает больше по скорости, чем -O2

торвальдса на свалку истории!!! надоел уже старый хрен! :)

--седайко стюмчик

Слышал такое распределение наиболее эффективных по общей скорости флагов: До 256 MB - "-Os" 256 Mb - 512 Mb - "-O2" 512 Mb и выше - "-O3"

Насколько это правда?

Зачем так? Можно openwatcom в поставку включить :)

Никогда "-O3" не пользовался и не буду. "-O3" обычно генерит код даже худший, чем -O2, т.к. врубается слишком много оптимизаций и не учитываются коллизии между ними. Плюз бинарники становятся очень жирными.

умелые inlines, assembly code, -ffast-math и -funroll-loops дают гораздо лучший эффект, чем применение "-O3".

про "-ffast-math" написано в доке: "it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. " и крайне не рекомендуется включать.

> больше шансов что он будет влезать в кеш процессора

Мысль хорошая, но изначально оптимизация по размеру задумывалась всё-таки для встраиваемых систем, где каждый байт на счету.

> торвальдса на свалку истории!!! надоел уже старый хрен! :)

Не говори, и Gnome ещё смеет критиковать! ;-)))

Кстати может кто пояснит на кой черт исполльзуется шедулер именно anticipatory по умолчанию? Вроде его специально для 2.6 делали очень долго какой-то умный чел и говорил что мол в 2.4 отстой а этот как попрет.

> Зачем так? Можно openwatcom в поставку включить :)

Чур меня!

> про "-ffast-math" написано в доке

Тем не менее, эта опция иногда выдаёт более точную математику, чем без нее. Quake2/3 собираются с этой опцией.

>Тем не менее, эта опция иногда выдаёт более точную математику, чем без нее.

то есть более точную? пример можно?

>Quake2/3 собираются с этой опцией.

там точность не особо нужна.

Насчёт gcc Торвальдс, если он такое и писал, не очень в курсе (мало того, сомневаюсь, что он употребил что-то подобное "плохо собирают код...").

> Мысль хорошая, но изначально оптимизация по размеру задумывалась всё-таки для встраиваемых систем, где каждый байт на счету.

для этого в ядре другое намечается:

Make vm86 support optional under CONFIG_EMBEDDED, to save about 5k of kernel size

configurable support for ELF core dumps, saves about 5K

Make x86 doublefault handling optional, saves about 13 KB

Make *[ug]id16 support optional, saves around 2 Kb

> на кой черт исполльзуется шедулер именно anticipatory по умолчанию?

А ты не в курсе, что это в конфиге ядра определяется?! :-)

А почему именно < GCC-3.3.0? На сколько мне извесно, в GCC-3.4.x поменялся ABI для C++, а чем GCC-3.3 отличается от GCC-3.2? Почему такая граница? Объясните мне незнающему.

>А почему именно < GCC-3.3.0? На сколько мне извесно, в GCC-3.4.x поменялся ABI ?>для C++, а чем GCC-3.3 отличается от GCC-3.2? Почему такая граница? Объясните >мне незнающему.

потому что каждая версия gcc имеет свои ошибки, в таком большом проекте как
ядро их хочется не хочется, а найдешь. приходится тащить за собой воз "work around" для каждой версии, т.к. на 3.3 все собирается и работает зачем нужно писать код думая о том как этот код перевед в ассемблер gcc <3.3.0

>умелые inlines, assembly code, -ffast-math и -funroll-loops дают гораздо лучший эффект, чем применение "-O3"

авторы mplayer с тобой несогласны

> авторы mplayer с тобой несогласны

Именно inlines и assembly code используются в mplayer на полную катушку.

> По моим личным тестам (исходники C/C++ + процессор AMD Athlon 64) -O2 всё же предпочтительней -Os по скорости в среднем 0,5-2%. Может быть, что на Intel P4 будет всё наоборот.

Вот-вот, у AMD кеш L1 64k против 16k у P4, да еще два потока в HT.

> Именно inlines и assembly code используются в mplayer на полную катушку.

Однако, согласно самым последним тестам, -O3 как минимум на атлоне быстрее всего.

http://article.gmane.org/gmane.comp.video.mplayer.devel/31228

http://article.gmane.org/gmane.comp.video.mplayer.devel/31235

2 no-dashi дык в курсе про конфиг ядра.Но вначале 2.6 начиналось именно с шедуллера anticipatory и только с какой-то версии можно менять в стиле echo "cfq" > /sys/тралялясчтототам . Мне интересно зачем был сделан такой шедулер и что его так долго пиннали, впрочем как и с vm рика-ван-рейла.

> только с какой-то версии можно менять в стиле echo "cfq" >

> /sys/тралялясчтототам .

Так io scheduler нельзя менять. Его можно менять параметром загрузки ядра elevator=as|deadline|cfq|noop