Наиболее удобный целочисленный тип для процессора - PullRequest
0 голосов
/ 02 февраля 2012

Согласно тому, что я слышал, целочисленные значения , которые не являются размером слова процессора , будут повышаться при их изменении (используя +, -,&, так далее).Тип long должен соответствовать размеру слова.На моем компиляторе int это 32-бит и long 64-бит .

Означает ли это, что long на более эффективен , чем int, несмотря на то, что требует больше памяти?

Еще одна вещь, составные операторы продвигать ценности?А как насчет операторов приращения и декремента ?

Ответы [ 4 ]

2 голосов
/ 02 февраля 2012

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

Язык гарантирует, что результат операций будет правильным, и компилятор выберет наиболее эффективный путь к этому результату, что онмогу найти.Это может включать изменение целочисленных размеров на каком-то этапе или нет.

Процессор может выполнять свои собственные внутренние преобразования.Опять без изменения результата.Опять же, это не в ваших руках.

1 голос
/ 02 февраля 2012

В принципе, обычный int должен быть "быстрым, обычным целым числом использования", тогда как long, если он отличается, может означать "расширенный диапазон, но может быть медленнее".

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

На нескольких микроконтроллерах, которые я использовал, int - 16-битный, long - 32-битный, и операции с long требуют более одного инструкций процессора. На «классическом» 32-битном x86 long и int обычно одинаковы, поэтому разницы нет вообще. На x86_64, в зависимости от проблем переносимости, long может быть 32 или 64 бит; что касается «количества команд для выполнения операции», они одинаковы, но увеличенный размер может иметь значение, если вам нужно читать / хранить большие массивы целых чисел в памяти (32-битные целые могут работать лучше, потому что больше помещается в кэш) (и вероятно, есть много соображений, которые вы могли бы сделать, оптимизация часто бывает нелогичной, , особенно на x86).

Итак, короткая история: не задумывайтесь над этой проблемой, если вам нужно "нормальное" целое число, которое гарантированно будет работать быстро и его диапазон в порядке для вашего приложения, просто используйте int. Если вам нужен минимальный гарантированный размер, посмотрите на typedef с <stdint.h> (который, кроме того, что дает целые числа точного размера, обеспечивает также «самое быстрое целое с этим минимальным размером»).

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

1 голос
/ 02 февраля 2012

Будет сложно дать вам прямой ответ.Лучшее, что вы можете сделать в этом случае, - это профилировать и убедиться сами.

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

Я также слышал, что быстрее получить if (int), чем if (bool), потому что bool повысится до int (противинтуитивно, я знаю), но никто не объявляет int вместо bool только ради производительности.(если, может быть, после профилирования)

0 голосов
/ 02 февраля 2012

Значит ли это, что long более эффективен, чем int, несмотря на то, что требует больше памяти?

Это полностью зависит от вашего компьютера.Не существует ни одного совершенного целочисленного типа, который был бы универсально оптимальным.Если это имеет решающее значение для производительности, вам нужно проверить с помощью какого-либо инструмента анализа.Если это не критично для производительности, вам все равно.

...