Trurl писал(а):
Владимир Ситников писал(а):
И?
Ну, вот мне, например, неочевидно. Не могли бы Вы привести какие-то аргументы в подтвердение тезиса?
Вот же:
viewtopic.php?f=47&t=6234&start=20#p103970Владимир Ситников писал(а):
Сравнение производительности делать стоит (чтобы убедиться, что оно не в 100500 раз медленнее простой программы на C++).
Ну и более подробно:
viewtopic.php?f=47&t=6234&start=40#p103978Ещё раз: цель сравнения не в том, чтобы узнать что круче GCC или ББ.
Цель замеров в том, чтобы понять насколько хорошо-плохо работает конкретная библиотека.
Например, мы знаем, что сложность поиска в красно-чёрном дереве составляет O(logN). По факту, в Scl реализации может быть ошибка. Поэтому логично сделать замер и посмотреть сколько работает Scl дерево. Допустим, получилось, что Scl отработало за 10 секунд. Это много? Мало?
Как понять сколько должно быть?
Как раз на подобные вопросы отвечает замер аналогичного кода в гарантированно быстрых компиляторах. Пишем простейший пример на C++/Java и получаем, например, цифру 5секунд. Если получится, что C++ работает 5 секунд, а ББ 10, то всё не так плохо. Если же окажется, что C++ работает 0.005сек, а ББ 10 секунд, то очевидно, что в ББ что-то сломано.
Для того, чтобы сравнивать нужна какая-то точка отсчёта.
За основу можно взять производительность C++ и/или Java на схожих задачах.
Теперь к вопросу "почему нужно активировать оптимизации в C++ компиляторе".
1) А почему бы тогда вообще не отключить все оптимизации в C++? Есть же опции. Можно взять и отключить все оптимизации. Давайте так сравнивать? Ну и вдобавок ББ код будем писать на ассемблере.
2) Как уже сказал Иван, часть STL кода написана именно с оглядкой на то, что оптимизирующий компилятор потом соптимизирует. Если запускать "без оптимизаций", то замер времени покажет погоду. Можно ещё и логирования понатыкать в каждой строке C++ кода, и замерять как оно будет работать.
3) Само по себе включение оптимизаций (-O3) нужно для того, чтобы можно было писать код по-простому (например, без ассемблерных вставок), и чтобы этот код потом работал быстро. Более того, как раз O3 и показывает, что многие абстракции в C++ (например, перегрузка оператора [] ) могут превращаться компилятором в прямые обращения к массиву. Т.е. по факту эта "абстракция" может быть "бесплатной" (в плане накладных расходов).
Например, при компиляции по умолчанию, обращение к перегруженному оператору [] это прямо CALL инструкция в ассемблерном коде.
Даже на уровне -O1 инструкция call пропадает, и в машинном коде используется просто обращение по адресу.
Получается, язык C++ с одной стороны допускает компактный и человекопонятный код, а с другой стороны, язык допускает эффективную компиляцию этого самого кода.
Поэтому за основу сравнения "эффективности работы" нужно именно C++ с включенными оптимизациями. Ну или Java.
Если же окажется, что ББ, например, генерирует CALL на каждый чих, то скорее повод добавить оптимизацию в ББ нежели сравниваться с "C++ без оптимизаций".