Indeed, my application did not require cache coherency or shared memory. In fact, what we ended up doing was basically a message passing system between the com

Indeed, my application did not require cache coherency or shared memory. In fact, what we ended up doing was basically a message passing system between the commodity machines in the cluster, so each node processed messages independently. Each node maintained its own shared (between messages processed on that node, but not between nodes) state and if a message which needed this state was on a different node, it was transferred to the correct node (using a distributed hash table to know which node to transfer to). Since we could tell very early during the messages processing if it requires access to the shared state or not (we knew more or less by message type), this was very efficient. There was a little more to it for redundancy and fault tolerance, but that's the basic strategy we followed and it does not require shared memory or cache coherency at all, like you correctly identified, which is why we didn't need Tilera and were able to meet our goals on a commodity hardware cluster. When I said my application was a good fit, I really meant that it was embarrassingly parallel enough to make good use of a lot of cores - not that it required or benefited from anything else that the Tilera hardware would have given us.