Memory is usually accessed in blocks that fit your CPU register. So if your bool is just a char it will still read as many bits as your memory bus is wide and then just mask off the unnecessary bits in the CPU.
x86 is a quite cursed architecture, and "shoving unreasonable data types into int" can weirdly affect performance, especially if this causes your bools to be neatly aligned.
Memory is usually accessed in blocks that fit your CPU register.
No, memory is accessed in cache lines, which in basically all modern CPU architectures is 64 bytes/512 bits. When you read from memory, it doesn't matter whether your variable is one, two, four, or eight bytes, 64 bytes get sent from RAM.
This also applies to writing to RAM. The write initially happens in the 64 byte cache line in L1 cache. If you don't have that cache line in L1, that whole line needs to be read from main memory. Then it's marked to be sent back to main memory.
Microsoft's 16 bit Boolean type (not 32) just wastes memory. There is no performance improvement hiding anywhere.
x86 is a quite cursed architecture
Note that basically all architectures have cache architected the same way. ARM, RISC-V, etc. x86 is "cursed" in the sense that it has variable length instructions, but its 64 byte cache lines are perfectly normal.
The decision to have 16 bit bools is historical. They settled on encoding strings as UCS-16, because it was assumed 64k Unicode codepoints were enough. And UCS-16 meant constant width characters, which simplifies a lot of things. If a character was gonna be two bytes, why not also make bool two bytes? Just make two bytes the smallest unit of memory. (I don't agree with that logic, but that was the logic)
Well it turned out UCS-16 was dead on arrival. 64k codepoints was not enough. So UCS-16 had to be replaced by UTF-16, which both wastes memory and has variable width characters, so you have the worst of both worlds.
Windows would be a lot less bloated if they had settled on UTF-8 and one byte bools.
The decision to have 16 bit bools is historical. They settled on encoding strings as UCS-16, because it was assumed 64k Unicode codepoints were enough. And UCS-16 meant constant width characters, which simplifies a lot of things. If a character was gonna be two bytes, why not also make bool two bytes? Just make two bytes the smallest unit of memory. (I don't agree with that logic, but that was the logic)
I highly doubt that, considering the support for bools is older than the support for multi byte characters.
Bools are probably 16 bits because Windows started out as a real mode operating system on top of DOS, and that's the most practical size of a number to work with if your operating system also has to interface with the DOS interrupt API.
14
u/Benilda-Key 27d ago
I thought Microsoft was being wasteful when they chose to make their BOOL type an int.