Bit subscriptions, RAM columnwise layouts

[Nick Sabalausky]

"Bill Baxter" <wbaxter at gmail.com> wrote in message 
news:mailman.150.1229027026.22690.digitalmars-d at puremagic.com...
> On Thu, Dec 11, 2008 at 11:21 PM, bearophile <bearophileHUGS at lycos.com> 
> wrote:
>> Wirbel lets you use an integer a little bit like a list of boolean values 
>> with the fixed length of 32 or 64. You can used the square brackets to 
>> directly address the bits:
>>
>> a = 0
>> a[0] = true
>> a[2] = false
>> print(a)
>
> Nice idea, that makes a lot of sense.
>
>> DataDraw is a very interesting library for C, it can be used as a 
>> RAM-database:
>> http://datadraw.sourceforge.net/
>
>> - By default it uses parallel arrays, that is if you create an array of 
>> struct-like things, it doesn't actually keep them as an array of structs, 
>> but as many arrays of single items. So the programmer doesn't specify how 
>> the system lays and uses memory, and usually lets the system do by 
>> itself. There is a also syntax to say that some or all fields of such 
>> records have to actually be stored closely, this is useful for the less 
>> common situations when you need to process more than a field at a time). 
>> This often leads to better usage of the cache, and in the end speeds up 
>> several programs.
>
> That's kind of interesting too.  There are definitely times I've
> flip-flopped back and forth over whether some particular thing should
> be an array-of-structures or a structure-of-arrays.  Definitely seems
> do-able in D.  You could make it so a Record!(Struct,20) stores
> Structs column-wise, or just flip a bit to store them the other way:
> Record!(Struct,20,RecordOrientation.Row).
>

I've always preferred array-of-structs because that way it's impossible for 
the lengths or indicies to end up out-of-sync. However, it does seem like 
accessing the same field from multiple "rows" could in many cases be more 
common than accessing lots of fields from one "row". So given a nice generic 
class or template or something that could ensure proper atomicity (is that 
the correct noun form of "atomic operation"?) for struct-of-arrays 
operations, I can see a lot of cases where it would be much more 
cache-friendly than my usual array-of-structs approach. I'm glad this was 
brought up, I had never thought about it that way before.