The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Дискуссия об использовании языка C++ для разработки ядра Linux, opennews (??), 14-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


8. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от maximnik0 (?), 14-Янв-24, 21:51 
>Нельзя туда цпп. Ладно модули, только не ядро. Запаримся пересобирать же! Си собирается намного шустрее.

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

63. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 14-Янв-24, 23:43 
> Так разговоры давно идут об введений подмножеств - урезанной современной версии языка.
> С выкидыванием всякого хлама,там такого всего накопилось ......

Так то g++ заметно тормознее gcc... потому что C++ куда как более фичастый язык. И время жевания сорцов на плсоте - ну вот реально заметно дольше. Хоть там как.

Ответить | Правка | Наверх | Cообщить модератору

458. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +2 +/–
Сообщение от Аноним (452), 16-Янв-24, 00:13 
И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный. Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.
Ответить | Правка | Наверх | Cообщить модератору

475. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (-), 16-Янв-24, 02:52 
> И чё? Когда сам GCC c версии 4.8 тоже начал постепенный переход
> на C++, тоже ныли, мееедленно. Вот спустя десяток лет, полёт нормальный.
> Пользуемся и не замечаем. Уж некоторые и забыли/не знали, что он на C++.

А вы часто вот именно gcc сами компилите, чтобы разницу в времени компила gcc ощутить? Так то его заметно тормознее себе перекомпиливать стало. Я это еще и практикую, так что знаю о чем говорю.

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

Ответить | Правка | Наверх | Cообщить модератору

583. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от _kp (ok), 16-Янв-24, 21:47 
> Так то g++ заметно тормознее gcc...

  Это в прошлом было такое.
А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc, в среднем, но не всегда.
  Но нет дыма без огня. В разных сборках компиляторов скорость может отличаться в разы, например, бывает "хорошая" сборка g++ может быть заметно быстрее gcc или другой сборки g++. Такой бардак с компиляторами есть для esp32 и stm32, и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары компиляторов можно сделать неверные выводы.

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

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

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

603. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 17-Янв-24, 04:30 
> А сейчас что скорость компиляции примерно одинакова, с очень небольшим преимуществом gcc,
> в среднем, но не всегда.

Угу, конечно. Запускаем допустим libaom компилиться. И чего-то сишная часть тикает быстро, а вот плюсатые - всего лишь тесты - куда скромнее по скорости сборки, при том что в общем то тесты довольно примитивные. Cmake индикатор прогресса кажет, в процентах, там хорошо видно кто тормоз.

>   Но нет дыма без огня. В разных сборках компиляторов скорость
> может отличаться в разы, например, бывает "хорошая" сборка g++ может быть
> заметно быстрее gcc или другой сборки g++.

У меня стандартный дебиановский gcc/g++ 12.x - такой как его дебиан отгружает. Васянские сборки я устанавливать не собираюсь хоть там как.

> Такой бардак с компиляторами есть для esp32 и stm32,

Я для STM32 собираю обычным дистровским же gcc-arm-none-eabi (впрочем и gcc-arm-gnueabihf катит). Но я для фирмварей только си юзаю. А зачем мне васянские сборки, опять же?

> и вляпавшись в крайние отклонения в скорости компиляции "удачной" пары
> компиляторов можно сделать неверные выводы.

Вон то - совершенно типовой тренд для билдовки софта. Суммарно я так или иначе пробовал билдовать около 250 разных программ так что имел возможность заметить тренды. Они мало меняются по версиям системного gcc, g++ всегда заметно медленнее gcc как компилер.

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

Возможно. Однако плюсатый софт в целом компилится весьма ощутимо медленнее. Ессно его нельзя собрать gcc для сравнения. Но например GTKшную морду трансмишна на си VS плюсатую на Qt - вполне, и в силу сравнимой функциональности можно прикинуть как мне время билдовки. И оно ессно не в пользу g++ от слова вообще.

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

Я выразил "интегральный" опыт - в целом плюсатый софт заметно тормознее в компиле. Вот хоть как. И тот же gcc после того как разрешили юзеж плюсов пересобираться стал ощутимо дольше, что в общем то и не фича вовсе.

Ответить | Правка | Наверх | Cообщить модератору

615. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от _kp (ok), 17-Янв-24, 12:26 
>>А зачем мне васянские сборки, опять же?

Если например пересборка компилятора esp32s3 и системы сборки сократила время сборки проекта  с 40 до 8 секунд, то таких Васянов на руках носить надо.
Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны" дали подсказку куда копать, то и их труды не пропали.

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

Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором.
Но это справедливо для одной версии и сборки компиляторов clang и gcc. А разные версии и сбоки могут отличаться как угодно

Ещё на слабых для разработки компах, и тем более каких есть ноутбуках, свежие компиляторы в принципе медленнее старых версий их же самих. И разрыв между компиляцией си и с++ будет вполне заметен. А на среднемощном десктопе таки пофиг.

Ответить | Правка | Наверх | Cообщить модератору

673. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 21-Янв-24, 16:53 
> Впрочем, раз Вы вполне опытный, можете собрать и сами. А если "Васяны"
> дали подсказку куда копать, то и их труды не пропали.

Я ESP не использую, и врядли буду когда либо. Так что это знание может и будет полезно... но кому-то другому.

> Малый разрыв в скорости, это когда си-исходник собирается с++ компилятором.

Вы издеваетесь? Меня жонглирование цифрами не интересует, интересно время фактической сборки проектов. Зачем мне обманывать самого себя? И в этом смысле плюсовые проекты заметно тормознее билдить.

> Ещё на слабых для разработки компах, и тем более каких есть ноутбуках,
> свежие компиляторы в принципе медленнее старых версий их же самих. И
> разрыв между компиляцией си и с++ будет вполне заметен. А на
> среднемощном десктопе таки пофиг.

У меня довольно мощный десктоп - и - боюсь я очень даже вижу разницу в времени билда старого gcc и нового где плюсоту можно стало, например. А по сравнению с кернелом gcc так то довольно небольшой проект. Заякорить билд кернела в пару раз было бы очень такой себе идеей. На разлапистой конфиге там и так время билда очень даже.

Ответить | Правка | Наверх | Cообщить модератору

674. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от _kp (ok), 21-Янв-24, 19:21 
Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а не переписывать, чем занята другая группа.

Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.
Но случаи бывают разные. Банально что то поправить, и собрать не дома. Есть ещё командировки. И студенты в конце концов.

>>плюсовые проекты заметно тормознее билдить.

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

Ответить | Правка | Наверх | Cообщить модератору

675. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 21-Янв-24, 20:34 
> Как нас унесло. Изначальный смысл был скормить си исходники компилятору с++, а
> не переписывать, чем занята другая группа.

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

Да, C++ позволяет более выразительные конструкции. Если б еще наслоения легаси выкинуть, и оформить более безопасный subset дефолтов "для чайников" - был бы наверное неплохой яп так то. Но в случае с проектом размером с кернел есть много разных аспектов. Время компила напрямую влияет на допустим степень протестированности кода, да и скорость разработки якорит.

Не, коду который "haven't seen compiler" я не доверяю. Never had, and never will.

> Мощные десктопы на работе, и дома у любителей. У меня тоже есть и мощные.

Времена билда кернела могут напрячь и на таких. Помножить эти времена на эн - очень так себе идея. К тому же это все создает entry level barrier там где его быть не должно, отсеивая всяких студентов и ко. Зачем нам это проект без студентов и энтузиастов, где только мегакорпы?

> Но случаи бывают разные. Банально что то поправить, и собрать не дома.
> Есть ещё командировки. И студенты в конце концов.

Ну дык. Чем злее требования к конфиге - тем меньше народа это все будет делать. Это идет вразрез с идеями опенсорса - и куда это заведет? К тому что пилить будут полтора корпората с билдфермами? Так что совсем игнорить этот топик имхо не стоит.

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

Это в основном майкрософтовские кодеры таким страдают, как и юзежом си++ в режиме "чуть улучшеный си". Вызвано убогостью MSVS как си компилера, но в случае сабжа не аргумент ибо - unsupported config.

> И тут, взависимости от стиля исходника, бинарник может получиться и лучше,

С фига ли вдруг?

> и контроль типов получше,

Да вообще-то в сях он весьма даже. А если кто думал что знает о типах все, пусть попробует -Wconversion поюзать. И таки - компилер то может. А вот сможете ли вы с этим жить, если вам на pre-existing проекты вот такие жесткие проверки влепить...

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

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

> а то именно на мощных компах проекты "начинающих" и "консерваторов" не
> используют все ресурсы компа, и даже на мощной машине собираются неспешно.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру