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)

Ответ на: комментарий от mbivanyuk

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

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

8) Скорость компиляции - это конечно боль. Но есть инкрементальная компиляция, которая нивелирует эти затраты.

9) Разве? Если собирать без исключений и rtti будет не намного больше.

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

По субжу: да, если на крестах писать как на си, скорость будет как на си, но зачем тогда нужны кресты? Полиморфизм и в си завезли, объектных систем в сишке море на любой вкус, разве что шаблонов не хватает.

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

eao197 ★★★★★
()

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

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

Если сложность задачи такова

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

Так а если сложность задачи много выше, что мешает использовать нормальные языки программирования, вроде джавы, раста, шарпа или окамла — языков с нормальной моделью памяти, библиотеками и архитектурой. Чсх те же майки давно все на шарп переписали, ибо %#аться с крестами в 2016 году...

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

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

Неверно, у них weak linkage.

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

с ручной реализацией объектов

И что в твоем понимании ручная реализация объектов?

Gobject — ручная реализация? А те структурки с функциями в крестах без рефлексии, нормальной делегации и пересылки сообщений — объектная система?

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

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

Идём почти в любой *.с файл этого вашего GCC

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

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

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

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

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

Чем «сишечка»? Лучше.

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

Высокие накладные расходы?

Чсх те же майки давно все на шарп переписали, ибо %#аться с крестами в 2016 году...

Ну и что они такое переписали? Windows, Edge, Visual Studio, MS SQL Server, Office, Bing? Там везде плюсов столько, что трахаться с крестами будут еще дети тех, кто сейчас на LOR-е звездит.

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

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

Как ни странно, но «нормальность» им не помогла обогнать плюсы.

джавы

Не для десктопа. Уверенно держит лидерство в своей области.

раста

Языку год. Он еще слишком сырой и далёк от замены плюсам.

шарпа

За 16 лет так и не выбился в люди. Оставаясь в своём windows мирке.

окамла

Академический язык.

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

И что в твоем понимании ручная реализация объектов?

Что-то вроде:

struct some_type {
  void (*do_something)(some_type * this);
  void (*do_something_else)(some_type * this, int arg);
  ...
};

А те структурки с функциями в крестах без рефлексии, нормальной делегации и пересылки сообщений — объектная система?

Таки да.

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

На «сишке» его бы вообще не было.

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

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

Как ни странно, но «нормальность» им не помогла обогнать плюсы.

Обогнать в чем? Java точно используется шире, чем плюсы, C# - наверное, тоже.

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

Надо было и ядро ляпикса на плюсах строчить

Линус знает чего делает. И ресурсов в ядро Linux-а вбухано гораздо больше, чем в огромное количество коммерческих проектов.

Ну и опыт Linux-а не мешает людям делать ОСы на C++.

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

Ну они честные - нету С++ вот и не поменяли. А как будет С++ - поменяют.

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

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

Используется он там из-за шаблонов функций и деструкторов :-)

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

Вообще. Открыть любой топ языков - Java и С++ будут в пятерке. Java, обычно, популярнее.

То, что C# используется больше С++ - сомневаюсь. Но пруфов нет.

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

накладные расходы

Чем на написание кода на жаве? Написание кода на жаве стоит во сто крат дешевле.

Ну и что они такое переписали?

Все, практически, весь юзерспейс там давно на дотнете. Кортаны всякие, edge — все на F#/C#. Студия и скуль разве что на крестах, ибо легаси. Ну ядро, и то по большей части на сишке.

Чем «сишечка»? Лучше.

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

Яркий пример:

https://gcc.gnu.org/onlinedocs/libstdc /libstdc -html-USERS-4.4/a01347.html

http://web.mit.edu/dosathena/sandbox/emacs-19.28/lib-src/qsort.c

В крестах нет ни нормальной объектной системы, ни алгебраических типов, ни паттерн матчинга, ни макросов, да что там, даже с указателями беда: есть ли в крестах что-то вроде Box из rust? Накладные расходы, лол.

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

Используется он там из-за шаблонов функций и деструкторов :-)

Пруфец в виде ссылки на файлики с template хочу, мой смайлофажный анончик.

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

Чем на написание кода на жаве? Написание кода на жаве стоит во сто крат дешевле.

Сейчас в ход пойдёт последний аргумент в такой ситуации - «присутствие сборщика мусора в жаве» :-)

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

Таки да.

Таки пародия это на объектную систему.

На «сишке»

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

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

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

Чем «сишечка»? Лучше.

Вообще несущественно. Траха с крестами практичести столько же на фоне нормальных языков

Если уж заговорил о «трахе на фоне нормальных языков», расскажи, какова величина траха с Си на их фоне.

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

Написание кода на жаве стоит во сто крат дешевле.

Тот код, который на Java написать в сто крат дешевле, уже давно пишут на Java.

Кортаны всякие, edge — все на F#/C#.

Пруф в студию.

Яркий пример

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

В крестах нет ни нормальной объектной системы

Где есть нормальная объектная система? Уж не в CLOS-е ли?

есть ли в крестах что-то вроде Box из rust?

Я не знаток Rust-а.

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

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

Ссылочку можно? А то мне из живых попадался разве что QP, да и то сильно заточенный под embedded.

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

Вы меня с кем-то путаете. Во-первых, никого не поучаю. Нравиться кому-то трахаться с указателями на функции в C-шных структурах — да не вопрос. А мне жалко своего времени. Во-вторых, Erlang — это динамический и не очень быстрый ЯП с очень примитивными структурами данных. Плюс нужно таскать свою VM. Для каких-то задач это все не есть хорошо.

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

C 1377900 (code)
C++ 51189 (code)
Переведена-то она переведена, только признаков С++ почему-то не обнаружилось в гцц.

Наблюдаю явное противоречие.

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

В крестах нет ни нормальной объектной системы, ни алгебраических типов, ни паттерн матчинга, ни макросов, да что там, даже с указателями беда: есть ли в крестах что-то вроде Box из rust? Накладные расходы, лол.

Ну и да, неужели это все есть в C?

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

Лораэсперт пытается меня поймать - это так мило:

$ find . -name '*.cc'
./config/tilepro/gen-mul-tables.cc
./config/sh/sh_optimize_sett_clrt.cc
./config/sh/sh-mem.cc
./config/sh/sh_treg_combine.cc
./cp/constraint.cc
./cp/logic.cc
./go/go-gcc.cc
./go/gofrontend/types.cc
./go/gofrontend/export.cc
./go/gofrontend/expressions.cc
./go/gofrontend/runtime.cc
./go/gofrontend/gogo.cc
./go/gofrontend/unsafe.cc
./go/gofrontend/statements.cc
./go/gofrontend/dataflow.cc
./go/gofrontend/go.cc
./go/gofrontend/import.cc
./go/gofrontend/parse.cc
./go/gofrontend/go-dump.cc
./go/gofrontend/escape.cc
./go/gofrontend/import-archive.cc
./go/gofrontend/ast-dump.cc
./go/gofrontend/go-optimize.cc
./go/gofrontend/lex.cc
./go/go-linemap.cc
./memory-block.cc
./jit/docs/examples/tut04-toyvm/toyvm.cc
./jit/docs/examples/tut01-hello-world.cc
./jit/docs/examples/tut02-square.cc
./jit/docs/examples/tut03-sum-of-squares.cc
./wide-int-print.cc
./wide-int.cc

Ой, что это - неужели весь С++-код не имеет отношения к гцц. Бывает.

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

Ну и да, неужели это все есть в C?

А вот у хохлов

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

Улавливай диалог:

-- На си нужно городить объектную систему

-- А на си++ не нужно?

-- Там есть

-- Структурки с методами?

-- А вот на си!!!

На си есть и подобие clos, и gobject, который ближе к ооп, чем пародия на ооп из крестов. Нагородить можно везде, я не спорю.

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

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

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

Что же касается пользовательского софта: как часто падает гномостек, и как часто кеды/плазма? То-то и оно.

У крестов очень узкая сфера применения: когда производительность критична, но не очень, и при этом проект сложный. Кроме игрушек даже не знаю, где дешевле на крестах писать. Уверен, то говно, что пишешь ты, было бы дешевле переписать на java/scala + akka.

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

Да что ж ты тупой то такой?!?

Громче нужно, вас не слышно.

Там libstdc++ и прочее барахло.

Это вы с ходу по количеству строк кода на C++ определили?

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

Ой, что это - неужели весь С++-код не имеет отношения к гцц. Бывает.

Sloc не я натравливал на сорцы компилятора, а вы. Я же ткнул вас носом в вами же приведенные «пруфы».

Ну и по поводу С++ кода в файлах *.c выше уже сказали. Только там вы снова начали крутиться как уж на сковороде.

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

Это вы с ходу по количеству строк кода на C++ определили?

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

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

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

Ирония в том, что все примеры из этой области имеют возраст от 20 лет и больше. Времена меняются. Хочется жрать C-шку и про*бывать сроки в коммерческой разработке — не вопрос.

А кто наелся этого досыта, смотрит в сторону C++ и Rust-а.

Уверен, то говно, что пишешь ты, было бы дешевле переписать на java/scala + akka.

Переписать дешевле, да. Эксплуатировать затем дороже.

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

Используется он там в основном для полиморфизма и неймспейсов

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

using namespace gcc; namespace {}

Нейспейсы такие неймспейсы. Нужность их я прям отлично ощущаю и даже не скажешь, что прям явно на 100% для галочки.

о чем сами гцц-шники говорили

Не правда. Насколько я помню куллстори - у них там случилась банальнай больничка, которая случилась у всех адептов в райне нулевых. Каждый начал писать на С/С++ - правда 95% дальше классов не ушли. Такой энтузиазм был - свой вектор написали, а потом что-то несраслось.

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

Так там же дело не в Box-е, а в Rust-овском механизме контроля за lifetime.

Ошибки, связанные с unique_ptr, ловяться с помощью статических анализаторов.

Ну и главный вопрос: где вся эта прелесть в C?

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

от 20 лет и больше

Openbsd, linux, freertos какой возраст имеют? Кто переходит на кресты? Список в студию эмбеддеда, который массово на кресты валит, а то как увижу дрова для какого сайпреса или дектека, все сишка.

C++ и Rust-а.

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

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

Где есть нормальная объектная система? Уж не в CLOS-е ли?

В CLOS-е :-)

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

Ошибки, связанные с unique_ptr, ловяться с помощью статических анализаторов.

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

А вот у хохлов

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

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

gobject, который ближе к ооп, чем пародия на ооп из крестов

Смищно. Макрос на макросе сидит и макросом погоняет.

В вики даже в открытую пишут:

The main drawback of the GObject framework is its verbosity. Large amounts of boilerplate code, such as manual definitions of type casting macros and obscure type registration incantations, are necessary to create a new class.

В своей слепой ненависти к C++ ты готов приводить даже подобные примеры.

как часто падает гномостек, и как часто кеды/плазма? То-то и оно.

Современные кеды/плазма написаны школьниками, лепящими синие сопли сбоку окон, для школьников. Не мудрено, что там постоянные сегфолты.

А вот если брать KDE 3.5 и GNOME 2/GNOME 3, то там количество падений на квадратный сантиметр было приблизительно одинаковым.

Ну и мир не идеален, я в том же GTK+ тоже натыкался на падения:

Подтвердите баг в (Firefox/GTK?)
http://i.imgur.com/onUAF3w.png

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

Дык, namespace { } тупо означает «мне лениво писать перед каждыс определением „static“, пусть трахаются те, кому мой говнокод читать.

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

Sloc не я натравливал на сорцы компилятора, а вы. Я же ткнул вас носом в вами же приведенные «пруфы».

Кого ты там ткнул. Ладно - я пощажу тебя, а то меня снова тереть начнут.

Давай разберёмся. У меня было:

gcc-6.1.0/gcc $ cloc ./

Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
C                                      808         276553         288701        1377900
Ada                                   1971         215341         287660         591735
C/C++ Header                           955          58608          63790         225781
C++                                     32           9587           7552          51189

//Чудо - не меньше.


//
$ find . -name '*.cc'
./config/tilepro/gen-mul-tables.cc
./config/sh/sh_optimize_sett_clrt.cc
./config/sh/sh-mem.cc
./config/sh/sh_treg_combine.cc
./cp/constraint.cc
./cp/logic.cc
./go/go-gcc.cc
./go/gofrontend/types.cc
./go/gofrontend/export.cc
./go/gofrontend/expressions.cc
./go/gofrontend/runtime.cc
./go/gofrontend/gogo.cc
./go/gofrontend/unsafe.cc
./go/gofrontend/statements.cc
./go/gofrontend/dataflow.cc
./go/gofrontend/go.cc
./go/gofrontend/import.cc
./go/gofrontend/parse.cc
./go/gofrontend/go-dump.cc
./go/gofrontend/escape.cc
./go/gofrontend/import-archive.cc
./go/gofrontend/ast-dump.cc
./go/gofrontend/go-optimize.cc
./go/gofrontend/lex.cc
./go/go-linemap.cc
./memory-block.cc
./jit/docs/examples/tut04-toyvm/toyvm.cc
./jit/docs/examples/tut01-hello-world.cc
./jit/docs/examples/tut02-square.cc
./jit/docs/examples/tut03-sum-of-squares.cc
./wide-int-print.cc
./wide-int.cc
//да неужели - го, доки и конфиг - т.е. признаков С++ в гцц  не обнаружено.

Т.е. вначале выкачен высер cloc, а далее показаны все С++ файлы, что он нашел. И описано их назначение: «го, доки и конфиг», а далее «т.е. признаков С++ в гцц не обнаружено.» Т.е. список файлов был определён как не имеющий отношения к конпелятору С/С++, а значит в него не входящие.

Откуда взялся С/С++ конпелятор - отсюда:

в гцц, как в самом сильном компиляторе С/С++

Ну и по поводу С++ кода в файлах *.c выше уже сказали.

Во-первых сказал не ты - это раз. Не твоё к твоим потугам отношение не имеет. Ты нашел ошибку в изначальном моём комменте, высрав не «в гцц есть кресты в си-файлах», а:

C++ 51189 (code)
Переведена-то она переведена, только признаков С++ почему-то не обнаружилось в гцц.

Наблюдаю явное противоречие.

Ты нашел противоречие в моём посте. И ты мне его покажешь. Хотя нет - ты не покажешь, но всё же попытайся.

Только там вы снова начали крутиться как уж на сковороде.

Где, конкретней и в чём. Есть что ответить валяй, только не обделывайся на первой же попытки как сейчас.

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

от 20 лет и больше

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

Такой и имеют.

как увижу дрова для какого сайпреса или дектека, все сишка.

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

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