Not too close please!

Thinking about how the multiple core setup is, I realized I missed something in my internal map how computing is done on my machine, say 2 cores. Many applications have good cache hit rates but it strikes me that when you do scanning work in a stream with a sequence of modifiers you would like to have the stream nodes close to each other in order to reuse cache but not too close in order to muck with each other. For large mungling of data sure there will be a benifit on doing this.

Another thing that struck me was that perhaps working with variable sized objects might not be as stupid as I thought before, especially if your work flow is to mostly construct new lists all the time. Then you could compress your linked list for the special case when the cons cells is physically situated one after another or perhaps just close to each other. Hmm actually you could make your cpu help you in this task to really scan fast through these lists. And perhaps there are algorithm that may still let you link as you like (at the usual performance hit if it is done more often). Think scanning speed of arrays, flexibility of linked lists.

Actually contemplating about scanning and reading in a stream from RAM, doing processing on the cores in a stream like fashion you would like to use the bandwidth of the BUS between ram and cpu as efficiently as possible, can it be wise to implement help in the cpu to compress and decompress data structures?

Bullseye!!!