If you're running a clustered application, you've got lots of options beyond Ethernet, but you'll need to figure out what characteristics will best suit your application. Often you'll need to make a trade-off between low latency of communications and high bandwidth. In extreme situations, you may want to look at spending more money to use a smaller number of higher-powered nodes to reduce latency to memory-access rather network-access levels. And, of course, you should take a look at your application to see if there are ways of rewriting it to work better with the technologies out there.
Wikipedia offers a handy list of network technologies and nominal bandwidths that you can use to start off your research. It gives nominal speed (the actual throughput you'll get will be lower) and doesn't discuss latency.
Note that if you're not using the latest and greatest servers, you need first to look at what you've got available in terms of internal buses. You can certainly put a 10GigE card on a 64-bit 66 MHz PCI bus and run faster than with a GigE card, but you're not going to get anywhere near the network's nominal rate of 1 GB/sec or so because the bus can only do about 500 MB/sec.
As far as whether you should "use a routing switch stop Ethernet clashes," if you're talking about using a switch instead of a hub, these days that's pretty much automatic. Hubs are darn hard to find, in fact. However, not all switches are created equal; one that might handle two hosts transferring at 100 Gbps may not handle six doing the same.