Здравствуйте, so5team, Вы писали:
S>Пройдите таки по ссылке и сравните эффективность кружев с -O0 и -O2.
Она как-то изменится, если "шаблонные кружева" убрать совсем? Напомню, речь шла о возврате объекта по значению из набора вложенных вызовов функций, а MSVC++ умеет избегать многократных копирований только при включенной оптимизации.
, будто нелегко одним взглядом определить, во что будут транслироваться "современные шаблонные кружева". Я в ответ спросил, каким образом "кружева" могут влиять на кодогенерацию. Если компилятор не умеет что-то оптимизировать, то никакие шаблоны не спасут. А если умеет, то сможет и на любом уровне шаблонных наворотов. Поэтому нет никакого повода для иронии.
Здравствуйте, night beast, Вы писали:
NB>ну тебя же не напрягает использование большинством библиотеки std?
Я их вообще не использую.
Когда я в середине 90-х начинал писать на C++, они были в зачаточном состоянии, впоследствии же концепции и реализации неоднократно менялись. Вместо того, чтобы регулярно участвовать в обсуждениях "какого хрена std::xxx глючит на yyy", я предпочел сразу сделать себе набор простых классов и шаблонов для повседневных нужд, и полностью устраниться от этого класса проблем. Мне по уши хватало собственных глюков компиляторов, особенностей оптимизации в разных версиях, различий в SDK/DDK/WDK и т.п.
А уж в коде под ядро использование любых библиотек чаще всего превращается в квест, поскольку они очень любят исключения, которые в ядре не поддерживаются, и часто используют функции CRT, не имеющие реализации под ядром. Писать же код в двух разных стилях — под kernel-mode и под user-mode — мне никогда не нравилось. Поэтому и обхожусь до сих пор собственными реализациями, периодически добавляя туда новые возможности.
Но все это, само собой, возможно лишь при разработке замкнутых, технологически несложных продуктов (драйверы, системные расширения, утилиты и т.п.). Если б я взялся за масштабные проекты, требующие вдобавок интеграции с существующим софтом — само собой, пришлось бы использовать типовые библиотеки — и шаблонные, и интерфейсные.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Пройдите таки по ссылке и сравните эффективность кружев с -O0 и -O2.
ЕМ>Она как-то изменится, если "шаблонные кружева" убрать совсем?
Если вас интересует именно этот вопрос, то поищите ответ сами: код на godbolt-е есть, можете изменять его как вздумается.
Приведенный же пример показывает, какой оверхэд вы получите от полезных для надежности кода шаблонов, если избегаете включения оптимизатора в компиляторе. Соответственно, меня лично интересует то, зачем какие-то одаренные личности отказываются от оптимизатора по доброй воле.
ЕМ>Вы утверждали
, будто нелегко одним взглядом определить, во что будут транслироваться "современные шаблонные кружева".
Так и есть.
EM>Я в ответ спросил, каким образом "кружева" могут влиять на кодогенерацию.
Пример на godbolt-е. Может возникнуть изрядный оверхэд при отключенной оптимизации.
EM>Если компилятор не умеет что-то оптимизировать, то никакие шаблоны не спасут.
Еще раз: компилятор умеет и умеет подобное уже лет 25. Вопрос в том, зачем кому-то от этого отказываться. А сарказм возникает из-за того, что вы мало того, что заведомо отказываетесь, так еще и считаете это нормой.
Здравствуйте, so5team, Вы писали:
ЕМ>>Она как-то изменится, если "шаблонные кружева" убрать совсем?
S>код на godbolt-е есть, можете изменять его как вздумается.
Какой смысл этим заниматься, если логика работы оптимизатора не зависит от того, шаблонный код он обрабатывает, или нешаблонный? Если известно, например, что компилятор не умеет оптимизировать какие-то операции с 64-разрядными значениями для 32-разрядных архитектур, то этого не добиться, завернув исходную конструкцию хоть в сотню хитровложенных шаблонов.
Так и здесь: достаточно увидеть в этих "современных шаблонных кружевах" возврат объекта по значению, чтобы с уверенностью утверждать, что результирующий код, побитно копирующий объект перед возвратом из каждой функции, никуда не денется при любой сложности "кружев".
S>Приведенный же пример показывает, какой оверхэд вы получите от полезных для надежности кода шаблонов, если избегаете включения оптимизатора в компиляторе.
В конкретно этом случае использование стандартной реализации expected не приведет к сколько-нибудь заметному росту надежности моего кода, а вот геморроя добавит гарантированно, поэтому я с сходу и отмел этот вариант.
S>Соответственно, меня лично интересует то, зачем какие-то одаренные личности отказываются от оптимизатора по доброй воле.
Одаренные личности Вам уже и так, и этак разжевали, что использование оптимизатора во многих случаях лишает возможности увидеть значения всех переменных и вести пошаговую отладку, если вдруг сработает какая-то из охранных проверок. То, что это трудно или невозможно в полностью релизных конфигурациях, ни исключает желания иметь такую возможность в отладочных.
S>Пример на godbolt-е. Может возникнуть изрядный оверхэд при отключенной оптимизации.
А при включенной — потеряется возможность адекватно отлаживать код. Если достигаемое удобство значимо перевешивает этот недостаток — его можно принять. В данном же случае удобство весьма условно.
EM>>Если компилятор не умеет что-то оптимизировать, то никакие шаблоны не спасут.
S>Еще раз: компилятор умеет и умеет подобное уже лет 25.
Хорошо, уточняю: "не умеет оптимизировать без потери других важных свойств кода".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Какой смысл этим заниматься, если логика работы оптимизатора не зависит от того, шаблонный код он обрабатывает, или нешаблонный?
Смысл в том, что нешаблонные варианты tagged_scalar под каждое сочетание scalar_type+tag писать вряд ли будут. Будут использовать в коде голые скалярные типы. А от tagged_scalar будут оказываться потому, что в неоптимизированных вариантах есть оверхэд.
ЕМ>Так и здесь: достаточно увидеть в этих "современных шаблонных кружевах" возврат объекта по значению, чтобы с уверенностью утверждать, что результирующий код, побитно копирующий объект перед возвратом из каждой функции, никуда не денется при любой сложности "кружев".
Тут нужно определиться с тем, что вы понимаете под объектом. std::pair<int, int> -- это объект, и expected<int, int> -- тоже объект, и expected<int, std::string> -- объект, и expected<int, unique_ptr<error>> -- объект. Только стоимость возрата этих объектов будет разная. Включая и отсутствие побитного копирования в некоторых случаях.
ЕМ>Одаренные личности Вам уже и так, и этак разжевали, что использование оптимизатора во многих случаях лишает возможности увидеть значения всех переменных и вести пошаговую отладку, если вдруг сработает какая-то из охранных проверок. То, что это трудно или невозможно в полностью релизных конфигурациях, ни исключает желания иметь такую возможность в отладочных.
Если вам скорость неоптимизированного кода нужна только для отладки и вам повезло работать в условиях, когда просадка производительности в 2-3 раза из-за выключенной оптимизации погоды для вас не делает вообще, то вопросов больше нет.
Здравствуйте, night beast, Вы писали:
NB>в чем принципиальная разница того "пипл хавает" и обсуждаемого здесь разделения на дебаг/релиз?
Суть в том, что, сорвав одну виноградину в большом винограднике, Вы не создадите в нем заметных изменений. А если придет сто тысяч человек, и каждый сорвет по виноградине, винограда может не остаться.
Так и библиотеками: большинство совершенно не задумывается о том, что там внутри, какой ценой даются те или иные преимущества — они просто составляют нужные конструкции согласно документации. После этого нередко получается [исходный] код, о котором даже опытные программисты могут сказать, что он "оптимален", и единственная возможность его ускорения — это применение оптимизаций кодогенератора. Поэтому подавляющее большинство, от имени которого выступает so5team, рассматривает неоптимизированные сборки типа "Debug", как "плохие", "неполноценные", "негодные", а оптимизированные типа "Release" — как "нормальные", "правильные", "рабочие". А должно быть иначе: обычная, неоптимизированная сборка — "нормальная", "рабочая", "годная", а оптимизированная — "улучшенная", "продвинутая", "предельная" и т.п.
Здравствуйте, so5team, Вы писали:
S>Послушайте, ведь очевидно, что вы говорите про некий уникальный для вашего проекта define, который в зависимости от определения будет приводить либо к использованию operator[], либо к at. И что вы, в зависимости от каких-то факторов, определяете этот define при сборке либо так, либо иначе.
Да. Как и множество других.
S>Давайте перестанем играть в эту игру и перейдем к сути.
Это и есть суть.
S>Так что возвращаемся к тому, о чем говорилось: "Выбор между operator[] и at для vector вообще лежит вне деления на Debug/Release." S>И мне не понятно, что вы этому пытаетесь возразить. Как и непонятно зачем.
Верно. Оно лежит вне деления на Debug/Release, в прокрустовом ложе которого вы пытаетесь лежать.
Оно является всего лишь одним из параметров, которые можно регулировать при компиляции кода.
N>>Ну а для кого я говорил, что используем такие, которые не выключаются при (условном) релизе? S>Повторюсь: если что-то не выключается при релизе, то это не assert-ы. Ну вот определение у assert-а такое. Что уж тут поделать.
Это вам так кажется, потому что вы ограничили себя тем понятием, что в рамках стандартной библиотеки C.
Но если вам так нравится, можете читать любое моё упоминание assert как некоторую проверку времени компиляции или исполнения, которая будет останавливать (некоторым образом) от дальнейшего выполнения кода, в котором она находится.
N>>Ну я тут таки по делу, а не по литературе. Хотя вы можете что-нибудь сами рассказать.
S>Так в том-то и дело, что мне не вспомнаются примеры того, чтобы скорость работы кода в Debug-е имела значение. S>Тогда как у вас, можно предположить, подобные примеры имеются:
Я уже приводил. В качестве примера попроще — возьмите установку, которой надо отдавать команды вовремя, иначе что-то не куда надо уедет.
Здравствуйте, night beast, Вы писали:
NB>>>нормально, это значит устраивает большинство. NB>>>иначе бы использовалась другая модель.
N>>Это не "устраивает большинство". Это 1) инерция от древних времён (70-80-е, когда эта концепция только была придумана), 2) инерция мышления тех, кто просто не представляет себе иначе и не хочет думать о других вариантах.
NB>возможно, но на текущий момент ситуация именно такая
Где? В Visual Studio? Ну я с ней не работаю и не планирую, а мои средства имеют сильно бо́льший спектр вариантов.
N>>В IT тысячи примеров такой инерции, этот далеко не единственный. Каждый из них постепенно устраняется, но на это могут уйти десятилетия. Но размыв идёт постепенно и со стороны. Уже несколько уровней оптимизации в компиляторе — вполне источник альтернативных подходов. NB>несколько уровней оптимизации в гсс существуют уже очень давно...
Да. Но влиять на эти концепции они начали достаточно недавно, примерно с началом массовой миграции хомячков на Linux.
Здравствуйте, so5team, Вы писали:
S>стоимость возрата этих объектов будет разная. Включая и отсутствие побитного копирования в некоторых случаях.
Если Вы знаете случаи, в которых MSVC++ делает возврат по значению любых объектов без копирования, когда отключена оптимизация — поделитесь, пожалуйста, буду благодарен. Я таких случаев не нашел. Единственное исключение — это RVO, когда объект конструируется непосредственно в операторе return. Но для того, чтобы сконструировать объекта в return, необходимо инициализировать все значимые члены. ABI не позволяет в таком случае вернуть адрес объекта — только содержимое.
Разумеется, можно возвращать не само описание ошибки, а адрес объекта, его содержащего. Но тогда возникают проблемы с созданием этого объекта — я оговорил это в первых сообщениях. И снова нет никакой разницы, как это делать — хоть с шаблонами, хоть без них.
S>Если вам скорость неоптимизированного кода нужна только для отладки и вам повезло работать в условиях, когда просадка производительности в 2-3 раза из-за выключенной оптимизации погоды для вас не делает вообще, то вопросов больше нет.
Наоборот — это Вам не повезло оказаться в условиях, когда только автоматическая оптимизация кодогенерации позволяет решить поставленную задачу. Такая ситуация не является нормальной, и допустима лишь в том случае, когда программа делается для конкретной, локальной аппаратной конфигурации. Большинство же программ делается "под архитектуру", быстродействие конкретных экземпляров которой может различаться в десятки-сотни раз. Поскольку разработка традиционно ведется на конфигурациях, близких к топовым, следование Вашим традициям приведет к неработоспособности программ на бОльшей части вполне кошерного железа.
Поэтому в общем случае оптимизацию генерируемого кода следует рассматривать, как метод повышения производительности, но не как необходимое условие работоспособности программы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так и библиотеками: большинство совершенно не задумывается о том, что там внутри, какой ценой даются те или иные преимущества — они просто составляют нужные конструкции согласно документации. После этого нередко получается [исходный] код, о котором даже опытные программисты могут сказать, что он "оптимален", и единственная возможность его ускорения — это применение оптимизаций кодогенератора. Поэтому подавляющее большинство, от имени которого выступает so5team, рассматривает неоптимизированные сборки типа "Debug", как "плохие", "неполноценные", "негодные", а оптимизированные типа "Release" — как "нормальные", "правильные", "рабочие". А должно быть иначе: обычная, неоптимизированная сборка — "нормальная", "рабочая", "годная", а оптимизированная — "улучшенная", "продвинутая", "предельная" и т.п.
поправлю немного
Debug -- версия, максимально пригодная для отладки. в которой основной упор сделан на обнаружение ошибок.
Release -- версия, которая отдается клиенту. в которой упор сделан на производительность. но это не исключает использования в этой сборке отладочных символов.
нет никаких "правильная"/"неправильная". есть просто разное назначение.
и в сборке Debug критерий производительности играет не очень важную роль.
ну, по крайней мере я так воспринимаю различие в сборках.
Здравствуйте, netch80, Вы писали:
NB>>возможно, но на текущий момент ситуация именно такая
N>Где? В Visual Studio? Ну я с ней не работаю и не планирую, а мои средства имеют сильно бо́льший спектр вариантов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если Вы знаете случаи, в которых MSVC++ делает возврат по значению любых объектов без копирования, когда отключена оптимизация — поделитесь, пожалуйста, буду благодарен.
Так уж получилось, что меня не интересуют показатели производительности кода, который собирается с выключенной оптимизацией. Для чего такой код может понадобиться понять можно. Вот что сложно понять, так это кому и зачем нужна производительность в этом случае. Ну вот вам нужно, ну и ОК, чего только в жизни не бывает.
ЕМ>Наоборот — это Вам не повезло оказаться в условиях, когда только автоматическая оптимизация кодогенерации позволяет решить поставленную задачу.
Не нужно подменять понятия. Автоматическая оптимизация позволяет забесплатно избавиться от бойлерплейта, который возникает по различным причинам (обеспечение надежности, безопасности, гибкости, настраиваемости и т.д.).
ЕМ>Поэтому в общем случае оптимизацию генерируемого кода следует рассматривать, как метод повышения производительности, но не как необходимое условие работоспособности программы.
Я не делал знака равенства между "производительностью" и "работоспособностью". Более того, это что-то странное. Работоспособность должна быть априори, производительность -- это всего лишь одно из качеств работоспособного кода.
Оптимизация здесь при том (повторяюсь), что позволяет избавится от накладных расходов, связанных с обеспечением работоспособности кода (см. пример с tagged_scalar). Без оптимизации пришлось бы отказываться от ряда приемов программирования, потому что компилятор тогда бы привносил в код оверхэд и это сказывалось бы на производительность. И в таких условиях достижение работоспособности оказывалось бы дороже.
Здравствуйте, night beast, Вы писали:
NB>>>возможно, но на текущий момент ситуация именно такая
N>>Где? В Visual Studio? Ну я с ней не работаю и не планирую, а мои средства имеют сильно бо́льший спектр вариантов.
NB>не только NB>https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
Ну так
1) это только образцы — возможно больше.
2) там с ходу больше список вариантов — вы сами-то ссылку прочли?
Здравствуйте, night beast, Вы писали:
NB>нет никаких "правильная"/"неправильная". есть просто разное назначение. NB>и в сборке Debug критерий производительности играет не очень важную роль.
Ну вот у вас "не очень важную".
А so5team@ заглючило на том, что якобы вообще тут производительность не имеет значения, и не разглючивает.
да. и эти образцы используют разные библиотеки
поиск по слову _DEBUG выдал ~50 файлов из ~150 Find*
N>2) там с ходу больше список вариантов — вы сами-то ссылку прочли?
Здравствуйте, netch80, Вы писали:
NB>>нет никаких "правильная"/"неправильная". есть просто разное назначение. NB>>и в сборке Debug критерий производительности играет не очень важную роль.
N>Ну вот у вас "не очень важную". N>А so5team@ заглючило на том, что якобы вообще тут производительность не имеет значения, и не разглючивает.
ну, для меня тоже не совсем понято не желание что-то использовать только по той причине, что в дебаг режиме используемый компилятор не делает NRVO
Здравствуйте, Alexander G, Вы писали:
AG>В контексте этой темы, Guaranteed Copy Elision в C++17. AG>Это как бы обязательный RVO, и это фича компилятора, не библиотек
Безусловная (без включения режимов оптимизации кода) RVO поддерживается в MSVC++ еще с компилятора 15.00 (VS 2008). А вот безусловная NRVO не поддерживается даже в 19.21 (VS 2019).
ЕМ>При помощи множества последовательных вызовов приходится искать, например, поддерживаемые звуковые форматы — в интерфейсах не предусмотрено способа получения исчерпывающего списка хоть конкретных форматов, хоть их диапазонов. Сама система тоже делает множественные вызовы. Если устройство возвращает ошибку "не подходит" то пробуем следующую комбинацию. ЕМ>А если вдруг возвращает "устройство отключено", "отказ в доступе" и т.п., то это уже нештатная ситуация, о которой нужно сообщить именно на самый верх.
Ну, сделай два типа исключений — один для retry-able, второй — для fatal проблем.
Можно вообще на каждую проблему свое исключение, отнаследованное от тех же групп retry-able/fatal
Как много веселых ребят, и все делают велосипед...
