Применение специальных возможностей GCC в ядре Linux

> С другой стороны, когда просто так на 15% скорость критичного кода повысилась, то грех expect не вставить.

Не лучше ли написать функцию на ассемблере, чем портить компилятор?

С практической точки зрения для отрасли практичнее знать С, С++ и ассемблер. А в нынешней ситуации надо знать рюшечки отдельных компиляторов, таким образом ухудшается портабельность кода и освоения кода сторонними программистами.

> С практической точки зрения для отрасли практичнее знать С, С++ и ассемблер. А в нынешней ситуации надо знать рюшечки отдельных компиляторов, таким образом ухудшается портабельность кода и освоения кода сторонними программистами.

С практической точки зрения портабельность обычных программ не нужна. Библиотек типа boost - да, нужна. C++ сейчас знать уже непрактично, лучше заменить на Java/C# или вообще Питон, раз ассемблер и Си уже знаешь.

> Поиск тегов при разборе плохо структурированного потока. Продукт проприетарный, код не дам :)

Вот не верится мне, и все тут. Если участок кода сколько-нибудь горячий, все джампы мониторит процессорный аппаратный предсказатель переходов. Чтобы подобрать паттерн, на котором предсказатель постоянно ошибался бы - нужно постараться.. Продукт целиком мне нафик не сдался - нет ни времени, ни желания его ковырять. А вот примерчик строк на 100 я бы с удовольствием посмотрел.

Напишите. PGO же вам доступно, вот и напишите код, который плохо ветвится :)

> Догадки? Хорошие программисты *знают*. При недостатке опыта, конечно, помогает, но гуру ещё до написания кода уже знают, где будут затыки.

Это утопия, имхо. В реальности программы очень часто работают не совсем так, как думали их создатели :) И если обычные баги рано или поздно обнаруживаются и правятся, то заблуждения программиста насчет expect могут жить вечно.

> PGO в виде performance counter'ов помогают только при отладке нового железа. Оно и появилось-то непосредственно для отлова ошибок в процессорах.

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

> На асме x86 переписать обычный, невекторный код лучше, чем это делает gcc (4.4 особенно) - весьма нетривиальная задача.

Тут Silvy недавно оценивала качество кода из-под gcc4.4. На gzip он оказался хуже, чем все предшественники.

http://www.linux.org.ru/view-message.jsp?msgid=3591941&page=1#3592695

Примерно год назад я изучал выхлоп gcc на небольшом горячем цикле. Руками все переменные внутри цикла как раз раскладывались по x86 регистрам, но gcc не осилил, и с на каждой итерации делал по два spill и два fill. И цикл у него получился в полтора раза толще, чем можно было бы. Ни раскрутки, ни наложения смежных итераций он по -O2 не делал.

Короче говоря, gcc приписывают слишком высокое качество ассемблерного кода :)

> Если вместо недели расчёт обсчитается за 5 дней, то тут уже и премией попахивает =)

Вместо пять дней вместо семи - это ускорение на 30% :) Я и в 15% не верю.

>> Ты освоил арифметику с указателями, и решил на радостях этим понтоваться?

> Должен тебя огорчить: ты не угадал.

Тогда извините, К.О., не узнал вас в гриме.

s/и с на каждой/и на каждой/ s/Вместо пять/Пять/

ИМХО, полезно.

thnx

Скажи об этом мсям

>> Беда в том, что если я вот так же приведу список того что реализовано это сочтут флудом, намек понятен?

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

Ладно, объясню как прапорщику, какая боль заставляет тебя рыдать именно об этих 9 нереализованных возможностях? Почему именно они отнесены к "значительной части"? Сдается мне причина одна - они не реализованы.

> typeof(x++) работает как надо - x не инкрементирует. В статье, конечно же, такого не написано.

Кстати и sizeof(x++) тоже не инкрементирует. Дело в том, что обе эти операции (sizeof и typeof) выполняются на этапе компиляции.

Вообще, IMHO, typeof и массивы нулевой длины превращают язык C в какой-то другой.

> какая боль заставляет тебя рыдать именно об этих 9 нереализованных возможностях?

Мне и с c89 нормально живется. Массивы переменной длины - одна из мажорных частей c99 - в gcc не работает полноценно. Если верить твоей ссылке, нет wchar.h (и это сильно снижает юзабельность wide char). Убого.

> Почему именно они отнесены к "значительной части"?

А по-твоему, эти вещи значительными не являются? Обоснуй-ка, почему?

>А по-твоему, эти вещи значительными не являются? Обоснуй-ка, почему?

Потому что за всю свою практику я никогда не встречал необходимости их использовать. Да, конечно, я ковырялся в основном с системным кодом, возможно есть приложения где подобные навороты важны, но ни в солярке ни в линуксах ни в эмбедах это все абсолютно не нужно. Что мы и наблюдаем глядя на gcc, если бы мсье Торвальдс сказал что ему дозарезу нужны массивы переменной длинны думаю их бы прикрутили, ИМХО.

> Потому что за всю свою практику я никогда не встречал необходимости их использовать. Да, конечно, я ковырялся в основном с системным кодом [поскипано] ни в солярке ни в линуксах ни в эмбедах это все абсолютно не нужно

Т.е. твоя практика говорит о том, что c99 придумали идиоты, и понапихали туда кучу не нужных тебе - драйверолобателю - вещей? :)))

> Что мы и наблюдаем глядя на gcc, если бы мсье Торвальдс сказал что ему дозарезу нужны массивы переменной длинны

Ничего, что ядро написано на c89 с экстеншенами, которые так и не были стандартизованы? Мсье Торвальдсу до c99 вообще дела нет.

> возможно есть приложения где подобные навороты важны

Ы-ыыы, какой кругозор впечатляющий :)))) Ну кому, как не тебе, судить о нужности и существенности? Прапорщикам своим привет передавай.

>т.е. твоя практика говорит о том, что c99 придумали идиоты, и понапихали туда кучу не нужных тебе - драйверолобателю - вещей?

Увы, дело не только в драйверах, но это не тема для обсуждения. И почему сразу идиоты? Более уместное слово - теоретики. Или для тебя это одно и тоже?

>> возможно есть приложения где подобные навороты важны

>Ы-ыыы, какой кругозор впечатляющий :)))) Ну кому, как не тебе, судить о нужности и существенности? Прапорщикам своим привет передавай.

Привет :) Не подскажешь пример таких приложений?

> Тоже самое нельзя сделать вставкой ассемблера?

foreach(el,list) { 100 строк кода } ? Конечно можно. Только зачем? Чтобы typeof() не учить?

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

branch prediction helps, кто спорит.

а вот вы скомпилируйте, к примеру, вот такой код:

        void f(int x)
        {
                aaa();
                bbb();
                if (unlikely(x)) {
                        xxx();
                        yyy();
                        zzz();
                }
                ccc();
                ddd();
        }

потом можете сделать s/unlikely/likely/, увидите
разницу. на этапе выполнения реорганизацию кода
уже не сделать.

крохи, конечно, но ведь бесплатно.

> а вот вы скомпилируйте, к примеру, вот такой код

Очередной сферический конь. Вы откомпилируйте свой код, убедитесь что есть разница, и только потом сюда флудите :)

> Не подскажешь пример таких приложений?

Что до массивов, то это любая процедура, которой нужен временный массив переменной длины. Стекообразное выделение/освобождение памяти организуется значительно эффективнее традиционной кучи. А автоматическое разрушение таких массивов освобождает от error-prone связки malloc-free (частный случай raii).

А wide char удобны при передаче строк по сети, когда на разных хостах у тебя разные локали. Потому что на практике для wchar все используют уникод (можешь поискать в стандарте c99 что значит дефайн __STDC_ISO_10646__).

> убедитесь что есть разница,

хмм... пришлось таки сделать. посмотрел на ассемблер,
разница таки есть.

> только потом сюда флудите :)

ладно, больше ну буду.

> посмотрел на ассемблер, разница таки есть.

Лол. Разница в производительности.

>Стекообразное выделение/освобождение памяти организуется значительно эффективнее традиционной кучи.

Но профит будет иметь только один массив переменной длинны, голова у кучи всего одна. В основном, когда нужна производительность, для этих целей используют связные списки (ну и не только, от задачи зависит) и не полагаются на "мудрость" компилятора. Каким боком тут raii я вообще не понимаю, причем тут инициализация? Детская болезнь утечек памяти не мой случай, с опытом ты либо приучаешься избегать утечек либо переползаешь на java-like языки. Естественно в системном программировании таких проблем у людей нет, иначе они занимаются не своим делом.

>А wide char удобны при передаче строк по сети

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

Я не спорю с тем что недоработки имеют место быть, просто не вижу причин реагировать на них так остро.

> Но профит будет иметь только один массив переменной длинны, голова у кучи всего одна. В основном, когда нужна производительность, для этих целей используют связные списки (ну и не только, от задачи зависит) и не полагаются на "мудрость" компилятора. Каким боком тут raii я вообще не понимаю, причем тут инициализация? Детская болезнь утечек памяти не мой случай, с опытом ты либо приучаешься избегать утечек либо переползаешь на java-like языки.

Мне лень. Лень дальше разжевывать про массивы: ты можешь открыть стандарт, прочитать что это такое, и понять, где они удобны. Лень разжевывать про оверхед от связных списков по сравнению со стековыми переменными. Лень разжевывать про raii - ты вполне можешь воспользоваться гуглом. Лень обсуждать тривиальные проблемы malloc/free. Прости.

Резюме остается прежним: расширения - зло (и нужно их избегать), стандарты - добро (и нужно знать их и соблюдать в своем коде). А gcc со временем подтянут, я думаю.

>Мне лень.

Слив засчитан.

> Резюме остается прежним: расширения - зло (и нужно их избегать), стандарты - добро (и нужно знать их и соблюдать в своем коде). А gcc со временем подтянут, я думаю.

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

> Слив засчитан.

Смешной ты :)

Под "граблями" я имею в виду отличие реализации массивов переменной длины от стандарта С99. Ты в курсе этих отличий?

> Твоя пространная и высокоморальная тирада имела мало смысла

Моя тирада относилась к непониманию некоторыми собеседниками очевидных вещей. Впрочем, я рад, что тебе понравилось :D

> gcc х.з. сколько времени держит массивы переменной длины

There are some known bugs (19771, 39564, 39581, 39582) relating to corner cases of variable length arrays (VLAs).

> Мотивировать свое мнение ты можешь только указанием конкретных граблей от жцц

На предыдущей страничке есть ссылка на сайт gcc, где английским по белому написано "variable-length arrays: Broken". Именно этим я свое мнение и мотивирую.

> обоснованием высокой вероятности на них напороться

А если вероятность невысокая, то что?

> причем си-девелоперам, которые по минному полю ходить привыгли

"Мы живем с глюк4аловом и гордимся этим!" Классная позиция :)

s/к4а/ка/

Ну это понятно, что автор предположил. Вам чем это знание поможет то?

Зачем ядро компилируют gcc? Зачем к gcc прикручивать объектноориентированные рюшечки? Почему ядро не компилируют g++?

>Лолшто? Давно c99 стал gcc-шным расширением? Ничего, что gcc до сих пор (10 лет спустя!!!) не поддерживает значительную часть стандарта c99?
Статья не раскрыла даже C99 не говоря о расширениях... Так наверное понятнее будет.

Да неужели этот список и есть пресловутая значительная часть? http://gcc.gnu.org/c99status.html

BTW может быть вы назовоте хоть один компилятор у которого аналогичный список хотябы на порядок не больше?

>Лолшто? Вы забыли о тех gnu extensions, которые сначала были объявлениы deprecated, а потом и вовсе выкинуты из компилятора. И если программа была гвоздями прибита к таким экстеншенам, то переход на новую версию gcc оборачивается реальной болью в заднице.

Может приведете реальный пример?

Часть расширений была приведена под новый синтаксис C99 это вполне нормально.

Часть deprecated вообще давно не работало правильно и никем не использовалась, поэтому и deprecated.

Вероятно имелись в виду всякие извращения с LVALUE, так туда им и дорога. Код с этим маинтейнить было тяжело и кто использовал сам виноват.

>Сами ничего толком не умеете, и от того вам нравится разговаривать с другими в снисходительном тоне?

У меня опыт работы с GCC >12 лет, из них >10лет работа с большими проектами (например Xray Debugger от Mentor Graphics, эмуляторы MIPS, PPC, x86, 68k, arm и других архитектур, ядра различных OS), часть кода в некоторых из них написан еще в 80x, проекты работают на 4-5 платформах с разным endianom, имеются части где размер char отличен от одного октета и int в 3 октета на целевой платформе.
Обычно мой код LP64, LLP64, ILP64 clean.

Видимо это не дает право давать советы учить матчавсть :(

> А если вероятность невысокая, то что?

то нефиг засорять своим нытьем форум, вот что. Сказали же четко -- corner cases.

> Зачем к gcc прикручивать объектноориентированные рюшечки?

какая из рюшечек по-твоему из ООП?

> "Мы живем с глюк4аловом и гордимся этим!" Классная позиция :)

Неправильно. Мы знаем, что можно, а что нельзя. А твое нытье про стандарт С99 показывает, что сам ты практически им не пользуешься. Иначе бы ты ныл совсем о других вещах.

> There are some known bugs (19771, 39564, 39581, 39582) relating to corner cases of variable length arrays (VLAs).

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

Писал бы серьезно на С -- были бы мысли, чего тебе на С действительно не хватает, а не "мама, хочу именно с клубничным". И это я бы послушал.

> Статья не раскрыла даже C99 не говоря о расширениях... Так наверное понятнее будет.

Так будет хотя бы корректно. И - на мой взгляд - вполне логично, что в статье, посвященной экстеншенам, не рассказывают про стандартный c99. Не нужно мешать божий дар с яичницой.

> Да неужели этот список и есть пресловутая значительная часть?

Да.

> Вероятно имелись в виду всякие извращения с LVALUE, так туда им и дорога. Код с этим маинтейнить было тяжело и кто использовал сам виноват.

Вот и я думаю - кто использует гнутые расширения - сам себе злой буратина. А те, кто пользуются его кодом, несут определенные риски.

> У меня опыт работы с GCC >12 лет, из них >10лет работа с большими проектами (например Xray Debugger от Mentor Graphics, эмуляторы MIPS, PPC, x86, 68k, arm и других архитектур, ядра различных OS), часть кода в некоторых из них написан еще в 80x, проекты работают на 4-5 платформах с разным endianom, имеются части где размер char отличен от одного октета и int в 3 октета на целевой платформе. Обычно мой код LP64, LLP64, ILP64 clean.

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

> Видимо это не дает право давать советы учить матчавсть :(

Не дает права бредить в поучительных тонах.

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

Видишь ли, когда я пишу на Си, меня все устраивает. Когда нужно больше - пишу на c++/stl/boost. Когда нужно что-то еще, пишу на perl. И тд.

> Неправильно. Мы знаем, что можно, а что нельзя. А твое нытье про стандарт С99 показывает, что сам ты практически им не пользуешься.

Как раз VLA я время ото времени использую. Потому меня и нервирует слово broken с той страницы.

> Сказали же четко -- corner cases.

Какой ты чоткий. А то, что чотко сказали broken - этого вы в упор не замечаешь?

> Какой ты чоткий. А то, что чотко сказали broken - этого вы в упор не замечаешь?

broken в основном означает "работающий, но не так, как в С99" -- т.е. не клубничная жвачка, а ананосовая

> Может приведете реальный пример?

В реальности я имел многомегабайтный плюсовый проект. Одним из ключевых кусков которого была сотня килобайт сложного шаблонного кода, и код этот полагался на нестандартное поведение при наследовании. Поведение, которое демонстрировали gcc и msvc тех времен. Аффтары кода, видимо, считали, что знают "что можно, а что нельзя". Прямо как www_linux_org_ru. А потом новые версии gcc привели в соответствие со стандартом, и код тупо перестал собираться. Простыми правками это не лечилось, код нуждался в переписывании. Ни времени, ни ресурсов на которое не было. В итоге мы больше года сидели на старом gcc (пока все же не улучили момент для переделки). И все это время мы не могли использовать появившиеся в новых версиях средства отладки -- а были бы очень к стати. Такова цена использования нестандартных фич.

> и код этот полагался на нестандартное поведение при наследовании.

Поподробнее, плиз. Желательно номера багов.

> и код этот полагался на нестандартное поведение при наследовании.

Прочитал бы хоть описание этих 4-х багов, что ли. *Ни один* из них не может быть использован для того, чтобы на него полагаться.

> Поподробнее, плиз. Желательно номера багов.

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

http://gcc.gnu.org/gcc-3.4/changes.html "In a template definition, unqualified names will no longer find members of a dependent base". В нашем случае жестко требовалась backward compatability, поэтому слово using не годилось.

По этому поводу и баги на gcc кто-то вешал, но, естественно, чинить их никто не собирается. Тк новое поведение - стандартное, а старое - нет.

> broken в основном означает "работающий, но не так, как в С99" -- т.е. не клубничная жвачка, а ананосовая

Вот и наследование работало, но не как в iso/iec 14882. До поры - до времени. А потом как хочешь, так и выкручивайся: твои проблемы авторов gcc не волнуют.

> Вот и наследование работало, но не как в iso/iec 14882. До поры - до времени. А потом как хочешь, так и выкручивайся: твои проблемы авторов gcc не волнуют.

> In a template definition, unqualified names will no longer find members of a dependent base

> Ни времени, ни ресурсов на которое не было. В итоге мы больше года сидели на старом gcc (пока все же не улучили момент для переделки).

Припоминаю этот скачок.

Только работа тут минимальна, обычно хватает расставить this-> (либо добавить <T>, но как такое до этого могло компилироваться -- мне не ясно). И все. Никакой переделкой и не пахнет.

Откуда появилась переделка?

> какая из рюшечек по-твоему из ООП?

Опс, сори. Виноват, не помню. Но в коде ядрая явно имеет место ООП подход на Си. Почему разработчики ядра не используют с++?

> Только работа тут минимальна, обычно хватает расставить this-> (либо добавить <T>, но как такое до этого могло компилироваться -- мне не ясно). И все. Никакой переделкой и не пахнет.

Ну давай, расставь this.

template<class T>
struct A
{
  typedef int value_t;
};

template<class T>
struct B : public A<T>
{
  typedef value_t result_t;
};

template<class T>
struct C : public A<T>
{
  typedef unsigned value_t;
  typedef char result_t;
};