Hardware Virtualization Slower Than Software? 197
Jim Buzbee writes "Those you keeping up with the latest virtualization techniques being offered by both Intel and AMD will be interested in a new white paper by VMWare that comes to the surprising conclusion that hardware-assisted x86 virtualization oftentimes fails to outperform software-assisted virtualization. My reading of the paper says that this counterintuitive result is often due to the fact that hardware-assisted virtualization relies on expensive traps to catch privileged instructions while software-assisted virtualization uses inexpensive software substitutions. One example given is compilation of a Linux kernel under a virtualized Linux OS. Native wall-clock time: 265 seconds. Software-assisted virtualization: 393 seconds. Hardware-assisted virtualization: 484 seconds. Ouch. It sounds to me like a hybrid approach may be the best answer to the virtualization problem.
"
Sponsored by VMWare.. what do you expect? (Score:5, Insightful)
Re:Sponsored by VMWare.. what do you expect? (Score:3, Insightful)
Even so, they may be at least partially right.
Besides, if a hybrid approach is necessary, VMWare will need to adjust as well. Or am I missing something?
Re:Sponsored by VMWare.. what do you expect? (Score:3, Insightful)
It's like Apple's claim that their Intel jobbies are 5x faster - a bit silly and very, very specific...
And yes, VMWare are hardly likely to mention that Xen-style virtualisation is going to be better now, are they?
Hybrid? Good + Bad = Better? (Score:2, Insightful)
* - I imagine in real life it's not a 1:1 ratio, but for the sake of argument, work with me.
The correct conclusion is more limited (Score:5, Insightful)
The correct conclusion is not that virtualization is better done entirely in software, but that current hardware assists to virtualization are badly designed. As the complete article points out, the hardware features need to be designed to support the software - not in isolation.
It reminds me of an influential paper in the RISC/CISC debate, about 20 years ago. Somebody wrote a C compiler for the VAX that output only a RISC-like subset of the VAX instruction set. The generated code ran faster than the output of the standard VAX compiler, which used the whole (CISC) VAX instruction set. The naive conclusion was that complex instructions are useless. The correct conclusion was that the original VAX compiler was a pile of manure.
The similarity of the two situations is that it's a mistake to draw a general conclusion about the relative merits of two technologies, based on just one example of each. You have to consider the quality of the implementations - how the technology has been used.
Re:Hybrid? Good + Bad = Better? (Score:3, Insightful)
I suppose there are certain things hardware virtualisation does better.
The trick is, I'd guess, to find out which works better in which circumstances.
You see that people suspect this white paper because of its origin; they are right in doing so at least because only one type of test has been performed; surely not all computing tasks perform the same way as a kernel compile.
This suggests that VMWare have found the example which supports their claims the best; the question is, of course, whether this is the only such example.
So if we suppose that there are certain types of problems where hardware virtualisation outperforms software virtualisation, hybrid solutions seem to be the right way to go.
P.S. I don't really know what I'm talking about...
hardware v/s software (Score:3, Insightful)
Sure, the instructions may be hardcoded, coming out of ROM, or whatever, but in the end its instrructions that tell the hardware what to do. And those instructions are called "software", no matter how the vendor tries to spin it. And if the solutions performs badly, it is because the software is designed badly. Period.
Re:Sponsored by VMWare.. what do you expect? (Score:5, Insightful)
VMware's paper is a typical research paper, published at a peer-reviewed conference. This means that they have used the scientific method. The chances are 99.9999% that you will easily reproduce their results, even if changing the benchmarks.
I, on the other hand, am smart enough to see that they are stating the obvious. If you read the Intel VT spec, you'll see that Intel does nothing for page table virtualization, nor anything for device virtualization. Both are extremely expensive, and besides sti/cli, are the prime candidates for hardware assists. Intel will likely solve this performance issue in future revs, but right now, VT isn't fast enough.
Hmmm, virtualisation? Do you happen to work on Xen?
Re:Bias? (Score:4, Insightful)
wrong (Score:4, Insightful)
It may or may not be faster eventually, but that doesn't matter. What matters is that small changes in the hardware make it possible to stop having to depend on costly, proprietary, and complex software--like that sold by VMware.
Re:This is why hypervisors rule (Score:2, Insightful)
I should be sleeping.
Rich
Use Paravirtualization (Score:4, Insightful)
g
Re:Hybrid? Good + Bad = Better? (Score:3, Insightful)
Re: Use Paravirtualization (Score:3, Insightful)
Re:Sponsored by VMWare.. what do you expect? (Score:3, Insightful)
And by the way... yes... device virtualization is still not there, but your page tables claim is bullshit. If you read the VT (and the SVM) docs, you would realize that you can implement shadow page tables RIGHT NOW. The hardware assists are there.
I think that's a little innacurate (Score:4, Insightful)
It's no supprise that large, extremely expensive computers get technology before home computers do. You give me $20 million to build something with, I can make it do a lot. You give me $2000, it's going to have to be scaled way back, even with economies of scale.
You see the same thing with 3D graphics. Most, perhaps even all, the features that come to 3D cards were done on high end visualizaiton systems first. It's not that the 3D companies didn't think of them, it's that they couldn't do it. The orignal Voodoo card wasn't amazing in that it did 3D, it was much more limited than other thigns on the market. It was amazing in that it did it at a price you could afford for a home system. 3dfx would have loved to have a hardware T&L engine, AA features, procedural textures, etc, there just wasn't the silicon budget for it. It's only with more developments that this kind of thing has become feasable.
So I really doubt Intel didn't do something like VT because they thought IBM was wrong on the 360, I think rather they didn't do it because it wasn't feasable or marketable on desktop chips.
Re:The correct conclusion is more limited (Score:2, Insightful)
I read that the calling convention specified a general call instruction which was architected to do a lot of stuff - build a stack frame, push registers and so on, so even an efficient implementation will be slow. Much of the time, you could get away with something much simpler.
>I would have thought the 16(if memory serves) orthogonal registers would have made a nice
>target for compilers, contrary to the ridiculous number of (non-orthogonal) registers on x86..
x86 is orthogonal in protected mode, and register renaming helps with the low number of architectural registers. And if you're doing something intensive, you have SSE registers to use too. And x86-64 has more architectural registers anyway. So most of the architectural problems with the 8086 have been solved or mitigated.
I guess if the VAX had been as popular, something similar would have happened of course.
Re:Say whaa??? (Score:2, Insightful)