Действительно ли в современном программировании есть такая вещь, как символ или шорт?

Question

За последние несколько месяцев я учился программировать для Mac (у меня есть опыт работы на других языках). Очевидно, это означало изучение языка Objective C и, следовательно, более простого языка C, на котором он основан. Итак, у меня возникла ошибка в этой цитате, которая относится к языку C / C ++ в целом, а не только к платформе Mac.

С C и C ++ предпочитают использовать int, а не чар и короткие Основная причина позади это то, что C и C ++ выполняют арифметические операции и параметр прохождение на целочисленном уровне, если у вас есть целочисленное значение, которое может вписаться в байт, вы все равно должны рассмотреть возможность использования int для хранения номера. Если вы используете char, компилятор будет первым преобразовать значения в целое число, выполнить операции, а затем преобразовать результат в char.

Итак, мой вопрос, так ли это в средах Mac Desktop и IPhone OS? Я понимаю, что когда речь идет об этих средах, мы на самом деле говорим о 3-4 разных архитектурах (PPC, i386, Arm и вариант A4 Arm), поэтому, возможно, не будет единого ответа.

Тем не менее, общий принцип гласит, что в современных 32-битных / 64-битных системах использование 1-2-байтовых переменных, которые не соответствуют естественным 4-байтовым словам машины, не обеспечивает ожидаемой эффективности. *

Например, обычный старый C-массив из 100 000 символов меньше, чем те же 100 000 целых чисел, в четыре раза, но если при перечислении при считывании каждого индекса происходит приведение / упаковка / распаковка, мы увидеть общее снижение «производительности», несмотря на экономию памяти?

Answer 1

Процессор очень очень быстрый по сравнению со скоростью памяти. Всегда будет полезно хранить значения в памяти в виде символов или шортов (хотя во избежание проблем с портированием следует использовать int8_t и int16_t). Будет использовано меньше кеша и будет меньше обращений к памяти.

Answer 2

Не могу говорить о PPC / Arm / A4Arm, но x86 может работать с данными, как если бы они были 8-битными, 16-битными или 32-битными (64-битными, если x86_64 в 64-битном режиме), хотя я не уверен компилятор воспользуется этими инструкциями. Даже при использовании 32-битной загрузки компилятор мог И данные с маской, которая очищала бы верхние 16/24-битные, что было бы относительно быстро.

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

Answer 3

Конечно, необходимо использовать структуры данных меньше, чем размер регистра целевой машины. Представьте, что вы храните текстовые данные, закодированные как UTF-8 или ASCII, в памяти, где каждый символ в основном имеет размер в байтах. Вы хотите хранить символы в 64-битных количествах?

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

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

Answer 4

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

C и ассемблер являются общими языками для них.

В 2008 году было произведено около десяти миллиардов процессоров. Около 98% новых процессоров, выпускаемых каждый год, являются встроенными.

Answer 5

Модель адресации архитектуры x86 заключается в том, что базовая единица памяти составляет 8 битных байтов.

Это упрощает работу со строками символов и десятичной арифметикой.

Затем, чтобы иметь полезные размеры целых чисел, набор команд позволяет использовать их в единицах 1, 2, 4 и (недавно) 8 байтов.