OK, thanks Julian. Just the way you said it made me think there were much faster chips we just couldn't use.
Personally I'd rather not go the emulation->multicompiled->x86 route. Perhaps it is just because of the legacy instruction set.
A system-independent OS is another matter, and perhaps that is the best route to getting there, but I'd prefer an efficient chip for my own use, at least.
Perhaps I can suggest an alternative path to fast ROS on ARM, in the absence of faster chips?
ROS has the advantage that it doesn't actually need that much power for its own use - we really only need more for power-hungry apps and funky stuff.
I mentioned at the end of the article-proper comments that multiple chips could be used, and Gulli correctly pointed out that ROS as it stands would need a lot of re-writing before it would work on them.
But why do that? You don't have to initially. Have ROS running on one. Then have each of the others receive tasks which need a lot of processing.
I'm not well-up on parallel processing architectures, but since I'm assuming they will get dedicated to particular tasks, suppose each one had its own private memory. They also need to be able to communicate. I know even less about this, but since the Iyonix has a GPU it is obviously possible somehow.
So what software would we need? I don't think it is that much (compared to rewriting ROS as pre-emptive). As I see it, you'd want SWI calls for the main system to send blocks of data to and from the 'fingers', and perhaps make them able to create interrupts in each other. You'd also need a system for apps to find out what resources were available
Each finger would need a BIOS so it could collect the initial data, and twiddle itself while it was waiting for something to do.
The big advantage of this is that (besides the hardware engineering and boot-straps), it doesn't have to all be done at once. As ROS evolves, it can delegate parts of itself to the fingers. But any apps with intensive calculations would be developed in parallel, and could then of-load the bulk of the processing to one or more fingers. Creating an archive, for example, needn't put up the hourglass. Artworks2 could spread the rendering load over as many fingers as were present.
Of course the fingers don't have to be perfectly symmetrical. For example, one could hold the frame-buffer, essentially replacing the GPU. (Yes, I know, support chips would be needed). This would have several advantages. There would probably be a cost saving, and all the power of the chip could be used since there wouldn't be a proprietary driver. Also, programmers could use the base of knowledge they already have.