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

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

Т.е. когда функция, выглядящая как std::string parse(...) вместо результата парсинга возвращает ошибку в виде std::string - это называется «Уровень возможной реализации»? :-) Хахаха :-)

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

Ага, на цепепе дорого, а на лиспе никому не нужно уже много лет XD

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

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

Т.е. когда функция, выглядящая как std::string parse(...) вместо результата парсинга возвращает ошибку в виде std::string - это называется «Уровень возможной реализации»?

И какой бы вариант вы лично предпочли в качестве возвращаемого значения parse()? Оставаясь в рамках C++, естественно.

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

И какой бы вариант вы лично предпочли в качестве возвращаемого значения parse()? Оставаясь в рамках C++, естественно.

Ну вот такую сигнатуру, например:

Json_object parse(const std::string& input) throw(Parse_error);
:-) А ты? :-)

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

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

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

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

А потом все эти «хорошие» либы отправляются в цифровую чёрную дыру.

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

Ну а теперь спросите мнение, например, RazrFalcon по поводу API с исключениями. Его такой вариант, полагаю, совсем не устроит.

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

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

А потом все эти «хорошие» либы отправляются в цифровую чёрную дыру.

Меня откровенно коробит от выражения «хорошая либа». Хорошесть — это очень субъективный критерий.

Кроме того, речь шла о прикладных либах, облегчающих решение каких-то прикладных задач. Думаю, что либы с поддержкой протоколов FIX или ISO8583, или с реализацией PDU из GSM 03.40 или 04.11, даже будучи опубликованными как OpenSource, не вызовут такой же интерес и ажиотаж, как какой-нибудь Boost.Spirit или Boost.Hana.

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

Это не важно - важно лишь то, что попроси я у тебя пруфцов - ты их не предоставишь, а если предоставишь - я их помножу на ноль. Но ты всегда можешь попытаться.

Я не буду даже пытаться. У меня правило не спорить с идиотами. Да и несешь ты такой бред что спорить с тобой это само по себе позор для оппонента. Не забывай про таблетки, удачи!

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

А вот и новая личина царя.

Повзрослевшего и остепенившегося. Так и на ЫмпЕратора потянет;-)

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

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

Скорее наверное заточенности рук?

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

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

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

Скорее наверное заточенности рук?

Нет. Для Си++ гораздо лучшие IDE, чем для Python, они компенсируют преимущества Python как языка. Ну а рефакторить свой код в Си++ гораздо проще.

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

Я мало знаю о числодробилке, но по крайней мере сейчас - нельзя. Про биндинги к сишным числодробильным либам я не слышал, а писание вычислительного кода на Rust с нуля требует программистов, а не математиков с физиками :-P

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

Для Си++ гораздо лучшие IDE, чем для Python

Блин.. .ощущаю себя замшелым ископаемым со своим не настроенным емаксом;-(

писание вычислительного кода на Rust с нуля требует программистов, а не математиков с физиками :-P

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

Добби подарили носок (tailgunner назвал меня программистом!!!) :-P

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

ощущаю себя замшелым ископаемым со своим не настроенным емаксом;-(

IDE реально экономят время. Для Emacs, кстати, есть rtags и irony-mode.

Добби подарили носок (tailgunner назвал меня программистом!!!) :-P

Извини, но тебе относилось «математики с физиками» %)

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

писание вычислительного кода на Rust с нуля требует программистов, а не математиков с физиками :-P

Я пишу на плюсах вычислительный код с нуля (ну юзаю свои либы), так кто же я? ;-)

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

Это интересный вопрос. Предлагаю тест: если ты начинаешь писать на Rust и при этом, несмотря на всё раздражение borrow checker, понимаешь его необходимость, ты определенно программист :)

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

Щас вот в горы уеду, и там может и начну...

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

с переходом к менее нагруженному узлу за N(1)...

За сколько, простите?

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

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

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

Ну а теперь спросите мнение, например, RazrFalcon по поводу API с исключениями. Его такой вариант, полагаю, совсем не устроит.

С какой радости меня должно интересовать мнение некоего RazrFalcon касаемо стиля программирования на цепепе, если и ежу понятно, что исключения придумали для того, чтобы сигнализировать об ошибке, а std::string придумали для хранения строковых данных? :-) Лол :-) Ну а ежели программисты на цепепе вынуждены городить такой вот несуразный огород, где функция возвращает строку с ошибкой, и это при наличии целого механизма языка под названием «исключения», то мне их искренне жаль :-)

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

Что характерно, каждый из малолетних дебилов знает, как нужно правильно программировать на C++. Показать, блин, только никто не может.

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

Что характерно, каждый из малолетних дебилов знает, как нужно правильно программировать на C++.

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

Показать, блин, только никто не может.

Почему не может никто? :-) Вон выше по треду показали пару десятков либ для парсинга JSON :-) Одна из них возвращает строку с описанием ошибки из функции синтаксического разбора - parse() :-) Наслаждайся :-)

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

Слышал про такое выражение, как «дурной вкус»? :-)

А... ты типа эталон хорошего вкуса. Ну окей.

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

Ты намекаешь на аудиторию, что программирует на цепепе?

Намекаю на местных аналитиков. На вас конкретно.

Одна из них возвращает строку с описанием ошибки из функции синтаксического разбора - parse()

Ну ёптыть, какие проблемы. Покажите как нужно.

А потом тоже самое для условий, когда исключения запрещены на уровне ключей компилятора.

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

имеется в виду, что одна шаблонная ф-ция — это 100500 в месте определения, и шаблоны, как правило, инлайнятся

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

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

Намекаю на местных аналитиков. На вас конкретно.

Так мне в голову никогда не пришла бы идея возвращать из функции разбора на C++14 объект std::string с текстом ошибки :-) У меня таких проблем с аналитикой не наблюдается :-)

Ну ёптыть, какие проблемы. Покажите как нужно.

Какая у тебя короткая память :-) Нельзя так много программировать на цепепе :-) Уже ведь показал сигнатуру :-)

А потом тоже самое для условий, когда исключения запрещены на уровне ключей компилятора.

Какие-то там ключи компилятора меня вообще никак не волнуют :-)

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

читать научитесь: «и микрооптимизаций на местах»

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

Так мне в голову никогда не пришла бы идея возвращать из функции разбора на C++14 объект std::string с текстом ошибки

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

Покажите свою аналитику, подскажите, как этим людям жить?

Уже ведь показал сигнатуру

Это в которой throw-спецификатор стоит? Ваши знания C++ устарели лет на надцать.

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

похоже, анониму следовало адресовать это вам, прошу проигнорировать его невоспитанность: Производительность C++ (комментарий)

до длинны, которая уже не поместится в кеш.

это нереально. на современных процессорах в кеш поместится старое ядро линукса, дум и ещё место останется.

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

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

Мне не приходит в голову, зачем брать для проекта язык, часть которого нужно принудительно отключать «на уровне ключей компилятора» :-) Лол :-)

Покажите свою аналитику, подскажите, как этим людям жить?

Не знаю :-) Возможно, выбрать язык без исключений, т.е. C :-)

Это в которой throw-спецификатор стоит? Ваши знания C++ устарели лет на надцать.

Предложенная сигнатура соответствует стандарту, принятому в 2014 году :-) Так что мои знания устарели на 2 года, а не на «надцать» :-)

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

Мне не приходит в голову

Это очень заметно.

Предложенная сигнатура соответствует стандарту, принятому в 2014 году

Матчасть учите, дятел.

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

Это очень заметно.
Матчасть учите, дятел.

Вот видишь, как быстро исчерпала себя твоя аргументация :-) Крыть стало нечем, и ты скатился к банальным и дешёвым оскорблениям :-) Ведь я говорю о разделе 15.4 стандарта ISO/IEC 14882, где описываются спецификаторы исключений :-) И ведь если ты не покажешь место в данном стандарте, где сказано, что эти спецификаторы deprecated, то ты просто трепло :-)

PS. Я то знаю про то, что в книжечках того же Саттера говорится про то, что «спецификаторы исключений приносят больше проблем...» и прочее бла-бла :-)

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

И ведь если ты не покажешь место в данном стандарте, где сказано, что эти спецификаторы deprecated,

Малолетний дебил, блин.

Раздел 15.4

17 [ Note: The use of dynamic-exception-specifications is deprecated (see Annex D). —end note ]

Приложение D:

D.4 Dynamic exception specifications [depr.except.spec]

1 The use of dynamic-exception-specifications is deprecated.

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

Малолетний дебил, блин.

Ну зачем же так сразу? :-) Эйфория от того, что выкрутился из этой ситуации? :-) Ну так смотри сюда, сигнатура, указанная мною:

Json_object parse(const std::string&) throw(Parse_error);
демонстрирует моё предложение, чтобы parse() генерировала исключение, а не возвращала дурь с текстом ошибки :-) Мне в лом писать этот факт в комментарии, когда можно написать на цепепе :-) Не надо так паниковать сразу :-) Ну да, язык маргинальным стал, что же теперь поделать? :-)

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

Ну почему же сразу? По совокупности заслуг.

Лол :-) Быль всего лишь вопрос про 2 библиотеки на C++14 - для разбора JSON и для запуска сервера HTTP/2 :-) Ты предложил библиотеку, которая, прямо скажем, не отвечает стилю ни C++14, ни даже C++98 :-) Учитывая то, что ты тут кичишься своим опытом, это выглядит очень странно :-) Потому что даже когда предлагается реально идиоматичное решение, опирающееся на базовые возможности языка - исключения, тут же начинается истерика экспертов и упоминания о существовании неких «ключей компиляторов» и о командах неких программистов, которые зачем то выбрали цепепе, а теперь мучаются, принудительно отключая те или иные значительные части языка, описанного в стандарте :-) Неразбериха, как она есть :-) Вот она, действительно серьёзная проблема цепепе, существенно усложняющая и удорожающая разработку на C++, а не какие там скорость dynamic_cast, виртуальные функции, и шаблоны, раздувающие код :-) Лол :-)

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

Ну зачем же так сразу?

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

демонстрирует моё предложение, чтобы parse() генерировала исключение, а не возвращала дурь с текстом ошибки

Ваше предложение давно было понято. Но вы не ответили, что нужно делать в ситуации, когда a) нужно оставаться в рамках C++ и b) использовать исключение нельзя.

Может удивите меня и таки ответите?

библиотеку, которая, прямо скажем, не отвечает стилю ни C++14, ни даже C++98

Ануткать, объясните публике, в чем состоит стиль C++14 или, хотя бы, C++98?

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

Лол :-) Быль всего лишь вопрос про 2 библиотеки на C++14 - для разбора JSON и для запуска сервера HTTP/2 :-)

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

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

на C++ пишут проекты, в которых исключения запрещены. Вообще. На уровне ключей компилятора.

Поддерживаю.

Напомнило о тех временах, когда написал для Palm OS небольшое приложение на Си++. Буквально пришлось отказаться и от исключений, и от RTTI. Точных деталей уже не помню, но, кажется, при компиляции с поддержкой исключений дюже раздувалась глобальная секция, а она всего была одна и с ограниченным размером. Но отключив нужное у компилятора Си++ в GCC, удавалось писать такие же «объемные» приложения для Palm OS, как и на голых Сях.

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

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

Там свой мир, свои библиотеки, свои подходы к разработке. Но C++ и там остается C++ом со всеми выигрышами от шаблонов, RAII и пр.

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

Возврат sum type наше всё.

А потом засахаризуем его try!, ?? или постфиксными ? и !. И получим те же исключения, вид сбоку.

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

в которых исключения запрещены.

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

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

Но отключив нужное у компилятора Си++ в GCC, удавалось писать такие же «объемные» приложения для Palm OS, как и на голых Сях.

Суть крестов, бгг.

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

А потом засахаризуем его try!, ?? или постфиксными ? и !. И получим те же исключения, вид сбоку.

Интересно, что конкретно будет «тем же»?

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

Чому ты такой порватка, тебя в детстве травили?

Спокойней надо быть, дискуссию вести уметь. Откуда у плюсов вообще такие оголтелые фанатики, интересно? Сколько видел жавистов, жабаскриптеров, сишников, шарперов — ни один так не рвался от упоминания других языков и не пытался доказать, что его язык лучше всех. Прям комплексы какие-то у плюсплюснутых, платят что-ли мало?

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