Use virtualization (or LXC containers) for ease of management and to better allocate complementary workloads according to the resources they require and to how redundant you need them to be.
Chances are your physical boxes will have one resource almost always 100% idle and having your workloads virtualized allows you to better use them.
Also, virtualization allows you to more easily fix problems - you just delete the box and rebuild it from a base image and the packages you need. Reimaging a physical box is a pain.
Obviously, if you are into HPC and very low-latency, you need physical hardware. You probably need some specialty networking hardware too and maybe less OS than most of us would like to have. But then we are no longer in the general purpose amd64 box world anymore.
I remember one instance where we were having some trouble with one batch-processing workload. The amd64 box we had for that was not enough, despite having much more memory and processing cores than its peers. I suggested we moved the workload to an almost abandoned Itanium box we had played with for some time. The HP machine crunched the workload more than 3 times as quickly. I noticed the working datasets could fit completely inside its (then) huge L3 cache (16MB, IIRC) but not in the 4MB of the amd64 machine, more or less eliminating the external memory bus penalties.
The first three paragraphs are just a marketing-speak.)
The last one is more interesting. Have you noticed that your solution was in a splitting workload, not in sharing it with other processes?
In general, splitting (dividing/partitioning/isolating) is a good idea, sharing (sharing resources) is a bad one.
Sharing, unless your data is read-only, like a txt segments of code, is a source of problems, not a solution. Partitioning, on the other hand, is a universal, natural way.
You cannot dismiss arguments as marketing-speak just because they don't fit your high-performance viewpoint, and "marketers" have made similar arguments in the past.
The first two paragraphs are about one benefit: using otherwise idle resources. At my lab, we have five powerful servers for data-processing experiments and non-time-critical analytics. Most of the time they sit completely unused. By installing Xen and running things in virtual machines, we have been able to also put tens of differently configured web servers for various small projects on each.
The third paragraph is also very valuable from experience. It has been very useful to keep documentation around how different servers are set up, and verifying that the actual setup still matches the documentation. This has been easiest to ensure by having scripts that create a new VM, install packages and make configuration changes - if in doubt, completely delete the VM and re-create it from scratch with a single command-line.
Chances are your physical boxes will have one resource almost always 100% idle and having your workloads virtualized allows you to better use them.
Also, virtualization allows you to more easily fix problems - you just delete the box and rebuild it from a base image and the packages you need. Reimaging a physical box is a pain.
Obviously, if you are into HPC and very low-latency, you need physical hardware. You probably need some specialty networking hardware too and maybe less OS than most of us would like to have. But then we are no longer in the general purpose amd64 box world anymore.
I remember one instance where we were having some trouble with one batch-processing workload. The amd64 box we had for that was not enough, despite having much more memory and processing cores than its peers. I suggested we moved the workload to an almost abandoned Itanium box we had played with for some time. The HP machine crunched the workload more than 3 times as quickly. I noticed the working datasets could fit completely inside its (then) huge L3 cache (16MB, IIRC) but not in the 4MB of the amd64 machine, more or less eliminating the external memory bus penalties.