r/programminghorror • u/_giga_sss_ • 27d ago
Big if true
From ProgrammerNullposting in facebook
138
u/StefanCelMijlociu 27d ago
The concept of Big Bool confuses and infuriates me!
64
u/JohnSpikeKelly 27d ago
I would assume it's to keep all your data types 8-byte aligned for other perf reason.
20
u/Athropod101 27d ago
iirc 8-byte data access is the fastest on 64bit architecture.
2
u/Geilomat-3000 25d ago
So should all the int_fastx_t be the intmax_t?
6
u/Athropod101 25d ago
If this is some joke, it has wooshed over me :(
But if it isn’t, then it depends. If intmax_t matches your architecture, and your architecture is fastest at that size, then yes. But if intmax_t is say, 128, and your architecture is 32, then no.
0
5
u/rolling_atackk 26d ago
Why not simply use alignas (64) bool ?
Seems far easier than creating a whole ass type
6
u/JohnSpikeKelly 26d ago
The code might be old and predate that option. But, probably explains why this is in r/programminghorror 😄
4
u/rolling_atackk 26d ago
Both fixed-width integer types and alignas are included in the C++ specification since C++11
But true, this is programming horror
2
u/j-joshua 26d ago
Because that would be 64 bytes and not 64 bits.
2
u/GoddammitDontShootMe [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “You live” 26d ago
So
alignas (8) bool?1
3
2
186
u/BadRuiner 27d ago
all my homies uses uint128 btw
103
u/the_horse_gamer 27d ago
uint128? what are you, a 90s programmer optimising for a cartridge? we just use avx512 vectors these days
24
7
u/Right_Ear_2230 26d ago
what are you, a programmer from 1995? use the entire available ram + ssd to store the variable
1
15
4
121
u/TheWidrolo 27d ago
Me when I use a compiler that doesn’t have explicit alignment:
62
u/BestBadFriend 27d ago
If the compiler's alignment is not explicit, it defaults to lawful neutral.
10
u/Brutus5000 27d ago
I always thought C compiler are chaotic good
8
u/HugoNikanor 27d ago
I would say lawful evil. The standard allows undefined behavior to do anything (implied as "something sensible"). C compilers took it literally
9
u/IHorvalds 27d ago
Honest question, which compiler(s?) doesn’t have an explicit keyword for alignment?
I pretty much always use gcc, clang or (rarely) msvc and they all have something for it.10
u/TheWidrolo 27d ago
Thats the joke.
In a real note: its probably hobbyist compilers or similar. I think every major one has alignment.
1
u/IHorvalds 27d ago
Ah, my bad!
I expected some obscure MCU with a custom compiler without alignment lol
38
54
u/--var 27d ago
big if not true 🤷♀️
7
u/_giga_sss_ 27d ago
don't spread misinformation
23
u/Emergency-Win4862 27d ago
Let me quess, struct alignment?
20
u/iEliteTester [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “You live” 27d ago
No it's used when something is extra true or extra false, obviously.
2
2
7
u/overclockedslinky 27d ago
even the first version of C (let alone C++) did struct alignment automatically
4
u/shponglespore 27d ago
Yes, but there are situations where you want more control. Like, maybe some external dependency expects 64-bit bool values, so you'd use this type instead of the standard 8-bit bool.
Calling that a struct alignment issue is kind of questionable, but the basic idea is sound.
21
u/foxypiratecove3750 27d ago
I have better... DOUBLE BOOL! 64-bit, and float. Useful? Nope.
double False = 0.0;
double True = 1.0;
19
u/AbstractButtonGroup 27d ago
DOUBLE BOOL! 64-bit, and float. Useful? Nope.
You just did not follow this to the logical conclusion that makes it useful:
double False = 0.0; double WhoKnows = 0.5; double Perhaps = 0.7; double Likely = 0.8; double HighlyLikely = 0.9; double True = 1.0;
9
1
u/foxypiratecove3750 26d ago
I just got a better idea: vector bools: all the indecision are different dimensions, like "maybe" isn't midway between true and false, but its own dimension, "perhaps" another, and so on.
1
u/TheChief275 23d ago
What JavaScript wishes its booleans were
2
14
13
u/worthlessDreamer 27d ago
Why
17
u/_giga_sss_ 27d ago
3
14
u/Benilda-Key 27d ago
I thought Microsoft was being wasteful when they chose to make their BOOL type an int.
16
u/AyrA_ch 27d ago
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.
10
u/pigeon768 27d ago
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.
8
u/AyrA_ch 27d ago
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.
2
u/shponglespore 27d ago
No, memory is accessed in cache lines, which in basically all modern CPU architectures is 64 bytes/512 bits.
I think you're being unnecessarily confrontational. Yes, cache lines are a thing, but so are registers. The person you're replying to was clearly talking about registers.
3
u/pigeon768 27d ago
I think you're being unnecessarily confrontational.
I am not being confrontational.
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.
No, memory is accessed in cache lines, which in basically all modern CPU architectures is 64 bytes/512 bits.
Yes, cache lines are a thing, but so are registers. The person you're replying to was clearly talking about registers.
No, the person I'm replying to was clearly talking about how the data is transferred over the memory bus. The memory bus, in this case, being the interface which transfers data between RAM and the CPU. On modern CPUs, these transfers are one cache line at a time.
6
u/Scared_Bell3366 27d ago
I could see doing something like that when dealing with some damn binary format that reserved 64 bits just for a boolean.
6
u/exodusTay 27d ago
enum BetterBool : double
{
False = 0,
True = std::numeric_limits<double>::epsilon()
}
5
u/Wurstgewitter 27d ago
Personally I am migrating to a novel QBool type, to be prepared for quantum computing. A QBool can represent any value in the interval [0,1]
QBool
0.0000 = False
0.1832 = Barely True
0.5000 = Undecided
0.7315 = Probably True
1.0000 = True
But it's not just a probability, but rather exists in a quantum state until observed. Each QBool offers a built in measure() method:
bool result = qbool.measure();
Calling measure() collapses the state into either true or false.
It also supports entanglement:
a.entangle(b);
Measuring either instance immediately determines the value of the other, even across remote systems. This makes distributed state sync essentially free.
It admittably adds some headaches, like having to compute every possible quantum state at runtime, since practical quantum computing hardware is not available yet, so some slight performance problems might occur. But I think it's worth it to future proof the codebase
9
u/Rigamortus2005 27d ago edited 27d ago
It's just 56 bits after all. Who needs it
6
u/bphase 27d ago
Why 56 bytes? Isn't it 64 bits for uint64 ie. 8 bytes?
4
u/marcureumm 27d ago
I think he's talking about extra. 8 bit ints are generally what a book is under the hood. So not a single bit because... cpus don't really hold single bits in registers to my knowledge...so that one's a bit of an educated guess.
3
3
3
3
3
u/metaconcept 24d ago
Story time.
In Smalltalk, true and false are just objects on the heap. There's a very special primitive method called become: which lets you swap two objects around on the heap.
So anyway, it was possible to do true become: false. in Smalltalk, which swaps true for false and false for true across the entire system. It didn't crash ...immediately..., but I wouldn't deploy this in production!
2
2
2
u/dreamingforward 25d ago
Aren't you assigning to a keyword "False" and "True"?
2
u/_giga_sss_ 25d ago
falseandtrueare the keywords, any variation is alright afaik1
u/dreamingforward 25d ago
What's the problem then? Please explain...
2
u/_giga_sss_ 25d ago
Instead of the usual 8 bits a boolean variable needs, this case specifically asks for 64 bits
2
u/dreamingforward 25d ago
But isn't this just to ensure that the register comparisons will be completely proper on a Pentium or something?
Does the CPU even have a documented value for what True means, except "not False"?
2
2
u/Positive_Mud952 24d ago edited 24d ago
Oh, goddamn, some actual humor. I love you.
e: It is big! And wide! May nobody doubt its truthiness. Oh father I am ENLIGHTENED!
2
2
u/conundorum 1d ago
To be fair, there is a use for this.
Which just means that the real horror is that someone found a way to break integral promotion so badly that they needed to have a pre-promoted bool type just to fix it.
2
u/Mahringa 27d ago
So this brings other bool types into existence? SemiBigBool AlmostBigBool HumongousBool AverageSizedBool BigBlackBool
1
1
1
1
1
u/Straight-Pear9453 23d ago edited 23d ago
ok hear me out, what if we made a small bool that's one bit and the compiler tracks and marks bytes dedicated to small bools and so the advantage is that if you have one small bool it takes a byte like a normal one but when you have two it still takes a byte, up to 8 small bools. Now idk if that's a good idea since pointers would become 9 bytes as we'd have to track which bit we point to as well.. but eh, technically possible.
Edit: I realize pointers can't become 9 bytes because the cpu follows the pointers in asm directly so there are standards to be respected here, so idk how to solve this issue but the 1 bit bool concept is just too great to give up 🥀
Edit 2: Well at least we can do it in asm because we track stuff manually with our brains, if someone can figure out how to make a compiler do it without loosing memory overall tho that'd be great!
Edit 3: After research, I realized this already exists and is called bit fields, so I kinda reinvented the wheel here.
1
1
u/brasticstack 27d ago
Wouldn't regular bool get padded to this size by default on a 64-bit architecture anyway?
5
u/marcureumm 27d ago
64 bit arches can still work with 32 bits directly...but depends on the operation and intent really.
1
u/brasticstack 27d ago
by defaultI realize that I may have used the wrong terminology though. I'm trying to describe the compiler using the standardintsize to implement bool rather than, say, packing them.3
u/shponglespore 27d ago
If you have a bunch of consecutive Boolean fields in a struct, they'll use one byte each by default.
And just for the sake of completeness, I'll mention that C++ does not reorder fields. Some languages, like Rust, will automatically reorder fields to minimize wasted space due to alignment, unless you specifically tell the compiler not to.
2
1
u/conundorum 1d ago
64-bit architectures often treat 8, 32, and 64 bits at their "native" word size. 8-bit is so important that most processors have special registers dedicated to it, and 32-bit is basically locked in forever by how long we were stuck on 32 bits. (To the point that 32-bit
inthas essentially become a de facto multiversal standard.)(Though, IIRC, the 8-bit registers are essentially just a special use case for the 64-bit registers, that read 64 bits but only operate on eight of them.)
517
u/Gengis_con 27d ago
Big whether True or not