LINUX.ORG.RU

Производительность C++

 ,


7

13

Как насчёт производительности у C++ по сравнению с C? Мои предположения на текущий момент:

1) Код, не использующий возможности C++ (то есть по сути plain C), скомпилированный C++ компилятором будет иметь абсолютно ту же производительность, что и код на С.

2) Исключения и dynamic_cast медленные. Если нам важна производительность, лучше их не использовать.

3) Класс без виртуальных методов, должен быть по производительности эквивалентен сишной структуре и функциям, обрабатывающим её. Не считая копирования. Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).

4) Класс с виртуальными методами полностью аналогичен пункту 3, но при вызове виртуальных методов добавляется небольшой оверхед. Сишный эквивалент obj->vtable->func(obj, ...). Если сравнивать с plain C кодом, реализующим ООП в той же манере (каждая структура-объект имеет поле, указывающее на структуру, содержащую адреса функций работы с ней), то оверхеда по сравнению с plain C не должно быть.

5) При использовании атрибута класса final (если компилятор поддерживает соответствующий стандарт) даже при наличии виртуальных методов в нём, их вызов будет превращаться в прямые вызовы функций вместо обращения к vtable, если переменная имеет соответствующий тип, а не указатель/ссылка на его предка (который не final).

6) Шаблоны могут привести к разбуханию кода. Впрочем, #define-ы и inline-функции в C++ могут устроить то же самое. Вопрос: будет ли использование шаблона с одинаковыми параметрами создавать 2 копии реализации или же всё-таки компилятор догадается сделать её лишь один раз. А если шаблон используется с одинаковыми параметрами в нескольких объектных файлах? Будет ли реализация расшариваться между ними или у каждого своя?

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

Я не претендую на правоту, какие-то утверждения могут быть ложными. Хотел бы узнать, как обстоят дела на самом деле. А также какие подводные камни я ещё не знаю. Разумеется, речь идёт о последних версиях gcc/clang с включённой оптимизацией не ниже -O2.

★★★★★

Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от EXL

ты готов приводить даже подобные примеры.

А ты писал на гобжект сам-то? И что, что макросы? Речь про семантику, а не про синтаксис. В gobject есть рефлексия, пересылка сообщений, делегации искоропки, это куда как более полноценная объектная система. Понятно, что сахарок в сишке кроме как макросами ты не наваяешь, тут уж древность и убогость сишки берет свое. Хочешь сахарок — бери валу. Речь, повторюсь, была о другом.

anonymous
()
Ответ на: комментарий от AnonCxx

Т.е. вначале выкачен высер cloc, а далее показаны все С++ файлы, что он нашел.

Ты искренне тупой или притворяешься от безнадеги? Весь gcc - это код на Си++. То, что он был когда-то кодом на Си, не меняет ровно ничего. Сейчас там шаблоны и ООП.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

И это доказывает только инерцию отрасли.

Пусть так, но изначальный тезис-то был «все убежали с сишки на кресты».

anonymous
()
Ответ на: комментарий от anonymous

Совсем нет.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Что же касается бэкенда, то на кой его писать на крестах, если можно писать на жабе?

Обстоятельства могут быть разными :-) Например, кто-то вложил в разработку на C++ много времени и/или денег, поэтому переходить на Java опасается :-) В этом случае, если есть команда опытных C++-программистов (которых на стороне сегодня днём с огнём не найдёшь), которые годами эту самую разработку вели, то у них просто может не быть времени переписывать вся на Java или ещё что-то :-) В этом смысле, они поневоле привязаны к цепепе :-) И это не есть совсем уж плохо, если готовый продукт на цепепе несёт людям, которым совсем вот нет дела до программирования, реальную пользу :-) Важен реальный и полезный готовый продукт, который захотят купить/пользоваться, и который можно продать :-)

anonymous
()
Ответ на: комментарий от anonymous
namespace {

/* If NODE is not versionable, warn about not emiting HSAIL and return false.
   Otherwise return true.  */

static bool
check_warn_node_versionable (cgraph_node *node)
{
  if (!node->local.versionable)
    {
      warning_at (EXPR_LOCATION (node->decl), OPT_Whsa,
		  "could not emit HSAIL for function %s: function cannot be "
		  "cloned", node->name ());
      return false;
    }
  return true;
}

Если бы всё было так просто.

AnonCxx
()
Ответ на: комментарий от anonymous

изначальный тезис-то был «все убежали с сишки на кресты».

Нет. Тезис был «все, кто смог, убежали». И это так.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

вроде джавы, раста,
раста

Я тут давича на нем либу одну переписывал, которая задания узлам распределенной сети раскидывает. И уткнулся в переписку раундробина, суть который в циклическом двусвязном списке с переходом к менее нагруженному узлу за N(1)...Короче победил только блоками unsave и то код сливает крестовой реализации процентов 10. Если делать его на LinkedList то проседает еще.

И это дня 2 йобани и борьбы с компилятором. При этом задача реализации этого решается на крестах минут за 20.

Хотя сам по себе язык прикольный. За карго вообще памятник разрабам при жизни поставить надо.

anonymous
()
Ответ на: комментарий от anonymous

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

Хм? В расте по твоему с ООП, моделью памяти и библиотеками лучше? Про последнее даже смешно.

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

Ты искренне тупой или притворяешься от безнадеги?

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

Весь gcc - это код на Си++.

Весь гцц - код на си, только собирают его С++ конпелятором.

То, что он был когда-то кодом на Си,

Он и сейчас на нём.

Сейчас там шаблоны и ООП

Шаблоны там чисто форфан и то в 0.хрен десятых процента кода. Причём тут ООП - мне неведомо.

AnonCxx
()
Ответ на: комментарий от anonymous

И кто смог в итоге?

Ну, я смог отчасти. Или выше - GCC смог. LLVM даже не рассматривал Си.

Лучше скажи, какие проекты, у которых был выбор между Си++ и Си, выбрали Си.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Openbsd, linux, freertos какой возраст имеют?

Сколько вам лет, эрудированный вы наш? 15 или 17? В Wikipedia заглянули бы: https://en.wikipedia.org/wiki/History_of_Linux#The_creation_of_Linux Анонс разработки Линус сделал в августе 1991-го года. В этом году аккурат 25 лет исполняется.

OpenBSD форкнулась от NetBSD в 1995-ом (упс, 21 год), а NetBSD произошел от 4.3BSD (релиз в 1986-м), а сам 4.3BSD берет свои корни вообще в очень древних версиях Unix-а.

Кто переходит на кресты?

Еще раз, для малолетних дебилов: «Ну и опыт Linux-а не мешает людям делать ОСы на C++.» Т.е. не валить на кресты, а делать на крестах: Windows, например, или OSv. Из прошлого — BeOS, Symbian, PalmOS.

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

Это для C++ нет инфраструктуры и библиотек? И это C++у нужно к Rust-у примазываться?

Вы, блин, в какой вселенной живете?

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

С моделью памяти и библиотеками — явно. ООП там не особо нужно. В крестах каждая вторая либа пилит свою модель памяти: у qt своя, у glib своя, половина либ делает какой алокатор или кучу выделяет, мрак, короче. Было бы везде raii, было бы еще не так страшно, но это невозможно по понятным причинам, ибо большая часть либ написана на чистой сишке, с которой никто убегать что-то не торопится, а остальное — кто во что горазд.

anonymous
()
Ответ на: комментарий от eao197

BeOS, Symbian, PalmOS.

HAIKU же. До сих пор пилят.

anonymous
()
Ответ на: комментарий от tailgunner

Весь gcc - это код на Си++. То, что он был когда-то кодом на Си, не меняет ровно ничего. Сейчас там шаблоны и ООП.

ООП - это способ проектирования и к конкретному языку отношения не имеет :-) То, что сейчас в GCC очень умеренно применяются шаблоны с деструкторами не говорит о том, что GCC спроектирован по канонам ООП :-)

anonymous
()
Ответ на: комментарий от anonymous

Речь шла про эмбеддед и ядра ос.

А также «и проч».

Но, если ограничиваться ОС и эмбеддед - приведи примеры ОС, которые начали писаться менее 20 лет назад. Я знаю несколько экспериментальных, которые отнюдь не на Си, и одну практическую - OS X, в которой, внезапно, используеться Си++ (поверх Сишного Mach, да - потому что Mach уже 30 лет). Ну а насчет эмбеддед - по глухим слухам, большой военный эмбеддед пишется таки на Си++.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Сейчас там шаблоны и ООП.

ООП - это способ проектирования и к конкретному языку отношения не имеет :-)

Иди вместе с царем перекомпилируй gcc на какой-нибудь «не конкретный язык», теоретик.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Лолшто? Каким образом доступ к ресурсу из разных потоков ловится статическим анализатором?

При чем тут unique_ptr? Статический анализатор ловит ситуации, когда из unique_ptr взяли указатель и стали его использовать после разрушения unique_ptr.

Ненене, ты сказал, что кресты принципиально лучше сишки, кардинально дешевле. Теперь ты заливаешь про статические анализаторы и то, что в сишке тоже жопа.

Совсем больной. Да, кресты принципиально лучше сишки, кардинально дешевле. И в сишке жопа. Что с анализаторами, что без.

Rust лучше сишки, но слишком молод. Поэтому, в качестве реальной альтернативы сишке кресты выглядят намного лучше, чем Rust. На данный момент по крайней мере. И это только для вещей, в которых C имеет смысл использовать.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Иди вместе с царем перекомпилируй gcc на какой-нибудь «не конкретный язык», теоретик.

А мне то это зачем? :-) Мне вообще по сараю на чём написан GCC и каким он компилятором компилируется :-) Просто смешно, когда ООП привязывают к компилятору цепепе :-)

anonymous
()
Ответ на: комментарий от AnonCxx

Весь гцц - код на си, только собирают его С++ конпелятором.

Царь, не тупи. Тут уже ткнули пальцем в файл с расширением .c, в котором и наследование, и шаблоны. Посему доверять выхлопу cloc уже просто нельзя.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Иди вместе с царем перекомпилируй gcc на какой-нибудь «не конкретный язык», теоретик.

А мне то это зачем? :-)

Без этого твои слова - пустой треп. Впрочем, если тебя это устраивает, то делать ничего не нужно.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

библиотеками

Сейчас о карго рассказывать будешь или о чём? Для плюсов библиотек намного больше. То, что их «подключать» менее удобно - другой вопрос.

ООП там не особо нужно.

Факт, в том, что ООП в расте ещё менее развитое. Нужность другой вопрос. И да, есть всякие предложения как «красиво» наследование данных сделать, то есть необходимость местами есть.

Про модель памяти цитата из официальной документации:

Rust does not currently have a rigorously and formally defined memory model, so...

Если что, раст мне весьма симпатичен и интересен, но в фанатизм впадать-то зачем?

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

В Wikipedia заглянули бы

Про freertos благоразумно умолчал, да?

малолетних дебилов

Крестофанатик порвался и скатился в оскорбления, как банально.

Windows

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

OSv, Symbian

А куникс на асме написан — все убегают с сишки на асм!

BeOS

И как оно поживает? Дешевле вышло, чем опенбзд? Взлетело за счет дешевизны разработки и всех порвало?

PalmOS

Не легаси ничуть.

Чсх что симба, что беос, что палм померли, а вот бзди и линуксы, да куникс с виндой живее всех живых.

anonymous
()
Ответ на: комментарий от anonymous

В крестах каждая вторая либа пилит свою модель памяти: у qt своя, у glib своя, половина либ делает какой алокатор или кучу выделяет, мрак, короче.

А давайте еще примеров. Пока только одна C++ная либа упомянута, да и в той поддержка STL-евских структур данных давным-давно из коробки.

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

Для плюсов библиотек намного больше.

Если считать сишные или нет?

ООП в расте ещё менее развитое

Потому что есть алгебраические типы данных и паттерн матчинг. Про фп вс ооп в другом топике. В крестах нет ни объектов, ни типов.

из официальной документацииз официальной документации

Это другое немного. Есть же негласные идиомы в раст? Никто не городит собственные механизмы владения, как в культях?

anonymous
()
Ответ на: комментарий от tailgunner

Я и на асме знаю промышленные ос, и че? Где примеры-то, кроме сишного мака?

Ну а экспериментальные и на жаве пишут, и на питоне, на то они и экспериментальные.

anonymous
()
Ответ на: комментарий от anonymous

Про freertos благоразумно умолчал, да?

У меня нет информации о том, когда ее начали делать. А у вас есть?

Дешевле вышло, чем опенбзд?

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

Взлетело за счет дешевизны разработки и всех порвало?

Во-первых, по сравнению с Linux-ом тот же OpenBSD ни разу не взлетел. Во-вторых, разработка была продана. Так что с коммерческой точки зрения вполне себе успех.

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

Вообще я говорил про стандартные либы, а не про сторонние, ибо сторонние — это всегда зоопарк. Но и со сторонними либами в расте все здорово, учитывая, сколько там биндингов в карго, а языку всего год.

anonymous
()
Ответ на: комментарий от anonymous

Товарищ ибанат не знает что ооп это просто свод нечетких правил и определений и реализация может быть любой?

anonymous
()
Ответ на: комментарий от anonymous

В gobject есть рефлексия, пересылка сообщений, делегации искоропки, это куда как более полноценная объектная система.

В том-то и суть, что в GObject это есть, а в C11 этого нет. Так что твой пример с GObject и Vala ничем не лучше примера с QObject и MOC.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Я и на асме знаю промышленные ос, и че?

Я тоже. Правда, им 50 лет, и их новые версии уже как минимум отчасти на ЯВУ. Но таки да, это ничё. Не о них разговор.

Где примеры-то, кроме сишного мака?

Пример с Мак привел я, eao197 привел Symbian и BeOS. Ты пока не привел никаких примеров.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

В крестах каждая вторая либа пилит свою модель памяти: у qt своя, у glib своя

Казалось бы, причем тут glib.

tailgunner ★★★★★
()
Ответ на: комментарий от EXL

QObject и MOC

Ну чего ты тупишь-то? Речь была не про qobject vs gobject, а про gobject vs крестовые объекты. Чсх кресты со всеми их шаблонами и о чем там еще порвавшийся крестофанатик вещает, не позволили реализовать нормальной объектной системы с соответствующим сахарком без отдельного препроцессора, генерирующего тонны бойлерплейт кода.

Нафф сэд.

anonymous
()
Ответ на: комментарий от anonymous

Если считать сишные или нет?

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

В крестах нет ни объектов, ни типов.

Как скажешь. Замечу только, что в расте тоже не идеально (сколько ещё HKT ждать?) и улучшения будут. И я более чем уверен, что рано или поздно какие-то костыли для наследования данных всё-таки будут и тогда такие заявления будут смотреться забавно.

Никто не городит собственные механизмы владения, как в культях?

Речь о банальности типа «владельца» (parent)? Как по мне, это не особо тянет на «собственный механизм владения».

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

Ты пока не привел никаких примеров.

Всмысле, блджад, не привел?

То есть когда крестофанатик приводит в пример легаси на крестах — это ок, а когда я привожу легаси на си того же возраста или моложе (линукс-то ровесник беоса) — это не годится.

*bsd, minix, freertos, linux, hurd, plan9, amiga os, windows ce, qnx и проч. не годятся?

anonymous
()
Ответ на: комментарий от anonymous

Вообще я говорил про стандартные либы

Множественное число ведь не случайно? Из стандартной либы в расте ведь стараются выносить всё что можно отдельно. И я не уверен, что это всегда можно продолжать считать «стандартом». И чем плюсовая стандартная библиотека хуже? Да, в ней много чего нет по сравнению со всякими джавами/шарпами, но в расте и того меньше. А уж если «околостандартный» буст посчитать...

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

*bsd, minix, freertos, linux, hurd, plan9, amiga os, windows ce, qnx и проч. не годятся?

Нет. Требовались ОС, которые начали писаться менее 20 лет назад.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

*bsd, minix, freertos, linux, hurd, plan9, amiga os, windows ce, qnx и проч. не годятся?

Цитирую: «Ирония в том, что все примеры из этой области имеют возраст от 20 лет и больше.»

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

костыли для наследования данных всё-таки будут и тогда такие заявления будут смотреться забавно.

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

anonymous
()
Ответ на: комментарий от tailgunner

Ну так что палм, что беос старше 20 лет. О чем и речь.

То есть когда крестофанатик приводит в пример легаси на крестах — это ок, а когда я привожу легаси на си того же возраста или моложе (линукс-то ровесник беоса) — это не годится.

anonymous
()
Ответ на: комментарий от DarkEld3r

но в расте и того меньше

До недавнего времени в стандартной либе с++ не было юникод строк.

anonymous
()
Ответ на: комментарий от anonymous

Чсх кресты со всеми их шаблонами

Тогда не смогли, да. Причина? А не в том ли, что раньше в крестах и сишке оно мало кому нужно было. Все пользовались обрезком объектной системы и не жужжали. А тем кому нужна была всякая там рефлексия, сигналы-слоты — брали соответствующие библиотеки (как и в C) или другой язык (ту же Java) и тоже не жужжали.

Только сейчас началась вся эта эпопея с «осовремениванием» плюсцов. И вот уже в Qt 6 подумывают выкидывать MOC и переходить на C++ reflection: https://woboq.com/blog/reflection-in-cpp-and-qt-moc.html

Не понимаю, почему тебя зло так распирает. Хреново задизайненный язычок причёсывают, делая этот мир лучше. Но тебе что-то всё равно не нравится.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Без этого твои слова - пустой треп.

Пустой трёп - это когда ООП отождествляют с компелятором цепепе :-) Это ещё и признак неполного понимания того, что такое ООП :-)

Впрочем, если тебя это устраивает, то делать ничего не нужно.

Да, ведь я могу и на bash писать в ООП-стиле :-) Причём динамическое связывание получается на ура :-) Так что ты тут мне не рассказывай, теоретик :-) Ты вот лучше скажи, а можно ли на цепепе писать так же продуктивно и быстро, как, скажем, на питоне? :-)

anonymous
()
Ответ на: комментарий от anonymous

Ну так что палм, что беос старше 20 лет. О чем и речь.

Еще раз: примеры ОС на Си, которым меньше 20 лет, будут или нет?

tailgunner ★★★★★
()
Ответ на: комментарий от EXL

А не в том ли, что раньше в крестах и сишке оно мало кому нужно было. Все пользовались обрезком объектной системы и не жужжали.

Дело куда проще. До начала 2000-х с поддержкой продвинутых возможностей C++ (шаблонов, исключений и STL) дело было так себе. Поэтому, если требовалась нормальная кроссплатформенность, приходилось очень сильно ограничивать подмножество C++. Что уж говорить о том, что было в начале 90-х.

Но где-то с 2002-го года ситуация сильно поменялась.

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.