Depending on the language
And compiler. And hardware architecture. And optimization flags.
As usual, it’s some developer that knows little enough to think the walls they see around enclose the entire world.
I don’t think so. Apart from dynamically typed languages which need to store the type with the value, it’s always 1 byte, and that doesn’t depend on architecture (excluding ancient or exotic architectures) or optimisation flags.
Which language/architecture/flags would not store a bool in 1 byte?
things that store it as word size for alignment purposes (most common afaik), things that pack multiple books into one byte (normally only things like bool sequences/structs), etc
things that store it as word size for alignment purposes
Nope. bools only need to be naturally aligned, so 1 byte.
If you do
struct SomeBools { bool a; bool b; bool c; bool d; };its 4 bytes.
sure, but if you have a single bool in a stack frame it’s probably going to be more than a byte. on the heap definitely more than a byte
but if you have a single bool in a stack frame it’s probably going to be more than a byte.
Nope. - if you can’t read RISC-V assembly, look at these lines
sb a5,-17(s0) ... sb a5,-18(s0) ... sb a5,-19(s0) ...That is it storing the bools in single bytes. Also I only used RISC-V because I’m way more familiar with it than x86, but it will do the same thing.
on the heap definitely more than a byte
Nope, you can happily
malloc(1)and store a bool in it, ormalloc(4)and store 4 bools in it. A bool is 1 byte. Consider this a TIL moment.c++ guarantees that calls to malloc are aligned https://en.cppreference.com/w/cpp/memory/c/malloc .
you can call
malloc(1)ofc, but callingmalloc_usable_size(malloc(1))is giving me 24, so it at least allocated 24 bytes for my 1, plus any tracking overheadyeah, as I said, in a stack frame. not surprised a compiler packed them into single bytes in the same frame (but I wouldn’t be that surprised the other way either), but the system v abi guarantees at least 4 byte alignment of a stack frame on entering a fn, so if you stored a single bool it’ll get 3+ extra bytes added on the next fn call.
computers align things. you normally don’t have to think about it. Consider this a TIL moment.
Wait till you find out about alignment and padding
Tell me the truth, i can handle it
typedef struct { bool a: 1; bool b: 1; bool c: 1; bool d: 1; bool e: 1; bool f: 1; bool g: 1; bool h: 1; } __attribute__((__packed__)) not_if_you_have_enough_booleans_t;I set all 8 bits to 1 because I want it to be really true.
01111111 = true
11111111 = negative true = false
Why do alternative facts always gotta show up uninvited to the party? 🥳
Could also store our bools as floats.
00111111100000000000000000000000is true and10111111100000000000000000000000is negative true.Has the fun twist that true & false is true and true | false is false .
So all this time true was actually false and false was actually true ?
Depends on if you are on a big endian or little endian architecture.
Come on man, I’m not gonna talk about my endian publicly
00001111 = maybe
Schrödingers Boolean
10101010 = I don’t know
0011 1111 = could you repeat the question
Back in the day when it mattered, we did it like
#define BV00 (1 << 0) #define BV01 (1 << 1) #define BV02 (1 << 2) #define BV03 (1 << 3) ...etc #define IS_SET(flag, bit) ((flag) & (bit)) #define SET_BIT(var, bit) ((var) |= (bit)) #define REMOVE_BIT(var, bit) ((var) &= ~(bit)) #define TOGGLE_BIT(var, bit) ((var) ^= (bit)) ....then... #define MY_FIRST_BOOLEAN BV00 SET_BIT(myFlags, MY_FIRST_BOOLEAN)With embedded stuff its still done like that. And if you go from the arduino functionss to writing the registers directly its a hell of a lot faster.
Okay. Gen z programmer here. Can you explain this black magic? I see it all the time in kernel code but I have no idea what it means.
It’s called bitshifting and is used to select which bits you want to modify so you can toggle them individually.
1 << 0 is the flag for the first bit
1 << 1 for the second
1 << 2 for the third and so onI think that’s correct. It’s been years since I’ve used this technique tbh 😅
The code is a set of preprocessor macros to stuff loads of booleans into one int (or similar), in this case named ‘myFlags’. The preprocessor is a simple (some argue too simple) step at the start of compilation that modifies the source code on its way to the real compiler by substituting #defines, prepending #include’d files, etc.
If myFlags is equal to, e.g. 67, that’s 01000011, meaning that BV00, BV01, and BV07 are all TRUE and the others are FALSE.
The first part is just for convenience and readability. BV00 represents the 0th bit, BV01 is the first etc. (1 << 3) means 00000001, bit shifted left three times so it becomes 00001000 (aka 8).
The middle chunk defines macros to make bit operations more human-readable.
SET_BIT(myFlags, MY_FIRST_BOOLEAN)gets turned into((myFlags) |= ((1 << 0))), which could be simplified asmyFlags = myFlags | 00000001. (Ignore the flood of parentheses, they’re there for safety due to the loaded shotgun nature of the preprocessor.)
Could a kind soul ELI5 this? Well, maybe ELI8. I did quite a bit of programming in the 90-00s as part of my job, although nowadays I’m more of a script kiddie.
A Boolean is a true/false value. It can only be those two values and there be represented by a single bit (1 or 0).
In most languages a Boolean variable occupies the space of a full byte (8 bit) even though only a single of those bits is needed for representing the Boolean.
That’s mostly because computers can’t load a bit. They can only load bytes. Your memory is a single space where each byte has a numeric address. Starting from 0 and going to whatever amount of memory you have available. This is not really true because on most operating systems each process gets a virtual memory space but its true for many microcontrollers. You can load and address each f these bytes but it will always be a byte. That’s why booleans are stored as bytes because youd have to pack them with other data on the same address other wise and that’s getting complicated.
Talking about getting complicated, in C++ a std::vector<bool> is specialized as a bit field. Each of the values in that vector only occupy a single bit and you can get a vector of size 8 in a single byte. This becomes problematic when you want to store references or pointers to one of the elements or when you’re working with them in a loop because the elements are not of type bool but some bool-reference type.
And performance optimisation of a compiler for a 64 bit CPU will realign everything and each boolean will occupy 8 bytes instead.
Then you need to ask yourself: Performance or memory efficiency? Is it worth the extra cycles and instructions to put 8 bools in one byte and & 0x bitmask the relevant one?
A lot of times using less memory is actually better for performance because the main bottleneck is memory bandwidth or latency.
It’s not just less memory though - it might also introduce spurious data dependencies, e.g. to store a bit you now need to also read the old value of the byte that it’s in.
It might also introduce spurious data dependencies
Those need to be in the in smallest cache or a register anyway. If they are in registers, a modern, instruction reordering CPU will deal with that fine.
to store a bit you now need to also read the old value of the byte that it’s in.
Many architectures read the cache line on write-miss.
The only cases I can see, where byte sized bools seems better, are either using so few that all fit in one chache line anyways (in which case the performance will be great either way) or if you are repeatedly accessing a bitvector from multiple threads, in which case you should make sure that’s actually what you want to be doing.
Wait until you hear about alignment
The alignment of the language and the alignment of the coder must be similar on at least one metric, or the coder suffers a penalty to develop for each degree of difference from the language’s alignment. This is penalty stacks for each phase of the project.
So, let’s say that the developer is a lawful good Rust
zealotPaladin, but she’s developing in Python, a language she’s moderately familiar with. Since Python is neutral/good, she suffers a -1 penalty for the first phase, -2 for the second, -3 for the third, etc. This is because Rust (the Paladin’s native language) is lawful, and Python is neutral (one degree of difference from lawful), so she operates at a slight disadvantage. However, they are both “good”, so there’s no further penalty.The same penalty would occur if using C, which is lawful neutral - but the axis of order and chaos matches, and there is one degree of difference on the axis of good and evil.
However, if that same developer were to code in Javascript (chaotic neutral), it would be at a -3 (-6, -9…) disadvantage, due to 2 and 1 degree of difference in alignment, respectively.
Malbolge (chaotic evil), however, would be a -4 (-8, -12) plus an inherent -2 for poor toolchain availability.
…hope this helps. have fun out there!
If JS is chaotic neutral, what then is chaotic evil?
All I’m saying is
"10" + 1 => "101" "10" - 1 => 9 "a" - "b" => NaNfair enough. My personal opinion might be that it’s evil, but perhaps that’s because I expected some kind of order.
This reminds me that I actually once made a class to store bools packed in uint8 array to save bytes.
Had forgotten that. I think i have to update the list of top 10 dumbest things i ever did.
Ah, the creator od std::vector<bool>?
It’s far more often stored in a word, so 32-64 bytes, depending on the target architecture. At least in most languages.
No it isn’t. All statically typed languages I know of use a byte. Which languages store it in an entire 32 bits? That would be unnecessarily wasteful.
It’s not wasteful, it’s faster. You can’t read one byte, you can only read one word. Every decent compiler will turn booleans into words.
You can’t read one byte
lol what. You can absolutely read one byte: https://godbolt.org/z/TeTch8Yhd
On ARM it’s
ldrb(load register byte), and on RISC-V it’slb(load byte).Every decent compiler will turn booleans into words.
No compiler I know of does this. I think you might be getting confused because they’re loaded into registers which are machine-word sized. But in memory a
boolis always one byte.Sorry, but you’re very confused here.
You said you can’t read one byte. I showed that you can. Where’s the confusion?
Internally it will still read a whole word. Because the CPU cannot read less than a word. And if you read the ARM article you linked, it literally says so.
Thus any compiler worth their salt will align all byte variables to words for faster memory access. Unless you specifically disable such behaviour. So yeah, RTFM :)
Wrong again. It depends on the CPU. They can absolutely read a single byte and they will do if you’re reading from non-idempotent memory.
If you’re reading from idempotent memory they won’t read a byte or a word. They’ll likely read a whole cache line (usually 64 bytes).
And if you read the ARM article you linked, it literally says so.
Where?
Thus any compiler worth their salt will align all byte variables to words for faster memory access.
No they won’t because it isn’t faster. The CPU will read the whole cache line that contains the byte.
RTFM
Well, I would but no manual says that because it’s wrong!
I mean is it really a waste? What’s minimum amount of bits most CPUs read in one cycle.
In terms of memory usage it’s a waste. But in terms of performance you’re absolutely correct. It’s generally far more efficient to check is a word is 0 than to check if a single bit is zero.
Usually the most effective way is to read and write the same amount of bits as the architecture of the CPU, so for 64 bit CPUs it’s 64 bits at once.
Are you telling me that no compiler optimizes this? Why?
Consider what the disassembly would look like. There’s no fast way to do it.
It’s also unnecessary since 8 bytes is a negligible amount in most cases. Serialization is the only real scenario where it matters. (Edit: and embedded)
In embedded, if you are to the point that you need to optimize the bools to reduce the footprint, you fucked up sizing your mcu.
They do, that’s the optimisation.
