Why is the bool type 4 bytes it's a wast of memory..
in [CSharp]
|
Prev: Using Delegates?
Next: Drag & Drop text
From: Arne Vajhøj on 3 Jun 2010 22:31 On 28-05-2010 07:24, Patrice wrote: >> I mean it's just a wast of memory. > > As most design decision, this is a tradeoff that is you usually buy memory > at the price of speed or speed at the price of memory. > > Here they likely considered how data are aligned in memory. From > http://en.wikipedia.org/wiki/Data_structure_alignment : > > "Data alignment means putting the data at a memory offset equal to some > multiple of the word size, which increases the system's performance due to > the way the CPU handles memory. To align the data, it may be necessary to > insert some meaningless bytes between the end of the last data structure and > the start of the next, which is data structure padding." That is not a sufficient argument: 1 byte incl. padding 4 bytes incl. padding 1 boolean 4 bytes 4 bytes 4 boolean 4 bytes 16 bytes Arne
From: Peter Duniho on 3 Jun 2010 22:55 Arne Vajh�j wrote: > On 28-05-2010 03:58, Peter Duniho wrote: >> On current hardware architectures, it's more efficient to move 32 bits >> around than just 8. And because of that, there's the possibility that >> writing to a 1-byte boolean would require first reading 4 bytes, >> modifying a single byte within those 4 bytes, and then writing the 4 >> bytes back. Obviously that's harder for .NET to make atomic than just >> writing to a single 32-bit word, and of course the efficiency aspect >> alone is a decent enough reason. > > But the old architecture x86 and x86-64 is actually killing the > modern architecture IA-64. Itanium seems to be on its way out, yes. Word-sized memory access is more critical on Itanium (maybe one reason people don't use it as much :) ), but even though no exception occurs on x86 for unaligned data access, that doesn't mean there's no advantage to doing so. And if committed to writing more than one byte at once, the issue of non-atomic byte-sized writes becomes an issue. For performance reasons, it might well make sense to avoid having to decide between the in-CPU overhead and the out-of-CPU overhead and just create a data size large enough that neither matters. >> When you think about it, you might as well ask why a boolean isn't just >> 1 _bit_ in size. The issues are actually quite similar. > > In Pascal packed array of boolean usually is a single bit per boolean. If you specify "PACKED", yes...the data winds up packed. And? This is C#, not Pascal. And there's a reason C# doesn't have bitfields nor packed bit-array data structures. The same reason applies to not making booleans 1 bit wide as to not making booleans 1 byte wide. Whatever that reason is. ;) Pete
From: Patrice on 4 Jun 2010 07:54 Hello, > 1 byte incl. padding 4 bytes incl. padding > 1 boolean 4 bytes 4 bytes > 4 boolean 4 bytes 16 bytes But then those booleans are not all aligned any more in memory while they are still aligned with the more expensive layout. Anyway my main point was rather to tell the OP that he has other options if he needs to save space (as knowing why it is done this way is unlikely to change anything) likely at the price of speed (even going down to a boolean per bit). -- Patrice
From: Arne Vajhøj on 5 Jun 2010 23:21 On 03-06-2010 22:55, Peter Duniho wrote: > Arne Vajh�j wrote: >> On 28-05-2010 03:58, Peter Duniho wrote: >>> On current hardware architectures, it's more efficient to move 32 bits >>> around than just 8. And because of that, there's the possibility that >>> writing to a 1-byte boolean would require first reading 4 bytes, >>> modifying a single byte within those 4 bytes, and then writing the 4 >>> bytes back. Obviously that's harder for .NET to make atomic than just >>> writing to a single 32-bit word, and of course the efficiency aspect >>> alone is a decent enough reason. >> >> But the old architecture x86 and x86-64 is actually killing the >> modern architecture IA-64. > > Itanium seems to be on its way out, yes. > > Word-sized memory access is more critical on Itanium (maybe one reason > people don't use it as much :) ), but even though no exception occurs on > x86 for unaligned data access, that doesn't mean there's no advantage to > doing so. And if committed to writing more than one byte at once, the > issue of non-atomic byte-sized writes becomes an issue. Neither solution involves any unaligned data access. There are no reason to expect 4 bytes to be faster than 1 byte. I tried making some tests on some systems: x86, x86-64 and Power : approx. same speed Alpha and IA-64 : 4 byte faster for write operations Unless one is using .NET on IA-64, then the performance benefits is not existing. >>> When you think about it, you might as well ask why a boolean isn't just >>> 1 _bit_ in size. The issues are actually quite similar. >> >> In Pascal packed array of boolean usually is a single bit per boolean. > > If you specify "PACKED", yes...the data winds up packed. > > And? This is C#, not Pascal. And there's a reason C# doesn't have > bitfields nor packed bit-array data structures. The same reason applies > to not making booleans 1 bit wide as to not making booleans 1 byte wide. > > Whatever that reason is. ;) Not really. Packing to bits will have a real performance impact. Arne
From: Arne Vajhøj on 5 Jun 2010 23:23
On 04-06-2010 07:54, Patrice wrote: >> 1 byte incl. padding 4 bytes incl. padding >> 1 boolean 4 bytes 4 bytes >> 4 boolean 4 bytes 16 bytes > > But then those booleans are not all aligned any more in memory while they > are still aligned with the more expensive layout. They are natural aligned in both cases. > Anyway my main point was rather to tell the OP that he has other options if > he needs to save space (as knowing why it is done this way is unlikely to > change anything) likely at the price of speed (even going down to a boolean > per bit). Unless MS was interested in Itanium (which they actually may have been back in 2001-2002 when stuff like this was decided !), then performance could not justify the decision. Arne |