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)
Ответ на: комментарий от anonymous

Это я уже лет 10 в разработке gcc участвую.

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

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

Единственное, что можно сказать уверенно - ты можешь трепаться.

Т.е. на цепепе писать столь же быстро, как на питоне, нельзя :-) Таким образом, для абсолютного большинства, питон оказывается лучше, чем цепепе :-) Вывод: цепепе сегодня - удел маргиналов :-) Лол :-)

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

Ты вот лучше скажи, а можно ли на цепепе писать так же продуктивно и быстро, как, скажем, на питоне? :-)

За Питон не скажу, могу за Ruby сказать. При наличии заточенных под предметную область либ — запросто. Плюс дополнительный выигрыш получается при тестировании и последующем сопровождении (в сопровождении старый код на динамическом ЯП — это тяжко).

Если же библиотек нет или когда в команде оказывается один-два дятла, не имеющих мозгов понять, что такое указатель, то нельзя, конечно же.

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

ведь я могу и на bash писать в ООП-стиле :-)

Единственное, что можно сказать уверенно - ты можешь трепаться.

Т.е. на цепепе писать столь же быстро, как на питоне, нельзя :-)

Bash, Python... всё смешалось. И да, на Си++ можно писать быстрее, чем на Python. Вопрос библиотек.

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

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

Ну freertos около десяти лет так-то. Бугуртос и того моложе. Bertos тот же. Да почти весь список rtos на си. Только к чему этот аргумент про <<кококо старое>>, если крестофанатик сам жуткое легаси приплел?

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

При наличии заточенных под предметную область либ — запросто.

Вот именно, но либ таких малая малость :-)

Плюс дополнительный выигрыш получается при тестировании и последующем сопровождении

В каком стиле нужно писать на цепепе, чтобы развитие системы не приводило к массовому рефакторингу в отдельных ветках git-а, растянутому на недели? :-) ООП, что в цепепе, с этой задачей справляется очень плохо :-)

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

Bash, Python... всё смешалось.

У кое-кого в голове? :-) Хм, может быть :-) Но я на bash таки умею писать в ООП :-) Это не очень трудно :-)

И да, на Си++ можно писать быстрее, чем на Python. Вопрос библиотек.

Которых нет :-) Лол :-)

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

Ну freertos около десяти лет так-то

Про freertos ничего не знаю, но вангую, что на некоторых ее таргетах просто не было Си++ (или до сих пор нет).

Только к чему этот аргумент про <<кококо старое>>

К тому, что широкое использование Си - это тупо инерция, а попытки избавиться от него предпринимаются уже 20 лет как минимум.

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

Bash, Python... всё смешалось.

У кое-кого в голове? :-)

В голове, которая перескакивает с одного на другое.

И да, на Си++ можно писать быстрее, чем на Python. Вопрос библиотек.

Которых нет :-)

У кого-то нет, у кого-то есть.

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

а попытки избавиться от него предпринимаются уже 20 лет как минимум.

То есть убегающие превратились в пытающихся убежать. Ясно, вопросов больше не имею.

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

а попытки избавиться от него предпринимаются уже 20 лет как минимум.

То есть убегающие превратились в пытающихся убежать

Все, кому удалось убежать (частичный список удачных побегов приведен), до этого были «пытающимися убежать».

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

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

Как будто что-то плохое. Универсального подхода не существует. Каждый пилит под свои потребности, благо язык позволяет.

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

Только к чему этот аргумент

Повторю еще раз для малолетних дебилов: примеры того, что C отлично подходит под ряд предметных областей (ядра ОС, встраиваемые системы, системное ПО) как правило, повторюсь, как правило, имеют историю из десятков лет и уходят во времена, когда C++ не был насколько реальной альтернативой C, как в последние годы.

Кроме того, даже на временном интервале в 20 лет легко находятся примеры ОС, которые либо были разработаны на C++, либо переходят на C++.

При этом такие примеры вовсе не должны означать, что сейчас ядра ОС должны разрабатываться исключительно на C++.

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

Вот именно, но либ таких малая малость

Во-первых, мы над этим работаем.

Во-вторых, бывают заточенные под конкретные предметные области либы, про которые широкая публика вообще не знает. И которые в OpenSource могут вообще никогда не уйти.

В каком стиле нужно писать на цепепе, чтобы развитие системы не приводило к массовому рефакторингу в отдельных ветках git-а, растянутому на недели?

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

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

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

Советую почитать историю и не позорится. Когда Qt изобретали велосипед/MOC, половина компиляторов не умела шаблоны, исключения и rtti. Сейчас бы писали совсем по-другому.

ЧСХ, есть форк Qt4, который работает без MOC, тупо на шаблонах.

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

В голове, которая перескакивает с одного на другое.

Это нормальное мышление, в отличии от мышления персон, которые игнорируют задаваемые им вопросы :-)

У кого-то нет, у кого-то есть.

Пусть требуются 2 компактные и качественные библиотеки на Си++14: парсер JSON, сервер HTTP/2 :-) Какие будут предложения? :-)

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

Во-первых, мы над этим работаем.

Ну, т.е., иными словами «все либы на цепепе мы пишем сами, потому что готовых нет» :-)

Во-вторых, бывают заточенные под конкретные предметные области либы, про которые широкая публика вообще не знает. И которые в OpenSource могут вообще никогда не уйти.

Т.е. «хороших и готовых либ на цепепе нет и никогда не будут доступны публике» :-)

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

Ну, знаешь, это уж слишком абстрактно :-)

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

Сколько тебе Гвидо платит за унылый пиар, анон?

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

В том-то всё и дело, что C++ завоевал тогда ынтерпрайзный рынок, как выразился анончик «структурками с методами». Если бы можно было заглянуть в код того же BeOS/Symbian OS, то вряд ли там нашлись бы исключения и куча шаблонов.

Вот и вся суть нынешней популярности C++: разработчикам нужна была лишь возможность создания простеньких классов с деструкторами, namespace'ы и сопряжение с библиотеками на C. И всё это, желательно, без макросной лапши, которую хрен нормально отдебажишь.

Языки, которые реализовывали более мощное и функциональное ООП, тот же Smalltalk — канули в Лету. А плюсцы, которым постепенно «пришивали» очередные ножки, вертятся в котле до сих пор.

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

Пусть требуются 2 компактные и качественные библиотеки на Си++14: парсер JSON, сервер HTTP/2 :-) Какие будут предложения? :-)

На счет HTTP/2 ничего не скажу, не сталкивался. По поводу JSON-а можно глянуть сюда: https://github.com/miloyip/nativejson-benchmark

Мы используем у себя RapidJSON с небольшой нашлепкой в духе Boost.Serialize. Вполне нормально.

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

хватит одной - gRPC. или из нее взять что нужно.

Нет, мне нужны 2 конкретные маленькие либы, а не фреймворки самоуверенных авторов, планирующих захватить рынок своими поделиями :-)

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

планирующих захватить рынок своими поделиями :-)

это google. он уже захватил, с разморозкой

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

Но я на bash таки умею писать в ООП :-) Это не очень трудно :-)

Ох насмешил. То есть язычок, в котором всё строка, имеет лучшее ООП, через статически типизированный ЯП?

В дурке явно день открытых дверей.

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

В голове, которая перескакивает с одного на другое.

Это нормальное мышление

Ну окей.

Пусть требуются 2 компактные и качественные библиотеки на Си++14: парсер JSON, сервер HTTP/2 :-) Какие будут предложения? :-)

Для JSON меня устраивает picojson, а HTTP/2 мне без надобности. Но, естественно, библиотеки для него есть.

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

Я не думаю, что C++ и тогда был на энтерпрайзном рынке. Если был, то в виде middleware (типа CORBA-брокеров, менеджеров транзакций и т.д.). Ну или десктопных приложений для конечных пользователей (вроде AutoCAD, Photoshop, CorelDRAW, Illistrator, 3DMax и т.д.), что вряд ли можно считать энтерпрайзом.

Ну и там, где нужда в C++ была, продвинутые возможности C++ (включая шаблоны и исключения) использовались сразу же, как они оказывались доступны разработчикам. Благо, разработкой кроссплатформенных вещей занимался небольшой процент, а большинство пилило софт под одну какую-то платформу.

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

Ох насмешил. То есть язычок, в котором всё строка, имеет лучшее ООП, через статически типизированный ЯП?
В дурке явно день открытых дверей.

Расписание дурки мне неведомо, возможно, ты в курсе :-) А я всего лишь сказал, что умею писать в ООП стиле на bash, не говоря ни слова про «лучше» :-) Лол :-)

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

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

Извини, нет времени перебирать 37 библиотек для работы с JSON :-) За это время я напишу 38-ю :-) Лол :-) Это я к тому, что заявление «при наличии библиотек на цепепе не жизнь, а сахар» - пустое :-)

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

что умею писать

давно выяснили, что ты просто трепло и писать умеешь только на ЛОР. И даже на ЛОР не в ООП стиле.

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

Ну, т.е., иными словами

Иными словами, когда делаем что-то полезное для себя, то выкладываем это в OpenSource. Если считаем это выгодным.

Т.е. «хороших и готовых либ на цепепе нет и никогда не будут доступны публике»

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

Ну, знаешь, это уж слишком абстрактно

Да, для некоторых «здравый смысл» — это уж слишком абстрактно.

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

Мы про CopperSpice? Как по мне, это чисто proof of concept, ибо из заверений автора, использовался транслятор кода, а не переписывание либы с нуля.

PS: собрать в своё время не смог - OOM.

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

Ага, на Си.

Причём тут Си, если я говорил про Си++14 :-) Кто-то там про перепрыгивание в голове что-то говорил :-) Лол :-)

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

Причём тут Си

При том, что писать новую JSON-либу ты будешь на Си. Ведь Си++ говно, от которого умирают котята^W^Wобразуются ветки рефакторинга.

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

Ага, которая сдохнет от недостачи памяти на машине-парсере, ибо твои 38 сортов говна жрут как не в себя))

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

Для JSON меня устраивает picojson

Смотрим на picojson:

std::string json = "[ \"hello JSON\" ]";
picojson::value v;
std::string err = picojson::parse(v, json);
if (! err.empty()) {
  std:cerr << err << std::endl;
}
Т.е., parse() возвращает ошибку, и тип этой ошибки - std::string :-) Ахаха :-) А как же стиль «ошибка = исключение»? :-) Ах да, он имел в виду, что исключение может быть при копировании std::string :-) Лол :-) Это что, в стиле цепепе как учил Страуструп? :-)

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

Ага, которая сдохнет от недостачи памяти на машине-парсере, ибо твои 38 сортов говна жрут как не в себя))

Т.е. писать на цепепе - уже само по себе вредно :-)

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

частичный список удачных побегов приведен

Это три двадцатилетней давности провальных оси-то?

Ясно. То есть успешный линукс и провальный беос говорят нам об успешном массовом побеге на кресты.

anonymous
()

Ядра всех ОС написаны на С, так что думай сам что быстрей и лучше.

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

Ну так сипипи же, кто во что горазд.

Ты еще акторы местного крестофанатика для мигания диодами не видел.

anonymous
()

Автор топика сасает пока все ругаются.

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

Иными словами, когда делаем что-то полезное для себя, то выкладываем это в OpenSource. Если считаем это выгодным.
Их есть, а публике они не будут доступны до тех пор, пока их использование в закрытом виде приносит деньги владельцам бизнеса.
Да, для некоторых «здравый смысл» — это уж слишком абстрактно.

Ну, т.е., понятно, либ для цепепе хороших в свободном доступе как кот наплакал, все пилят свои велосипеды и давятся boost-ом :-) Отсюда вывод, писать на цепепе очень медленно и дорого :-)

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

Ты еще акторы местного крестофанатика для мигания диодами не видел.

А что там, тоже std::string в качестве возвращаемого значения из функции для индикации ошибки, как в picojson? :-) Или там новшество using Error = std::string? :-)

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

Ну, т.е., понятно, либ для цепепе хороших в свободном доступе как кот наплакал, все пилят свои велосипеды и давятся boost-ом :-) Отсюда вывод, писать на цепепе очень медленно и дорого :-)

Да, для некоторых «здравый смысл» — это уж слишком абстрактно.

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

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

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