В настоящее время я начинаю проект на PS3 в университете, и мы получаем оценки за то, насколько оптимизирован код.
Я и мой партнер смотрели на битовые поля, поскольку мы имеем дело с миллионами чисел от 0 до 255. Мы решили, что если мы сможем упаковать 4 целых числа в 4 байта (типичный блок памяти целочисленного размера) вместо одного, то сможем четверть память используется. Мы считаем, что работа с данными — одна из самых больших оптимизаций, которую мы могли бы сделать, и мы изучаем все. Стоит ли хлопот? Кажется, что-то, с чем довольно сложно справиться в редактировании целых.
У нас также есть проблема в том, что в идеале нам нужны разные битовые поля, зависящие от чисел, поскольку до 255 требуется 9 бит, но большинству не потребуется столько битов.
Затем мы можем также быстро передать данные процессорам spu и, надеемся, увидеть значительные улучшения, когда мы введем параллелизм в код.
Как указано в комментариях:
«Оптимизация часто является компромиссом между скоростью и пространством. Битовые поля могут экономить пространство, но обрабатывать их медленнее, чем целые».
Битовые поля редко используются по нескольким причинам
char
должен делать работу адекватно, 8 бит в char
против сказать, int_32
с 32, без добавления накладных расходов на доступ к данным. Общее правило:
(обратите внимание, что вы можете заранее оценить размер, если у вас есть представление о том, что вы будете хранить. Пока вы не приступите к оптимизации строк кэша (бит как по скорости, так и по памяти) до тех пор, пока он будет «подходить», вы, вероятно, можете дать самостоятельно отметьте использование памяти)
К вашему сведению, наиболее распространенное использование битовых полей — это упаковка данных в структуры данных, предназначенные для передачи. Это только первый пример, который я смог найти
Вам просто нужно int8_t
(подписано) или uint8_t
(без знака) 8-битные целые числа из <cstdint>
Заголовок C ++ (или <stdint.h>
в С99). Нет необходимости использовать битовые поля (которые непереносимы, медленны и неудобны в использовании — например, вы не можете взять их адрес или ссылку).
Для параллельной векторной обработки рассмотрим также, возможно, OpenCL а также OpenMP и в конце концов OpenACC. Лучше использовать очень свежий компилятор, который также поддерживает C ++ 11. Остерегайтесь этого SPU очень специфичны для оборудования.
В зависимости от вашего приложения вы можете быть немного разочарованы реальной производительностью SPU, и ни OpenCL, ни OpenMP, ни OpenACC не являются серебряными пулями. Параллелизм это сложно.