Здравствуйте, student__, Вы писали:
__>Это ЯП для системного и околосистемного софта с реал-тайм требованиями, с вылизанными компиляторами, на которых пишут ядра ОС, и соответственно всё API документировано в терминах C, с кучей литературы и тоннами кода. Нет ни одного ЯП, который состязался бы уверенно по всем этим пунктам одновременно с С и C++.
Так это я и сам знаю, именно поэтому его и использую.
__>И чтобы разрабатывать на этих ЯП в большинстве случаев вовсе не нужно знать, передаются ли параметры через регистры или стек и прочую машинерию.
Да как сказать. Например, если Вы будете в цикле вызывать друг из друга несколько небольших функций хотя бы с 4-5 параметрами у каждой, на этой самой передаче параметров может набежать изрядный процент накладных расходов, и того же нормального реалтайма может не получиться. Конечно, в большинстве случаев спасают волшебные ключи компилятора вроде -O2, но без знания того, как именно они работают, их применение выглядит как молитва "дорогой компилятор, сделай мне зашибись". Для чистого прикладника простительно, но ему и C++ особо без надобности. А для системщика слепо уповать на компилятор — стремно, ведет к деградации профессии.
Я тут уже как-то рассказывал, как у меня полностью исправный ядерный драйвер под виндой вдруг начал, будучи скомпилирован в отладочном режиме, периодически валить систему с переполнением стека, причем не в самом драйвере, а где попало. Я попервости не мог понять, в чем дело, а потом присмотрелся к использованию стека в коде драйвера, и ужаснулся — в отладочном режиме компилятор выделяет в стеке отдельную область под каждый временный объект, даже если их области существования не перекрываются. Поскольку как раз в отладочном режиме временные объекты использовались очень активно, стек все время был на пределе, и периодически какое-нибудь прерывание приводило к его переполнению. А не умел бы анализировать порожденный код и разбираться в особенностях выделения памяти на стеке — неизвестно, сколько времени потратил бы на выяснение причин.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Компилируемые в нативный код языки (будь то Си, Паскаль, Модула-2, Ada, C++ или Rust) хороши как раз тем, что нормально написанный на них код быстро работает даже если программист вообще понятия не имеет о наборе команд архитектуры, под которую код собирается.
ЕМ>Фишка в том, что перечисленные языки "быстро работают" лишь в том смысле, что они "явно не тормозят" и не требуют "чрезмерного объема памяти".
Евгений, а вы после стольких лет работы еще не поняли, что зачастую это именно то, что нужно?
ЕМ>Но среди них лишь C/C++ имеют качественные отличия, остальные различаются лишь количественно.
С этого места поподробнее, пожалуйста.
ЕМ>Иначе говоря, если нечто реализовано на любом из перечисленных (и многих других) языков, то это гарантированно можно реализовать на C/C++. А вот многое из реализованного на C/C++ невозможно переделать на других языках
Что именно?
ЕМ>не создав собственной реализации под конкретную платформу — даже если какие-то реализации для нее уже есть.
А вы точно сейчас не бредите? Или вы опять про нишу драйверов для ОС Windows?
ЕМ>Именно в этом смысле я и говорил
Смысла в ваших словах пока не видно
ЕМ>Я ж делал софт не только для ядра и голого железа.
И что же вы делали? CAD? СУБД? MQ-шный брокер? mail-сервер? Распределенные тяжелые вычисления?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я тут уже как-то рассказывал, как у меня полностью исправный ядерный драйвер под виндой вдруг начал, будучи скомпилирован в отладочном режиме, периодически валить систему с переполнением стека, причем не в самом драйвере, а где попало. Я попервости не мог понять, в чем дело, а потом присмотрелся к использованию стека в коде драйвера, и ужаснулся — в отладочном режиме компилятор выделяет в стеке отдельную область под каждый временный объект, даже если их области существования не перекрываются. Поскольку как раз в отладочном режиме временные объекты использовались очень активно, стек все время был на пределе, и периодически какое-нибудь прерывание приводило к его переполнению. А не умел бы анализировать порожденный код и разбираться в особенностях выделения памяти на стеке — неизвестно, сколько времени потратил бы на выяснение причин.
В DEBUG-сборках вообще много интересного может происходить. Начиная от каких-то проверок, которые вставляет компилятор, завершая дополнительными действиями, выполняемыми в отладочной версии стандартной библиотеки (типа принудительного заполнения освобождаемой памяти специальными значениями).
Так что ваша история по фееричности даже круче, чем попытки профилировать код, собранный в DEBUG-режиме.
Здравствуйте, so5team, Вы писали:
ЕМ>>перечисленные языки "быстро работают" лишь в том смысле, что они "явно не тормозят" и не требуют "чрезмерного объема памяти".
S>еще не поняли, что зачастую это именно то, что нужно?
Так само-то по себе это всегда было понятно. Главное, чтоб это было понятно тем, кто умеет отличать "не тормозит прямо сейчас на общих тестах" от "не будет тормозить потом, когда вложимся в разработку софта". Без этого понимания даже на голом C делают совершенно ужасный софт.
ЕМ>>Но среди них лишь C/C++ имеют качественные отличия, остальные различаются лишь количественно. S>С этого места поподробнее, пожалуйста.
.
ЕМ>>многое из реализованного на C/C++ невозможно переделать на других языках, не создав собственной реализации под конкретную платформу
S>Что именно?
Например, прошивки для микроконтроллеров с памятью на единицы килобайт кода.
S>Или вы опять про нишу драйверов для ОС Windows?
Про нишу любых программ, где почти любые готовые абстракции только мешают. Кстати, иные драйверы, независимо от ОС, написаны на C/C++ настолько коряво, что их можно было писать хоть на питоне, сгородив под него ту самую реализацию под ядро.
S>И что же вы делали? CAD? СУБД? MQ-шный брокер? mail-сервер? Распределенные тяжелые вычисления?
СУБД я как-то делал на ассемблере, еще до перехода на C. А на одном из виндовых драйверов некоторые заказчики успешно гоняют по нескольку тысяч звуковых потоков в реальном времени на вполне ординарном железе — в этом есть немножко и от распределенных вычислений.
Здравствуйте, so5team, Вы писали:
S>В DEBUG-сборках вообще много интересного может происходить. Начиная от каких-то проверок, которые вставляет компилятор, завершая дополнительными действиями, выполняемыми в отладочной версии стандартной библиотеки (типа принудительного заполнения освобождаемой памяти специальными значениями).
Для всего этого у меня своя поддержка, ибо MS не удосужились сделать ее под ядро.
S>Так что ваша история по фееричности даже круче, чем попытки профилировать код, собранный в DEBUG-режиме.
И чем она круче? Алгоритм распределения стековой памяти под области действия вполне примитивен, это как укладывать поля в сишное объединение. Когда я спрашивал у MS, отчего они используют столь тупые алгоритмы, они ответили что-то вроде "для удобства отладки". Смысла этого я так и не понял, поскольку отладчик сам их не видит — нужно руками найти адрес, и руками же вбить его с нужным типом. Если это они называют "удобством отладки", то у них весьма странные представления об удобствах...
Здравствуйте, Евгений Музыченко, Вы писали:
S>>попытки профилировать код, собранный в DEBUG-режиме.
ЕМ>Забыл добавить: Вы категорически против профилирования такого кода?
Ну почему категорически. Должно помогать при депрессиях, наверное.
Здравствуйте, rg45, Вы писали:
S>>>попытки профилировать код, собранный в DEBUG-режиме.
ЕМ>>Забыл добавить: Вы категорически против профилирования такого кода?
R>Ну почему категорически. Должно помогать при депрессиях, наверное.
А как весьма полезный, иногда даже необходимый в серьезной разработке метод?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так само-то по себе это всегда было понятно. Главное, чтоб это было понятно тем, кто умеет отличать "не тормозит прямо сейчас на общих тестах" от "не будет тормозить потом, когда вложимся в разработку софта".
Э... Тут я в очередной раз в ступоре. Разработку софта начинают когда есть конкретные требования, в том числе и по производительности. В процессе разработки эти требования стараются удовлетворить. В огромном количестве случаев при использовании языков из категории C/C++/Ada/Modula-2/Rust должной производительности удается достичь даже не опускаясь на уровень ассемблера.
Вы, вероятно, в какой-то специфической среде работаете.
ЕМ>>>Но среди них лишь C/C++ имеют качественные отличия, остальные различаются лишь количественно. S>>С этого места поподробнее, пожалуйста.
ЕМ>В общих чертах описывал тут
Основная специфика C/C++ — это прозрачная кодогенерация и отсутствие обязательной языковой среды. Почти все конструкции языка (кроме того, что связано с исключениями, и еще кое-чего по мелочи) порождают код, который не имеет внешних зависимостей ни по библиотекам, ни по исполняющей системе. Почти во всех случаях внешние ссылки порождаются явно. Код, не содержащий таких ссылок, почти всегда можно перенести в другой контекст, и он будет там нормально работать. Во всех остальных ЯВУ схожей функциональности подразумевается наличие этой самой среды, и обособить от нее код гораздо сложнее.
А вы точно уверены, что Modula-2, Ada и Rust как-то принципиально в этом смысле от C++ отличаются?
Точно-точно?
ЕМ>>>многое из реализованного на C/C++ невозможно переделать на других языках, не создав собственной реализации под конкретную платформу
S>>Что именно?
ЕМ>Например, прошивки для микроконтроллеров с памятью на единицы килобайт кода.
Вроде бы Modula-2 и Ada в свое время вполне позволяли такое делать. Ada, полагаю, и сейчас должна позволять.
Даже JavaME на JavaCard-ах работала в 16KiB.
S>>Или вы опять про нишу драйверов для ОС Windows?
ЕМ>Про нишу любых программ, где почти любые готовые абстракции только мешают.
А конкретнее? Что-то даже "тяжелый" embedded, который на Linux-ах с несколькими мегабайтами на борту, на эту нишу не тянет.
S>>И что же вы делали? CAD? СУБД? MQ-шный брокер? mail-сервер? Распределенные тяжелые вычисления?
ЕМ>СУБД я как-то делал на ассемблере, еще до перехода на C. А на одном из виндовых драйверов некоторые заказчики успешно гоняют по нескольку тысяч звуковых потоков в реальном времени на вполне ординарном железе — в этом есть немножко и от распределенных вычислений.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>В DEBUG-сборках вообще много интересного может происходить. Начиная от каких-то проверок, которые вставляет компилятор, завершая дополнительными действиями, выполняемыми в отладочной версии стандартной библиотеки (типа принудительного заполнения освобождаемой памяти специальными значениями).
ЕМ>Для всего этого у меня своя поддержка, ибо MS не удосужились сделать ее под ядро.
Так в стандарте C++ пока вообще нет понятия free-standing версии C++ и C++ной стандартной библиотеки.
S>>Так что ваша история по фееричности даже круче, чем попытки профилировать код, собранный в DEBUG-режиме.
ЕМ>И чем она круче?
Уровнем маразма. Пардон май френч.
ЕМ>Смысла этого я так и не понял, поскольку отладчик сам их не видит — нужно руками найти адрес, и руками же вбить его с нужным типом. Если это они называют "удобством отладки", то у них весьма странные представления об удобствах...
Смысл, например, в том, что если вставлять дополнительное место между стековыми переменными, да еще заполнять это место специальными значениями, то всякие out-of-bound ошибки ловить проще.
Здравствуйте, rg45, Вы писали:
R>А в чем его полезность?
Когда делается достаточно жесткий реалтайм, вообще полезно заставить его стабильно работать на отладочном коде — это показывает, что есть запас по производительности и, скорее всего, оптимизированный код будет стабильно работать и на более слабом железе.
Ну и во время отладки такого кода весьма полезно держать включенными всяческие встроенные проверки, assert'ы, отладочные логи, а если падает спонтанно и трудновоспроизводимо, то по отладочному дампу куда приятнее лазить отладчиком, нежели по релизному.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда делается достаточно жесткий реалтайм, вообще полезно заставить его стабильно работать на отладочном коде — это показывает, что есть запас по производительности и, скорее всего, оптимизированный код будет стабильно работать и на более слабом железе.
Как я это понимаю. Главная цель профилирования — это выявление критических участков программы с целью последующей оптимизации. Попытки собирать эту информацию в отладочной конфигурации при выключенных оптимизациях достаточно наивны, как по мне.
ЕМ>Ну и во время отладки такого кода весьма полезно держать включенными всяческие встроенные проверки, assert'ы, отладочные логи, а если падает спонтанно и трудновоспроизводимо, то по отладочному дампу куда приятнее лазить отладчиком, нежели по релизному.
Безусловно, все перечисленное полезно, только при чем тут профилирование? Похоже, мы как-то по-разному понимаем этот термин.
Здравствуйте, so5team, Вы писали:
S>Разработку софта начинают когда есть конкретные требования, в том числе и по производительности.
Как именно эти требования выглядят в типичном современном прикладном проекте софта для рядового пользователя — каком-нибудь мобильном приложении банка или службы, программе-каталогизаторе фотографий, программе наложения эффектов на изображение/видео? Там точно есть какие-то численные показатели, или только "должно запускаться на Android 11 и Windows 10"?
S>В огромном количестве случаев при использовании языков из категории C/C++/Ada/Modula-2/Rust должной производительности удается достичь
Проблема в том, что там, где из-за тормозов или переполнения памяти ничего не взорвется, не заклинит на ходу и т.п., под "должной производительностью" обычно понимается "пользователи топового железа не слишком часто жалуются на откровенные тормоза". И такое сплошь и рядом даже в C/C++ — достаточно где-нибудь на относительно низком уровне халтурно сделать работу со строками или списками, а затем навесить на это еще несколько уровней сверху. Тот софт, что десятки-сотни тысячи раз читает из файлов одни и те же данные, на чем написан?
S>А вы точно уверены, что Modula-2, Ada и Rust как-то принципиально в этом смысле от C++ отличаются?
Конечно. В первую очередь, в них нет родной привязки к машинным типам данных (байт, часть слова, составное слово и т.п.). Чтобы делать на них машинно-зависимый код, придется либо вводить расширения языка, либо добавлять костыли вроде внешних процедур/функций ReadByte/WriteByte, которые будут отъедать объем и скорость.
Еще в Modula-2 и Ada, насколько я помню, нет указателей на процедуры/функции. Любую диспетчеризацию придется делать через перебор по ключу.
ЕМ>>Например, прошивки для микроконтроллеров с памятью на единицы килобайт кода.
S>Вроде бы Modula-2 и Ada в свое время вполне позволяли такое делать. Ada, полагаю, и сейчас должна позволять.
Хм, кто и с какой целью делал эти реализации? Разве что в качестве демонстрации принципиальной возможности?
S>Даже JavaME на JavaCard-ах работала в 16KiB.
16 KiB — это уже достаточно много, некоторые ранние машины имели такую память. Я говорю про единицы килобайт — это 1-2-4. Обычно для таких МК пишут на голом C, но вся хохма в том, что аналогичный код на C++ порой совпадает до байта, если компилятор один и тот же (например, gcc).
S>даже "тяжелый" embedded, который на Linux-ах с несколькими мегабайтами на борту, на эту нишу не тянет.
Под эти-то можно свободно писать хоть на лиспе или коболе, там вообще никаких проблем нет. Разве что ядро/драйверы сделать на C/C++ для вящей эффективности.
S>>>И что же вы делали? CAD? СУБД? MQ-шный брокер? mail-сервер? Распределенные тяжелые вычисления?
ЕМ>>СУБД я как-то делал на ассемблере, еще до перехода на C. А на одном из виндовых драйверов некоторые заказчики успешно гоняют по нескольку тысяч звуковых потоков в реальном времени на вполне ординарном железе — в этом есть немножко и от распределенных вычислений.
S>Ясно, понятно
Здравствуйте, rg45, Вы писали:
R>Главная цель профилирования — это выявление критических участков программы с целью последующей оптимизации. Попытки собирать эту информацию в отладочной конфигурации при выключенных оптимизациях достаточно наивны, как по мне.
С чего бы вдруг? Если код не написан настолько топорно, что многоуровневые циклы при оптимизации сворачиваются в линейную формулу, из часто вызываемых мелких функций не выбрасываются развесистые записи в лог, или что-нибудь вроде этого, то включение оптимизации не ускоряет код на порядки, и в основном соотношение затрат между разными частями кода остается примерно таким же. А если отладочный режим еще и управляется не по "да-нет", а хотя бы по нескольким основным параметрам (проверки типов/индексов, проверки инвариантов, проверки целостности объектов, подробность лога и т.п.), то и вовсе нет проблем.
R>Безусловно, все перечисленное полезно, только при чем тут профилирование?
Я ж объяснил про реальное время. Вот переделал я, например, алгоритм смешивания звуковых потоков, и на отладочном коде он стал похрюкивать, если потоков больше пяти. На релизном-то тянет и два десятка, но ведь и на отладочном раньше тянул хотя бы десять. Профилирование позволяет увидеть, как изменилось распределение затрат.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да как сказать. Например, если Вы будете в цикле вызывать друг из друга несколько небольших функций хотя бы с 4-5 параметрами у каждой, на этой самой передаче параметров может набежать изрядный процент накладных расходов, и того же нормального реалтайма может не получиться. Конечно, в большинстве случаев спасают волшебные ключи компилятора вроде -O2, но без знания того, как именно они работают, их применение выглядит как молитва "дорогой компилятор, сделай мне зашибись".
Вы просто повторили мою мысль: в большинстве случаев, в какие команды что компилируется знать не надо (обозначу это X, чтобы не повторяться).
"Нормальный реалтайм" — это нонсенс. Есть soft, firm, hard реалтайм, и внутри каждого свои требования.
И во многих хард реалтаймах, если дедлайн соблюдается, пофиг, сколько там циклов и параметров.
ЕМ>Для чистого прикладника простительно, но ему и C++ особо без надобности. А для системщика слепо уповать на компилятор — стремно, ведет к деградации профессии.
Нет, C++ нужен, по причинам, которые я уже назвал. А деградации профессии не будет, потому что решаемые задачи не требуют Х.
ЕМ>Я тут уже как-то рассказывал, как у меня полностью исправный ядерный драйвер под виндой вдруг начал
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С чего бы вдруг? Если код не написан настолько топорно, что многоуровневые циклы при оптимизации сворачиваются в линейную формулу, из часто вызываемых мелких функций не выбрасываются развесистые записи в лог, или что-нибудь вроде этого, то включение оптимизации не ускоряет код на порядки, и в основном соотношение затрат между разными частями кода остается примерно таким же. А если отладочный режим еще и управляется не по "да-нет", а хотя бы по нескольким основным параметрам (проверки типов/индексов, проверки инвариантов, проверки целостности объектов, подробность лога и т.п.), то и вовсе нет проблем.
Ты никогда не сталкивался с тем, что картинка в профиляторе может разительно изменяться при переключении между дебагом и релизом?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Разработку софта начинают когда есть конкретные требования, в том числе и по производительности.
ЕМ>Как именно эти требования выглядят в типичном современном прикладном проекте софта для рядового пользователя — каком-нибудь мобильном приложении банка или службы, программе-каталогизаторе фотографий, программе наложения эффектов на изображение/видео? Там точно есть какие-то численные показатели, или только "должно запускаться на Android 11 и Windows 10"?
ХЗ, я без понятия что такое "типичный современный прикладной проект". А вы, уверен, понимаете в этом еще меньше.
Из последнего:
— есть конкретное железо на котором крутится софт X и обеспечивает Y rps, нужно на этом же железе обеспечить, минимум, 2xY rps;
— есть конкретное железо, есть софт от вендора B, некий датасет этот софт на этом железе обрабатывает на ~N секунд. Нужно обеспечить такую же производительность на этом же железе на этом же датасете.
S>>В огромном количестве случаев при использовании языков из категории C/C++/Ada/Modula-2/Rust должной производительности удается достичь
ЕМ>Проблема в том, что
что вы беретесь рассуждать на темы, о которых не разбираетесь.
S>>А вы точно уверены, что Modula-2, Ada и Rust как-то принципиально в этом смысле от C++ отличаются?
ЕМ>Конечно. В первую очередь, в них нет родной привязки к машинным типам данных (байт, часть слова, составное слово и т.п.). Чтобы делать на них машинно-зависимый код, придется либо вводить расширения языка, либо добавлять костыли вроде внешних процедур/функций ReadByte/WriteByte, которые будут отъедать объем и скорость.
Удивительно, и как же на Ada разрабатывают mission critical софт, да еще и в embedded-е...
Может быть потому, что Ada допускает расширения для конкретных реализаций:
An implementation may provide additional predefined signed integer types, declared in the visible part of Standard, whose first subtypes have names of the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer, etc. Different predefined integer types are allowed to have the same base range. However, the range of Integer should be no wider than that of Long_Integer. Similarly, the range of Short_Integer (if provided) should be no wider than Integer. Corresponding recommendations apply to any other predefined integer types. There need not be a named integer type corresponding to each distinct base range supported by an implementation. The range of each first subtype should be the base range of its type.
An implementation may provide nonstandard integer types, descendants of root_integer that are declared outside of the specification of package Standard, which need not have all the standard characteristics of a type defined by an integer_type_definition. For example, a nonstandard integer type might have an asymmetric base range or it might not be allowed as an array or loop index (a very long integer). Any type descended from a nonstandard integer type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for “any integer type” are defined for a particular nonstandard integer type. In any case, such types are not permitted as explicit_generic_actual_parameters for formal scalar types — see 12.5.2.
S>>Вроде бы Modula-2 и Ada в свое время вполне позволяли такое делать. Ada, полагаю, и сейчас должна позволять.
ЕМ>Хм, кто и с какой целью делал эти реализации? Разве что в качестве демонстрации принципиальной возможности?
Поставщики средств разработки на той же самой Ada. Просто потому, что Ada создавалась как универсальный язык для разработки софта для военных. И долгое время был единственным языком, разрешенным для использования в аэро- и космической отрасли. Причем для широкого спектра задач, от embedded до "десктопа". Тот же C++ туда только в конце 1990-х допустили, емнип.
S>>Даже JavaME на JavaCard-ах работала в 16KiB.
ЕМ>16 KiB — это уже достаточно много
Так блин, там же Java (Java, Карл!) в 16KiB ворочалась. Да, это не та Java, которая JavaSE, но все-таки и не Си.
ЕМ>Я говорю про единицы килобайт — это 1-2-4. Обычно для таких МК пишут на голом C, но вся хохма в том, что аналогичный код на C++ порой совпадает до байта, если компилятор один и тот же (например, gcc).
А вы в курсе, что в этом случае вы имеете дело с нестандартным C++, т.к. пока что нет для C++ такой штуки, как free standing?
S>>даже "тяжелый" embedded, который на Linux-ах с несколькими мегабайтами на борту, на эту нишу не тянет.
ЕМ>Под эти-то можно свободно писать хоть на лиспе или коболе, там вообще никаких проблем нет.
Пилять. Я очень надеюсь, что вы это в нетрезвом виде пишете. Ибо если в здравом уме и трезвой памяти, то ваша тупость просто поражает воображение.
S>>Ясно, понятно
ЕМ>Если не секрет, то что именно "ясно, понятно"?
Что вы не имели дела с C++ными проектами хотя бы от 500KLOC и хотя бы от 10 человек. Поэтому вы не осознаете зачем и где нужны все те ругаемые вами фичи C++.
ЕМ>Конечно. В первую очередь, в них нет родной привязки к машинным типам данных (байт, часть слова, составное слово и т.п.). Чтобы делать на них машинно-зависимый код, придется либо вводить расширения языка, либо добавлять костыли вроде внешних процедур/функций ReadByte/WriteByte, которые будут отъедать объем и скорость.
ЕМ>Еще в Modula-2 и Ada, насколько я помню, нет указателей на процедуры/функции. Любую диспетчеризацию придется делать через перебор по ключу.
Для такого мракобесия нужна оценка фейспалм.
Тот случай, когда взрослый человек пишет пургу в стиле "только езык си позволяит обротиться нопримую к жылезу1111", достойную кульных какиров из 9Б.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С чего бы вдруг? Если код не написан настолько топорно, что многоуровневые циклы при оптимизации сворачиваются в линейную формулу, из часто вызываемых мелких функций не выбрасываются развесистые записи в лог, или что-нибудь вроде этого, то включение оптимизации не ускоряет код на порядки, и в основном соотношение затрат между разными частями кода остается примерно таким же.
Вот тут как раз все наоборот. Хорошая оптимизируемость — это как раз свойство и показатель добротного хорошо структурированного кода. А плохо поддается оптимизации обычно спагеттиобразный говнокод с размазанной нечеткой логикой, пронизанный нездоровыми паразитными зависимостями и побочными эффектами. Такой код обычно получается у чайников, склонных к преждевременной оптимизации. Такой код плохо покрывается тестами и труден в сопровождении. Этот же код обычно является рассадником багов и UB.
Для чистого прикладника простительно, но ему и C++ особо без надобности. А для системщика слепо уповать на компилятор — стремно, ведет к деградации профессии.
