Your question is really missing critical informations about your setup, so answer cannot catch all possibilities.
But if we assume the typical Arduino setup, than the sensors would not use 8 wires, but some serial protocol (Serial, I2C,...). Especially if you mentioned multiple of them.
Also usually processor asks sensor for data and sensor reply with values, not that sensor is spamming the processor on its own (or not more, than sends interrupt, when data are collected)
Also they would probably not send data to both processors simultaneously, as it would mean, that both processors would be blocked by reading one pice of data - better setup is to send half sensors to one processor, second half to other and synchronise only minimum of processed data between processors.
So the speed of the protocol would be one of very limiting facts here (400 kbit/s ~ 50 kbyte/sec for fast I2C on 16 MHz Arduino means, that while receiving one byte=8bits, your processor is able to do like 16.000.000/50.000 = 320 instructions, for asking sensor for value you address the sensor and send register number, so at least 3 bytes are transferred, also there are some kinds of handshaking - so we have more like 960 instructions per byte) and the transfers usually cannot go in parallel, as they are using the same wires.
- two processors would be able serve more data, as each of them can have its own data line and so two sensors can be questioned in paralel. 900 instructions may be enough to do some simple data manipulation over collected values.
- 16-bit processor cannot generally process two independent data in one instruction, even if it have 2x longer registers. So the there would not be gain from longer word in this way
- on the other hand 16-bit processor can make computations faster if it comes to bigger data types, like int/long/real (to contrast only bytes), many times more than 2x faster. But jumps, loops and so are not such faster, as well as 8-bit calculation. So it deeply depends on how you process the data (how much computation and what kind you do).
- if the sensors would send data only occasionally (as many sensors need a time to collect something) and you would do a lot of complicated computations over them, and those computations would need (nearly) raw data from all sensors (not just average over half second or so), then the 16-bit can win with sheer computing power and lack of need to synchronize data over more units
- if there would be too much data from sensors and such data could be computed independently and mainly in 8-bit logic (
if (dist <128) near=true;), the 8-bits can win with two communication lines to sensors and two computing units (so 2x number of instruction/sec) - but in robotic it is not so simple usually (left half of robot is not independent from right).
- for many cases also the size of disposable RAM is factor
- complexity of programming differs in single-unit(16-bit) and two or more networked units (8-bit)
- Many Arduino libraries and examples are not very excellent, when it comes to parallel processing more inputs at the same time (first of all you must have forgot, that something like
delay() exists, then lot of communications (like Wire for i2C) happily waits for the full request fulfilled (so waste a lot of instructions just waiting for communication be completed))
- so you can spend more time in inefficient library implementation than in the rest of program. This is not problem for simple scratches, for which Arduino is planned, but is serious limitation in more complex computations
- so you may use different approach to the same HW and use AVR rather then Arduino way (but it needs a lot more skills and knowledge).
- Lots of 16-bit processors have a faster clock, more RAM and more and more elaborated HW build in devices, so they can do even more work faster. Some have two or more I2C subsystems, so they can communicate with two buses at the same time and share the results inside without transferring them around
- so usually you have two different architectures which cannot be simply compared with just "it has the same clock, but 16-bits"
So your question cannot be answered simply, without knowing what sensors you are going to use, how many, which processors you are considering, how you want process your data and what peripherals you want to manipulate.
If you are all confused now, then simply start with the processor you currently have and just few sensors and try to solve only small part of final project. You will learn a lot along the way.
- If it works with one sensor but not two, you have problem in your programming and you have the simplest case to learn, how to solve it.
- If it works with four sensors but not five, you are probably hitting some limits
- try to measure, where you spend more time, if in the logic, or the communication
- if communication is the main problem, try other libraries or more independent processors
- if logic is the limit, use better algorithm or faster processor, or split it in net, if everything else fails
- if you hit RAM limit reconsider the algorithm, or use processor with more RAM or try to split it to two cooperating units, each with half of sensors
But first of all - start playing and having fun, usually it is much faster way to some results, then theorising over all possible details of the Death Star Project at one time before you manage even driving straight with two wheels.
intfor computing with two different
bytes (both arriving at different time probably)? There are some ways, but usually not easy and not fast. You would understand better, if you try to write even easier program to manage two sensors at the same time in one variable - your result (if you would not drop it before) would be probably totally unreadable, long and prone to errors. And much slower, than doing it sequentially and independantly. Just try it with any non-totally-trivial task :) $\endgroup$