Разница в скорости между символьными и целочисленными массивами?
в настоящее время я имею дело с программным обеспечением для обработки видео, в котором данные изображения (8-битные подписанные и беззнаковые) хранятся в массивах 16-выравниваемых целых чисел, выделенных как
__declspec(align(16)) int *pData = (__declspec(align(16)) int *)_mm_malloc(width*height*sizeof(int),16);
В общем, разве это не обеспечило бы более быстрое чтение и запись, если бы использовались массивы подписанных / беззнаковых символов вроде этого ?:
__declspec(align(16)) int *pData = (__declspec(align(16)) unsigned char *)_mm_malloc(width*height*sizeof(unsigned char),16);
Я мало знаю о размере строки кэша и оптимизации передачи данных, но, по крайней мере, знаю, что это проблема. Помимо этого, в будущем будет использоваться SSE, и в этом случае массивы символов - в отличие от массивов int - уже находятся в формате упакованный. Так какая версия будет быстрее?
То, что мы думаем, на самом деле не имеет значения. Чтобы получить ответ, вам нужно запустить тест.
Обе версии будут работать с одинаковой скоростью. Это «последний» тип, который имеет значение, он по-прежнему int * и будет обрабатываться компилятором как таковой. Кроме того, во второй версии у вас могут возникнуть проблемы с переполнением буфера (вы выделили в 4 раза меньше памяти, чем в первой версии, этого достаточно?)
Я удалил тег C++ из вашего вопроса, поскольку он не имеет ничего общего с этим языком.
В данном случае я действительно ненавижу фразу "просто протестируйте это!" ответы. Да, это окончательный ответ, но он также невероятно бесполезен, если это единственный ответ, который вы можете здесь найти на вопросы скорости. Однако ответ Дарк Шикари дает гораздо больше.
Ответы 4
Напротив, упаковка и распаковка - дорогостоящие команды ЦП.
если вы хотите выполнить много случайных операций с пикселями - быстрее сделать его массивом int, чтобы каждый пиксель имел свой собственный адрес.
но если вы последовательно просматриваете свое изображение, вы хотите создать массив символов, чтобы он был маленьким по размеру и уменьшал вероятность ошибки страницы (особенно для больших изображений)
У каждого char есть свой адрес. Наполовину связанный: Может ли современное оборудование x86 не хранить в памяти ни одного байта? Ответ: да, может, люди, утверждающие, что процессоры могут выполнять только загрузку / сохранение всего слова, ошибаются.
Если вы планируете использовать SSE, хранение данных в исходном размере (8-бит) почти наверняка будет лучшим выбором, поскольку множество операций можно выполнять без распаковки, и даже если вам нужно распаковать для pmaddwd или другого подобного инструкции, это еще быстрее, потому что вам нужно загружать меньше данных.
Даже в скалярном коде загрузка 8-битных или 16-битных значений не медленнее, чем загрузка 32-битных, поскольку movzx / movsx не отличается по скорости от mov. Так что вы просто экономите память, что точно не повредит.
Это действительно зависит от вашего целевого процессора - вам следует ознакомиться с его спецификациями и выполнить несколько тестов, как все уже предлагали. Многие факторы могут повлиять на производительность. Первое очевидное, что приходит мне в голову, это то, что ваш массив int в 2-4 раза больше, чем массив символов, и, следовательно, если массив достаточно большой, вы получите меньше попаданий в кеш данных, что определенно замедлит вниз производительность.
В некоторых случаях массивы символов могут работать медленнее. Как правило, лучше всего использовать собственный размер слова, который, скорее всего, будет 4-байтовым (32-битным) или 8-байтовым (64-битным). Еще лучше, чтобы все было выровнено по 16 байтам, как вы уже сделали ... это позволит быстрее копировать, если вы используете инструкции SSE (MOVNTA). Если вас беспокоит только перемещение элементов, это окажет гораздо большее влияние, чем тип, используемый массивом ...
почему бы вам не протестировать его, есть масса вещей, которые теоретически могут работать, но на практике имеют разные эффекты. Проверьте это и убедитесь сами, что быстрее. Никто не может ответить на этот вопрос, если он имеет представление о производительности ... среда - это то, что определяет окончательную производительность.