Когда BOOL тип данные не всегда предопределен, я использовал булев со следующим определением,определения BOOL
ЬурейеГо неподписанный символ BOOL;
(Из-за использования памяти).
Я понял, что лучше использовать собственную ширину шины по соображениям производительности. Например, для 32-битного процессора это может быть
typedef unsigned int BOOL;
Теперь, что произойдет для 64-битного процессора, если я все еще хочу определить BOOL для собственной ширины шины.
По меньшей мере, x86 и ARM способны загружать и хранить байты в 32-битный регистр без каких-либо штрафов, поэтому на использование символа действительно не влияет производительность. Я не совсем уверен, но я бы сказал, что у x86-64 есть такие инструкции. (Конечно, x86 и x86-64 могут обрабатывать 8-битные значения непосредственно в регистрах тоже.).
Таким образом, единственная проблема может заключаться в макете памяти. Конечно, компилятор выравнивает все, поэтому большую часть времени значения char в структурах дополняются, если они не находятся рядом друг с другом, тогда вы можете фактически сохранить несколько байтов пространства и получить немного лучшую производительность кеша. Если у вас огромные массивы BOOL, а память - проблема, вы все равно должны упаковать их.
В любом случае, это не проблема. Почему бы вам не попробовать запустить программу, скомпилированную в обоих направлениях, и увидеть, если какое-либо существенное влияние на производительность или использование памяти. Если вы обнаружите, что есть, вы можете купить себе пиво и притвориться, что это от меня.
Я бы не стал беспокоиться о родной шине шириной, равной эффективной ширина (это была ваша цель, право)? На почти любой машине любой достойный компилятор c будет компилировать unsigned int на разумно эффективную ширину, так что вам хорошо идти.
Одно исключение составляют стандарты совместимые компиляторы для 8-разрядных микроконтроллеров. В этом случае unsigned char более эффективен, так как 16 бит - это минимальный размер int. –
@monjardin Да, и я полагаю, это может иметь значение, потому что он говорит о встроенных. Но действительно ли кто-нибудь действительно много делает на 8-битной шине? К этому моменту я ожидаю, что вы будете делать обычную или как-то, и даже поэтому я не уверен, почему. – MarkusQ
@MarkusQ, есть еще много вещей, которые все еще работают с 8-битными шинами, чем вы предполагали. Архитектура 8051 выглядит так, будто она никогда не умрет, например, и Z80 тоже живет ... – RBerteig
Ну, вы всегда можете определить typedef для long long или что-то в этом роде, но я на самом деле не уверен, что это то, что люди почему-то делают. (возможно, вы также можете сделать условное определение, основанное на sizeof (int *) или что-то в этом роде).
У меня нет голосов, так что +1 завтра. size_t автоматически расширяется до самого доступного беззнакового типа. –
Я бы рекомендовал использовать препроцессор.
#ifndef BOOL
#ifdef ILP32
#define BOOL uint32_t
#endif
#ifdef LP64
#define BOOL uint64_t
#endif
#endif
Использование символа может быть медленнее, чем использование целого числа.
Никогда не спекулируйте на представлениях, мера. Измеряя, даст окончательный ответ на то, что лучше - и помните, что это может измениться при каждой новой версии компилятора, обновление системы ...
Также в один прекрасный день вам может понадобиться массив булевых, и в этом случае с использованием процессорного слова для bool может не быть лучшим решением.
Просто посмотрите на количество инструкций по сборке, которые транслируется вашим кодом, а также тактовые циклы каждого из них. В этом случае, по-моему, измерение станет немного сложным. – Alphaneo
Не уверен, что я понял, к чему вы клоните. Позвольте мне пояснить: я имел в виду, когда задавался вопросом о выступлениях на таком низком уровне (т.е. не алгоритме), сравнение лучше. Создайте тестовую программу с интенсивным использованием bools и измерьте с помощью char или bool и comapre до 64 бит bools. – philant
Вы получаете всевозможные забавные вещи, такие как выравнивание памяти, количество данных, полученных за раз и т. Д., Где вам нужно знать больше, чем просто набор исходных команд. Но проверка на проверку всегда хорошая вещь. – TofuBeer
оптимальные для большинства платформы
ЬурейеГо перечисление { значения FALSE = 0, ИСТИНЫ = 1, } BOOL;
Потому что тогда TRUE! =! FALSE – Mikeage
??? Что вы имеете в виду? Iso c89 требует! 0 == 1. –
int_fast8_t из stdint.h должен быть хорошим выбором
Если вы упаковываете (1), то, очевидно, при загрузке количество инструкций для выделения bool должно быть больше, чем просто загрузка собственных слов ширины. Можете ли вы представить себе это представление? – Alphaneo
Я не уверен, что вы имеете в виду, но у ARM есть инструкции ldrb/strb для загрузки байтов. X86 может загружать байт непосредственно в младшие 8-битные регистры (экв. Mov al, [addr]), и есть movzx eax, [addr] для загрузки нулевого расширенного байта в eax. – TrayMan
@TrayMan - подсчитывает циклы и байты для не выровненных данных, чтобы увидеть, что он имеет в виду. Там может быть значительное наказание, и как мурфи говорит, что может быть, будет. – MarkusQ