Thanks for the good read, ill see if I can pay you back with some techno.
To get your machine to work, u could get away with a simplified high population pattern matching technique.
Its simple, and it multicores simply.
Change the form organization of your programming style, and it can simplify into a parallelizable structure like this:
for(t=0;t<POPULATION;t++)
{
switch(THREAD INPUT PATTERN)
{
case PAT A: return OUT A; break;
case PAT B: return OUT B; break;
case PAT C: return OUT C; break;
case PAT D: return OUT D; break;
case PAT E: return OUT E: break;
case PAT F: return OUT F; break;
.... n....
case PAT "million": return OUT MILLION; break;
}
}
If you put it in this form its easily parallelizable, and the switch statement in c is nice and itll route to the pattern in 1 cycle, u should be able to get into the millions of accesses. Even on a fairly ordinary computer.
What goes into it content wise is very important!
I remember at a pattern matching lecture today, The professor mentioned that you shouldnt ever just link a -> "42" because its wasteful of fields, but the symantics of the key should be designed so that it will include invarience in the match, due to your pick of variables for the key specification chart to go into the input, and then its a numerically based equivilent method for simplifying the complexity of the machine, therefore also increasing latent capacity given the same computational budget. ;)
In a finished droid, there may be 3 - 8 in a row - similar to a truth table machine- (id say it would be less than 2 hands), and contain millions of fields each, so if you wanted to do that LOCK THE END AT WHAT YOU WANT TECHNIQUE (then buzz it alot) you were talking about, im sure it would work in this stripped down purist I/O shape paradigm also.