Производительность операторов C++

Лучший ответ - синхронизировать время с вашим компилятором.

Вы спрашиваете: какие основные операции преобразуются в какие инструкции сборки и какова производительность этих инструкций в моей конкретной архитектуре. И это также ваш ответ: код, в который они переводятся, зависит от вашего компилятора и от знания вашей архитектуры, их производительность зависит от вашей архитектуры.

Имейте в виду: в C ++ операторы могут быть перегружены для определенных пользователем типов. Они могут вести себя иначе, чем встроенные типы, и реализация перегрузки может быть нетривиальной (не просто одной инструкцией).

Edit: Подсказка для тестирования. Большинство компиляторов поддерживают вывод сгенерированного кода сборки. Параметр для gcc - -S. Если вы используете какой-либо другой компилятор, посмотрите его документацию.

Зависит от архитектуры, встроенные операторы для целочисленной арифметики переводятся непосредственно в сборку (насколько я понимаю) ++, + = 1 и + = 10000, вероятно, одинаково быстры, умножение будет зависеть на платформе перегруженные операторы будут зависеть от вас

Что касается вашего редактирования, язык ничего не говорит об архитектуре, на которой оно выполняется. Ваш вопрос зависит от платформы.

Тем не менее, обычно все фундаментальные операции с типами данных имеют однозначное соответствие сборке.

Например, x86 имеет инструкцию, которая увеличивает значение на 1, что i ++ или i + = 1 переводится в. Сложение и умножение также имеют отдельные инструкции.

С аппаратной точки зрения довольно очевидно, что сложение или умножение чисел, по крайней мере, линейно по количеству битов в числах. Поскольку аппаратное обеспечение имеет постоянное количество битов, оно равно O (1).

Обычно числа с плавающей запятой имеют свой собственный процессор, который также имеет отдельные инструкции для операций.

---

Имеет ли значение?

Почему бы не написать код, который делает то, что вам нужно. Если вы хотите добавить его, используйте ++. Если вы хотите добавить большое число, добавьте большое число. Если вам нужны поплавки, используйте поплавки. Если вам нужно умножить два числа, затем умножьте их.

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

После того, как вы написали рабочий код и решили, что он слишком медленный, профилируйте его и выясните, почему. Вы обнаружите, что это не такие глупые вещи, как умножение и сложение, а скорее неправильное решение всей (под) проблемы.

Практически все перечисленные вами операторы в любом случае будут выполняться в одной инструкции ЦП, на настольных платформах.

Если вам нужно умножить два числа, затем умножьте их.

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

После того, как вы написали рабочий код и решили, что он слишком медленный, профилируйте его и выясните, почему. Вы обнаружите, что это не такие глупые вещи, как умножение и сложение, а скорее неправильное решение всей (под) проблемы.

Практически все перечисленные вами операторы в любом случае будут выполняться в одной инструкции ЦП, на настольных платформах.

Если вам нужно умножить два числа, затем умножьте их.

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

После того, как вы написали рабочий код и решили, что он слишком медленный, профилируйте его и выясните, почему. Вы обнаружите, что это не такие глупые вещи, как умножение или сложение, а скорее неправильное решение всей (под) проблемы.

На практике все перечисленные вами операторы в любом случае будут выполняться в одной инструкции ЦП, на настольных платформах.

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

Практически все перечисленные вами операторы в любом случае будут выполняться в одной инструкции ЦП, на настольных платформах.

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

Практически все перечисленные вами операторы в любом случае будут выполняться в одной инструкции ЦП, на настольных платформах.

Проблемы с производительностью, вызванные операторами C ++, происходят не от операторов, а не от их реализации. Это происходит из-за синтаксиса, из-за того, что скрытый код запускается без вашего ведома.

Лучший пример - это реализация быстрой сортировки для объекта, в котором реализован оператор [], но внутренне он использует связанный список. Теперь вместо O (nlogn) [1] вы получите O (n ^ 2logn) [2].

Проблема с производительностью в том, что вы не можете точно знать, каким будет ваш код в конечном итоге.

[1] Я знаю, что быстрая сортировка на самом деле O (n ^ 2), но она редко доходит до этого, среднее распределение даст вам O (nlogn).

[2] ... Боже ... Надеюсь, я получил математика правильно, так что вы, ребята, не голосуйте слишком много

Дональд Кнут : «Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол»

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

Краткий ответ: вы должны включить оптимизацию перед измерением.

Длинный ответ: если вы включили оптимизацию, вы выполняете операции с целыми числами, и все же вы получаете разное время для ++ i; и i + = 1; , тогда, вероятно, пора получить лучший компилятор - два оператора имеют точно такую ​​же семантику, и компетентный компилятор должен преобразовать их в та же последовательность команд.

«Имеет ли значение, если числа являются числами с плавающей запятой, а не целыми?»

-Это зависит от того, на каком процессоре вы работаете. Целочисленные операции выполняются быстрее на современных процессорах, совместимых с x86.

О i ++ и i + = 1: не должно быть разницы с любым хорошим компилятором, в то время как можно ожидать, что i + = 10000 будет немного медленнее на процессорах x86.

«*» Занимает значительно больше времени, чем «+»? »

- Обычно да.

Обратите внимание, что вы можете столкнуться со всевозможными узкими местами, и в этом случае разница в скорости между операциями не проявляется. Например. пропускная способность памяти, остановка конвейера ЦП из-за зависимостей данных и т. д.

Вот поворот в ваших оценках: попробуйте Loop Unrolling . Развертывание цикла - это повторение одних и тех же операторов в цикле, чтобы уменьшить количество итераций в цикле.

Большинство современных процессоров ненавидят инструкции перехода. У процессоров есть очередь предварительно выбранных инструкций, что ускоряет обработку. Они действительно ненавидят инструкции перехода, потому что процессор должен очистить очередь и перезагрузить ее после перехода. Это занимает больше времени, чем просто обработка последовательных инструкций.

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

Найдите руководства по оптимизации для вашего процессора. Это единственное место, где вы найдете ответы.

Заставьте ваш компилятор вывести сгенерированную сборку. Загрузите руководства для вашего процессора. Посмотрите инструкции, используемые компилятором в руководстве, и вы узнаете, как они работают.

Конечно, это предполагает, что вы уже знаете основы того, как конвейерный суперскаляр вне очереди ЦП работает, что означает предсказание ветвления, кэш инструкций и данных и все остальное. Сделайте домашнее задание.

Представление - смехотворно сложный предмет. В зависимости от контекста, код с плавающей запятой может быть таким же быстрым, как (или быстрее) целочисленного кода, или может быть в четыре раза медленнее. Обычно ветки почти не несут штрафов, но в особых случаях они могут нанести вред. Иногда, пересчет данных более эффективен, чем кэширование, а иногда и нет.

Изучите свой язык программирования. Разберитесь в своем компиляторе. Разберитесь в своем процессоре. А затем проверьте, что именно делает компилятор в вашем случае , путем профилирования / синхронизации и, при необходимости, путем изучения отдельных инструкций. (и при синхронизации кода помните обо всех предостережениях и ошибках, которые могут сделать ваши тесты недействительными: убедитесь, что оптимизации включены, но также что код, который вы пытаетесь измерить, не оптимизирован. Примите во внимание кеш ( если данные уже находятся в кеше ЦП, он будет работать намного быстрее. Если для начала потребуется чтение из физической памяти, это займет дополнительное время. И то, и другое может сделать ваши измерения недействительными, если вы не будете осторожны. Помните, что именно вы хотите измерить)

Почему для ваших конкретных примеров ++ i должно быть быстрее, чем i + = 1 ? Они делают то же самое ? Иногда может иметь значение, добавляете ли вы константу или переменную, но в этом случае вы добавляете константу в обоих случаях.

И вообще, инструкции занимают фиксированное постоянное время независимо от их операнды. добавление единицы к чему-либо занимает столько же времени, как и прибавление -2000 или 1772051912. То же самое касается умножения или деления.

Но если вы заботитесь о производительности, вам нужно понимать , как работает весь технологический стек, не просто полагайтесь на несколько простых практических правил, таких как «целое число быстрее, чем с плавающей запятой, и ++ быстрее, чем + = »