[evan_miller]

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 *)

[merb]

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.

[cthalupa]

>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