Производительность станд.:: голова - неудачные обращения в кэш?
Я пытался оптимизировать числовую мою программу, и столкнулся с чем-то вроде тайны. Я - цикличное выполнение по коду, который выполняет тысячи операций с плавающей точкой который 1 вызов к pow - тем не менее, тот вызов берет 5% времени... Это - не обязательно критическая проблема, но это нечетно, таким образом, я хотел бы понять то, что происходит.
Когда я представил для неудачных обращений в кэш, VS.NET 2010RC's, профилировщик сообщает, что фактически все неудачные обращения в кэш происходят в std::pow... так..., что произошло с этим? Существует ли более быстрая альтернатива? Я попробовал powf, но это незначительно быстрее; это все еще ответственно за аварийное количество неудачных обращений в кэш.
Почему основная функция хотела бы неудачные обращения в кэш причины головы?
Править: это не управляемый код. /Oi intrinsics включены, но компилятор может по своему выбору проигнорировать это. Замена pow(x,y) exp(y*log(x)) имеет подобную производительность - сейчас, все неудачные обращения в кэш находятся в функции журнала.
4 ответа
Если вы замените std :: pow (var) другой функцией, например std :: max (var, var) , все равно 5% занимает? Вы по-прежнему получаете все промахи кеша?
Я предполагаю, что нет вовремя и да по промахам кеша. Расчет мощности выполняется медленнее, чем многие другие операции (какие вы используете?). Вызов кода, которого нет в кеше, вызовет промах в кеше, независимо от того, какая это функция.
Если ваш код требует большого количества вычислений, я не удивлюсь, что std :: pow занимает 5% рабочего времени. Многие числовые операции выполняются очень быстро, поэтому немного более медленная операция, такая как std :: pow , будет занимать больше времени по сравнению с другими и без того быстрыми операциями. (Это также объясняет, почему вы не заметили значительных улучшений при переходе на std :: powf .)
Промахи в кеше несколько озадачивают, и трудно дать объяснение без дополнительных данных. Одна из возможностей заключается в том, что если ваш другой код настолько интенсивен памятью, что поглощает весь выделенный кеш, тогда не будет полностью удивительным, что std :: pow принимает на себя все удары по промахам кеша. .
Ага .. это медленно. Относительно того, почему в деталях может попытаться объяснить кто-нибудь, кто чувствует себя более уверенно.
Хотите ускорить? здесь: http://martin.ankerl.com/2007/10/04/optimized-pow-approximation-for-java-and-c-c/
Не могли бы вы дать больше информации о 'x', а также о среде, в которой оценивается pow?
То, что вы видите, может быть аппаратными программами предварительной выборки на работе. В зависимости от профилировщика распределение «стоимости» различных инструкций сборки может быть неправильным, оно должно быть еще более частым для инструкций с длительной задержкой, таких как те, которые необходимы для оценки мощности.
Кроме того, я бы использовал настоящий профилировщик, такой как VTune / PTU, чем тот, который доступен в любой версии Visual Studio.