@rikimaru2013

Добрый вечер,

встревожила и заставила задуматься статья https://habrahabr.ru/company/p... og/301736/

Ведь действительно, для меня лично, С++ является средне-уровненным языком так как содержит, как доступ к управлению данными через адресса, но и приятные высокоуровневые вещи присущие высокоуровневым языкам.

Да на новой философии и возможностях С++11 и С++14 приятнее писать, но я никогда и не задумывался, что скорость падает. Теперь задумываюсь ((( Стоит ли? (Ведь задача С++ выжать максимум с таргета, для других целях лучше выбрать другие языки)

0

@Renji

Появившийся в C++11 перемещающий конструктор однозначно поднимает скорость программы. Появившиеся там же variadic template позволяют реализовать emplace методы, что опять же однозначно поднимает скорость за счет ухода от копирования аргументов туда-сюда.

PS Лучше бы вас встревожила не статья, а отсутствие в ней каких либо конкретных примеров падения производительности. Ну, кроме iostream которому сто лет в обед. Причем, чтобы устранить тормоза iostream, его потроха как раз таки придется переводить на шаблонные рельсы.

1

@_Ivana

Не помню, в самой статье или в комментариях проскочила мысль, что в С++ в рамках одного языка можно критические к скорости и производительности вещи писать в pure С стиле, а в тех местах, где не так важна производительность - пользоваться всеми имеющимися приятными высокоуровневыми абстракциями. Хотя многим из них далеко до абстракций других языков.

1

@Nosey

Соглашаюсь с предыдущими сообщениями.
И насчёт статьи - слишком она поверхностная, а единственную ссылку на приведенное в статье видео я пока не смотрел, каюсь
Но я хочу привести вот эту ссылку(Насколько медленны iostreams?). Там в конце статьи есть соответственно замеры времени исполнения -> возникает вопрос, что автор первой статьи подразумевает под , если уж boost::spirit оказывается быстрее и соответственно он не создает трудностей, и чтож за боги столько компайлтайм абстракций налабали которые таки создают трудности.

3

IGPIGP

Я не смог понять кому принадлежит статья. Слова Блог компании PVS-Studio не вяжутся с действительностью так как PVS-Studio - это программа, а не компания, анализатор кода для С-подобных языков. Если использовать слово компания то очень всё это напоминает "вброс" рекламной кампании .
На всякий случай спрошу: rikimaru2013, имеете процент от?

0

@rikimaru2013

0

IGPIGP

Опять нет подписи. Имхо, это сам Гугл написал.
rikimaru2013, колитесь в чём тут дело.

0

@rikimaru2013

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

0

IGPIGP

0

@Геомеханик

Приятно то приятно, если писать небольшие программки. Когда проект достигает более 50k строк, вот тогда лишние конструкции не к чему. В больших и даже средних проектах легко допустить ошибку даже в логических выражениях или набить переизбыток конструкций. Из-за перелопачивание больших кусков строк кода внимательность падает, отсюда и возникают ошибки. Кстати статический анализатор PVS-Studio частенько доказывает это. На счёт скорости это да, ибо за компактность и обобщённость нужно платить!

2

@Mr.X

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

0

@Renji

Вы полагаете что myVector.push_back(MyObject(1,2,3,4)) быстрее чем myVector.emplace_back(1,2,3,4)? Спешу вас огорчить, второй вариант будет быстрее. Потому как первый вариант формирует временный объект и копирует его в вектор. А второй вариант формирует объект сразу в недрах вектора.

Если же мы пихаем объект в map, то второй вариант (через emplace) еще и позволяет выкинуть наконец эти жуткие std::make_pair.

0

@hoggy

статья - липа.
в ней нет никаких подтверждений собственным тезисам.
она целиком и полностью опирается на авторитет автора статьи.

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

сейчас же это какой то сферический конь в вакууме.
автор сильно смахивает на неосилятора.

2

@Kastaneda

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

2

@Mr.X

, который забыл подписаться.

0

@hoggy

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

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

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

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

0

@ct0r

А че тут спешить-то? И так все понятно. Оптимизации и уровни оптимизации конкретных компиляторов интересуют чуть менее, чем никак. Собираешь одним компилем - летает, переключил компилятор - лаг на лаге. Отлаживаешься в -O0 или собираешь стату по покрытию - тормозят абсолютно все. Нет, такой сказки нам не надо. Писать push_bask там, где можно emplace_back - это пессимизация от недостатка знаний или внимательности, только и всего.

1

@tapochka

лично я когда пришел на первое место практики, то пришлось иметь дело как раз с Verilog HDL... поэтому увидев призыв переходить с С++ на verilog какой-нибудь - ну я был в шоке честно говоря... настолько разные концепции языков и области применения. verilog языком то программирования назвать имхо нельзя - язык описания цифровой схемотехники тупо, не более; DSL фактически... после этого как-то под вопросом были эти "факты" о тормознутости шаблонов и т.д. Ну что хорошего из верилога я вынес - ну знать стал как работают дешифраторы всякие, компараторы, чем т-триггер отличается д-триггера... да и то уж забыл почти все)

1

@hoggy

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

однако, я не согласен с пессимизацией.
недостаток знаний здесь может проявляться в том,
что исполнитель не в курсе, всяческих RVO/NRVO/copy elision

к тому же, там в статье приключился тезис,
согласно которому, способность inline подстановки в шаблонах - это миф.

но этому нет подтверждений.

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

1

@yuyaryshev

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

Но это совсем не повод от них отказываться. Это классический вопрос преждевременной оптимизации.

Однако есть более существенная проблема: архитектура. И вот тут действительно, когда вопрос про нее нужно быть очень аккуратным.

Допустим я сомневаюсь что стоит завязывать процесс отрисовки кадра в игре на лямбды и предикаты.
Как я понимаю как-раз таки пытавшиеся это сделать и пришли в итоге к вот таким темам:
http://www.codeproject.com/Art... -Delegates

То есть по сути есть проекты которые пытаются переписать стандартные std::function по новому так чтобы побыстрее работало, причем им порой это удается (где то видел бенчмарки, сейчас ссылку сходу не дам).

Впрочем и такой подход тоже вполне применим.

Однако вся эта тема никак не связана с большой частью любой программы которая не лежит на критическом пути.
Даже в играх 90% кода наверняка можно и нужно писать с использованием всех последних веяний и это только улучшит проект.

1