We're diverging from the original topic here but......

The pitfalls of multi-cpu designs - one could write a book on this topic. First and foremost is that the task can be divided easily (I think Jan mentioned this). If you have tasks on each of the cpus that need to communicate with each other then inter-cpu comms becomes the bottleneck. This can kill any performance advantage you get from having multiple cpus. so, if your task can be divided cleanly and the amount of interaction between cpus is minimal, then a multi-cpu solution might be a good method.

I fell into a trap some time ago where I had three cpus. Two of these cpus had a lot of ram (16k) and ran a RTOS. The RTOS worked a charm but I had network comms on one cpu which also stored the whole configuration database but on the other (since I had a spare uart) handled the upload and download from a PC. In addition to this each of the cpus all had a common task (I just needed lots of capture /compare timers). For the most part the inter-cpu coms worked a treat except when doing PC upload/download - it was woefully slow and there was nothing I could do to fix it - it needed to move a lot of data that was on the other cpu. The inter-cpu comms was done using SPI as a master/slave configuration. Nowadays, I would use at least one cpu with two uarts and hopefully enough capture/compare timers or one larger cpu with 2 uarts and three tiny cpus to do the capture/compare.

In all it's like managing people. If you can offload some work onto another worker and they can then do the job without any further supervision then that is utilising everyone's time well. If you have to handhold the worker or transfer information backwards and forwards, then you are probably better doing the job yourself. These rules do not apply if you work for the government!