Существует ли различие с точки зрения производительности между “неподписанным интервалом” и “интервалом” на iPhone?

ARM является 32-разрядной архитектурой, таким образом, 32-разрядные целые числа являются самыми быстрыми. Однако 16-разрядные целые числа и 8-разрядные целые числа незначительно медленнее. Подписанный по сравнению с неподписанным не имеет значения очень кроме особых обстоятельств (как отмечено другими ответами здесь). 64-разрядные целые числа будут эмулированы двумя или больше 32-разрядными операциями, поэтому медленнее.

Когда дело доходит до типов с плавающей точкой, в процессоре iPhone (ARM11 с аппаратной плавающей точкой VFP), 32-разрядные плавания несколько быстрее, чем 64-разрядный, удваивается.

Стандарт C99 позволяет Вам отвечать на свой общий вопрос; самый быстрый тип в целевой системе, которая является выше особой, необходимой ширины, определяется в stdint.h. Предположите, что мне нужно, по крайней мере, целое число 8 битов шириной:

#include <stdio.h>
#include <stdint.h>

int main (int argc, char **argv)
{
    uint_fast8_t i;
    printf("Width of uint_fast8_t is %d\n", sizeof(i));
    return 0;
}

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

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

---

Править: это верно, что поведение переполнения со знаком не определено и что компиляторы могут (и в наше время сделайте), используйте это для оптимизации, как указано Hrvoje Prgeša в его ответе и @martinkunev в его комментарии.

Мне любопытно в ответе Nils, таким образом, эти вопросы направлены на него. Это не ответ на исходный вопрос.

В этом цикле компилятор должен удостовериться, что цикл даже завершается, если сначала больше, чем последний, потому что я перенесусь от UINT_MAX до 0 на переполнении

  for (i=first; i!=last; i++)
  {
     // do something here...
  }

Я не думаю, что это делает. Компилятор только должен проверить это i!=last в начале каждого повторения цикла:

i=first;
if (i == last) goto END;
START:
// do sth
++i;
if (i != last) goto START;
END:

Signess переменных не изменит код, таким образом, пример будет неправильным, по-моему. Я даже скомпилировал код с msvc08/release и сравнил ассемблерные результаты - в основном то же (за исключением типов перехода) во всем signed/unsiged и! = / <комбинации.

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

Я могу думать только о "плохом" примере:

signed i, j, k;
if (i > k)
{
  i += j;
  if (i > k)
  {
  }
}

i+= j мог переполниться, но подписался, переполнение не определено в C, таким образом, что-либо идет. Две вещи могли бы произойти:

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

Как я сказал, я уверен, что существует законная оптимизация, возможная, как Nils указывает, но отправленный цикл не среди них насколько я могу сказать.

Что касается исходного вопроса:

• используйте определение типа
• тест :)