Считайте затем условную запись по сравнению с записью
Который является, в среднем, быстрее - проверяют значение затем, в случае необходимости, присваиваются или просто присваиваются? Или, в терминах C++:
bool b;
if(b)
b = false;
или
b = false;
Предположите, что, если () условие верно с 50%-й вероятностью. Ответ будет, наиболее вероятен, очень архитектурно-зависимый - озвучьте свои соображения низкого уровня. Запись всегда dirties строка кэша - право? Таким образом путем предотвращения записи мы избегаем очистки кэша в 0,5 случаях. Но достаточно умный кэш мог бы обнаружить тривиальную запись и не грязный саму. Но безусловная запись является всегда точно одной операцией памяти, и чтение-запись является, в среднем, 1,5 операциями.
Отказ от ответственности: это - вопрос о любопытстве, не проблема, с которой я на самом деле сталкиваюсь.
7 ответов
Ветвления дороги на современных CPU, а доступ к памяти дорог на встроенных/старых CPU. Так что плоский just-assign всегда будет быстрее, если только у вас нет какой-то странной памяти, в которую запись занимает больше времени, чем чтение (подсказка: нет)
Он хуже по следующим причинам:
- Инструкция ветвления. Это может быть предсказано процессором, но это все равно влечет за собой накладные расходы.
- 2 обращения к памяти вместо 1. Чтение и запись в большинстве видов памяти происходит с одинаковой скоростью, так зачем делать это дважды, если можно сделать это один раз?
- Больше накладных расходов кода. Это микро, но для выполнения оператора
ifнужно выпустить больше инструкций. Это означает дополнительную пару считываний памяти и больше ненужного места в кэше. - А для пессимистов это может означать, что компилятор C++ решил поместить эту переменную в регистр вместо других, более нужных переменных...
- Также, если предположить, что
bпомещается в регистр. Чтение/запись регистров очень дешевы, но они не бесплатны...
В дополнение к предложениям по профилированию, это также действительно зависит от того, какая память выполняет резервное копирование этого запроса на запись - например, если это флеш-устройство с отображением в память, запись может быть чрезвычайно дорогостоящей.
Недавно я читал статьи о методах очень быстрого сжатия, и ребята подчеркнули в них необходимость избегать ветвления , если для достижения наилучшей производительности. Причина в конвейерной обработке ЦП. Использование if нарушает многие оптимизации, которые ЦП может произвести для параллельного выполнения частей кода. Итак, если у вас было много этих операций, возможно, будет быстрее использовать b = false .
На современном конвейерном процессоре вы должны принять это во внимание:
- неверно предсказанный переход стоит дорого
- хранение и загрузка занимает много времени
- кеширование может ускорить как чтение, так и запись, но если это архитектура с множеством кешей и
bмодифицируются более чем в одном кэше, множественная запись может означать многократное вытеснение кеша и может снизить производительность кеша.
Чтение с условной записью имеет как минимум один доступ к памяти и ветвь, которая может дать неверное предсказание. Предполагая, что ветвление выполняется в 50% случаев, у вас в среднем 1,5 обращения к памяти плюс вероятность неверного прогноза.
Безусловная запись имеет ровно один доступ к памяти и не имеет никакого перехода.
Теперь вам нужно уравновесить стоимость ошибочного прогнозирования со стоимостью магазина, которая меняется в зависимости от того, сколько у вас агентов кеширования.
Если вы выполняете присвоение типа указателя, ссылки или базового значения, я лично думаю, что прямое присвоение будет быстрее (хочу увидеть результат в профилировщике). В среде с вероятностью 50% вы можете выполнить гораздо больше инструкций, которые записывают значение в регистр. Назначение объекта структуры или класса, для которого оператор присваивания триггера будет самым дорогостоящим. Условная логика также вводит больше инструкций и добавляет метрики сложности кода
Это зависит от различных вещей:
- насколько предсказуемо ответвление (в первом сценарии)
- находится ли b уже в регистре
- какую архитектуру вы используете
Определенно стоит профилировать это на разных архитектурах, чтобы получить реальную информацию. Результаты.