m_Slasin(0.2) - это константа, компилятор его может смело заменить на



sin(0.2) - это НЕ константа.
Вообще никто не гаратирует что вызовется именно библиотечная функция sin.
Если предоставить свою реализацию, то линкер выкинет библиотечную и свяжет с пользовательской, и вызовется именно она, и далеко не факт что она не имеет какого-то глобального состояния в рантайме.
А значит компилятор не имеет права вычислять это выражение в момент компиляции.

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

GermanVИзопропилпеределке подлежат функции, использующие общие данные процесса.

Можно подробнее? Вводится ли новая функция или заменяется старая? Как это отражается на производительности? Какой-нибудь пример есть?
Заменяются не отдельные функции, а просто проект собирается с другими ключами и другой библиотекой (где все те же функции написаны с учетом многопоточности).

Многопоточность стандартной библиотеки, по сравнению с однопоточными вариантами заключается лишь в том, что создание/удаление из нескольких потоков в куче безопасно, и там где стандартные функции использовали глобальные переменные для хранения состояния (rand, strtok...) теперь для этого используются переменные размещенные в TLS(thread local storage), т.е. своя копия у каждого потока, и соответственно потоки не влияют друг на друга, хотя состояние у функций по-прежнему есть.

Естественно что доступ к TLS вносит накладные расходы. А в зависимости от криворукости разработчиков библиотеки производительность может упасть в разы. Но часто никакого выбора нет.
Во всех современных компиляторах под win/lin используются многопоточные версии стандартных библиотек. В некоторых можно переключаться между одно- и многопоточными. Но например в VS2008 уже нет однопоточной стандартной библиотеки С/С++.

GermanVЯ просто написал все вместе, чтобы было понятно общее направление поиска: корректная работа кода / отлавливание ошибок, которые не ловит компилятор и сборщик.
Есть одна стратегия для минимизации таких ошибок (особенно у новичков без опыта) - не использовать низкоуровневые инструменты, там где доступны высокоуровневые.
Язык С++ дает достаточно возможностей для этого.
Векторы вместо массивов, смарт-указатели вместо голых указателей и т.д.
На 99% программ это никак не скажется на производительности.
А оставшийся 1% - сначала отладить, а потом профайлером выявить узкие места и оптимизировать их.

GermanVА свободно распространяемые однопоточные библиотеки есть? Ведь я могу подцепить любую библиотеку и использовать ее функции вместо поставляемых со средой. Хочется повысить производительность.
Я надеюсь вы не собрались использовать однопоточный рантайм в многопоточной программе?
Это возможно только для однопоточных программ.

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

GermanVУ меня как раз задача с расчетами на несколько суток (а может и недель). Так что STL с его серьезным падением производительности явно не подходит.

STL никак не мешает писать максимально быстрые программы.
Тормозит не STL, а алгоритм.
Например выделение вектора размером с несколько гигов ну пусть секунды займет в худшем случае.
А алгоритм ваш работает неделями.
Как это может сказаться на скорости алгоритма? Никак, если не выделять память на каждый чих.

Да и никто не мешает обращаться с тем же вектором как с массивом через указатель, а самому вектору оставить управление памятью.

Вы для начала прогоните профайлером и посмотрите что реально тормозит (и это на 99% будет ваш код, а не станд.библиотека).
А замена стандартных библиотек не поможет в любом случае.

GermanV
Ну, например, здесь: /topic/945804&pg=2&hl=stl

Вообще-то конкретно в этой теме было разобрано, что задержка в векторе возникает из-за двух факторов:
1) Медленная реализация дебаг режима в VS.
2) в момент выделения памяти для вектора она всегда инициализируется.

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

maytonНепонятно. Ты даёшь ссылку на ветку где тебя нет в качестве участника.
Так может это Poslushnik.
Ну по крайней мере религия у них одна и та же.