Hacker News Reader

Comment by Someone1234 | Hacker News Reader

With all due respect: I don't buy it. That isn't how the technology works. Compilation in particular would never even hit the hypervisor layer regardless of which one you were utilising. It is CPU/memory bound.

The difference between hypervisors for IO is tiny. They're all slower than native, but vary very little between one another. That's why the manufacturers have all almost given up trying to use performance for comparison, and instead argue value adds/management/automation/cost.

If you really found one specific hypervisor slower than another (regardless of which two), I'd want to look at your exact test conditions since that has never been the case for me (everything else being equal). And even the manufacturers don't argue that point much.

There are plenty of reasons to e.g. pick AWS over Azure, but Hyper-V performance is not one of them. That's just FUD.

View on HN

You're missing something very significant: Compilation jobs involve a lot of forking. Forking, memory accesses, and TLB differences across various VM architectures can have an enormous impact on performance.

For example, we found two orders of magnitude performance difference between PV and HVM on ec2 on fork-heavy CI jobs. A difference between 3 and 30 minutes. This difference is trivially reproducible by measuring the time taken to complete a fork() syscall. As the memory size of the parent process grows, the difference becomes more pronounced.

Here's actual data I collected from c3.large instances, using a contrived Ruby one-liner to benchmark fork():

PV: [ec2-user@PV ~]$ ruby -e'$ref=[]; (24..29).each {|n| $ref << "X" * (2 n); start = Time.now.to_f; fork.nil? and exit!; puts Time.now.to_f - start; sleep 1}'

0.00550532341003418

0.011992692947387695

0.02542281150817871

0.05213499069213867

0.10562920570373535

0.21283364295959473

HVM: [ec2-user@HVM ~]$ ruby -e'$ref=[]; (24..29).each {|n| $ref << "X" * (2 n); start = Time.now.to_f; fork.nil? and exit!; puts Time.now.to_f - start; sleep 1}'

0.0005323886871337891

0.0007219314575195312

0.0012335777282714844

0.002183198928833008

0.004210233688354492

0.008102178573608398

As you can see, the difference is considerable. This is all on Amazon ec2, the only difference between these VMs is PV versus HVM.

(edit: HN formatting seems to be eating the exponent operator in the "2 to the n" expression. It's a double *)

that wasn't always the case. i remember times where pv could be faster on a lot of forks. however you can't compare pv/hvm vs kvm vs hyperv since the difference between pv and hvm is caused by a totally other aspect than the comparsion between hvm, kvm and hyperv. also note hyperv got way better in windows server 2012.

also note that fork() involvs "lots of" io computations which could also be a driver problem and they evolved in newer kernels, too. and also fork() could syntactially be different on hosts with ballooning and hosts without. especially on kvm.

edit: as of today we switched to hvm instances (however we are on many many micros so that performance boost is likewise zero) on our inhouse hardware we are varying between kvm and vmware. however I dislike vmware more and more. vcenter is just unusable (flash) and consumes a shitload of memory. so mostly we use vmware api calls which makes vmware unnecessary somewhat. also we sell our software as a appliance with a xenserver host and mostly we tested our software an all ends and we are mostly disk io driven and that barely changes between them. there are some aspects that could improve performance but that depends more on how you configured your virtual disk.

>that wasn't always the case. i remember times where pv could be faster on a lot of forks

32bit, or 64bit pre-virtualization hardware extension (vt-x/d, ept, amd equivalents) are really the only ways this should have been the case. Each time you make a fork() system call on 64bit PV you're making an extra context switch and flushing the TLB that an HVM instance does not need

I don't buy it either and it is not my experience. My bad experience with hyper-v was running a desktop Linux but was expected because other factors like 3D/2D acceleration are not supported.

I would expect a full description of the benchmarks and setup to follow up.

I have a developer who can show a marked difference in performance between VMWare Fusion (paid) and VirtualBox (free) running Windows 7 on OSX. Same Windows ISO used to install both, and both running on the same hardware and OS, with exact VM configs (as close a you can get between the two). I'm talking a night-and-day difference - VMWare Fusion is usable, but VirtualBox is not.

After reading your comment, and admittedly not knowing much about hypervisors (yet), I am genuinely curious as to what else could be causing this drastic difference in performance, if not for the hypervisor itself. Any ideas?

I was more talking about actual hypervisors that run on hardware. Client hypervisors (those that run on an underlying OS) are an entirely different thing.

Real hypervisors are utilising a lot of hardware features to accomplish jailing. Client hypervisors may or may not be, depending on how they're implemented, and or how they're integrated into the underlying OS (e.g. specialised drivers, just simulating hardware features, etc).

That's not a very good example since both of those are desktop applications providing virtualization and are expected to play nice with other desktop apps. You can virtualize in a web browser too, but that doesn't make it a good high performance idea.

You should be looking at dedicated virtualization hosts to do an apples to apples comparison, like vmware on bare server metal vs hyperv or any of the free tools also on metal. Not on a cpu throttled desktop.

There is a big impact in performance if you are running a graphical user interface instead of a server only with the console. VMware put more efforts in the UI than other vendors.

I would always separate benchmarks for server or desktops.

I'd be interested in the same test with the latest VirtualBox 5 - you can use HyperV by switching a setting in the VM control panel.

It might be worth your time to run that same benchmark without any hypervisor to establish a baseline.

Reply on news.ycombinator.com