Performance hit on processor intensive tasks?

[aarelovich]

Hi

Where I work we are running relatively powerful PCs using the Debian Linux Distribution. However for certain programs which we need to install it would be infinitelty better to have CentOS. Changing the OS for all of the computers in our workplace is a possibility, but we are trying to decide if using VirtualBox is a better choice for simplicity.

This all hinges on the following point. The programs we need to run are simulators which are very processor intensive tasks that can easily run up to an hour or more each time a simlation is launched. We need to decide if the performance degradation when using Virtual Box is large enough to merit our change of OS.

So my question is if anyone can verifiably tell me what is the performance hit from running a processor intensive task in virtual box versus running it on the native PC?

Thanks.

[mpack]

Impossible to answer. If the CPU isn't being shared with other processes, and if you aren't doing a lot of I/O, then the VM hit really isn't that high. OTOH people don't use VMs for the performance boost.

[aarelovich]

Fair enough.

Two things. Let us assume that the only program that will run on the host is the actual VM

The simulation itself basically creates C code compiles it and runs it.

Does this help answer the question? Do you still think that the performance hit is not that high?

[mpack]

It still depends on how your "simulation" handes I/O.

A VM has direct access to the physical CPU, but all I/O is simulated. Each I/O transaction (at guest driver level) involves at least one exception, this carries an overhead. Also the circumstances of the I/O make a difference (e.g. if disk I/O, did the VDI need to grow? How fast/fragmented/congested is the host drive?

Why not try it?

[aarelovich]

Because of the nature of the programs (installing, running and so forth), their complexity to use simply running a test is not this simple. I was tasked to ask around and do some research in order to get a better idea. Several of us thought that the answer would be a lot more straight forward.

Thank you for you time.

[mpack]

Well, the answer is straightforward - for me - being that the I/O overhead has never been high enough that I cared. I.e. it's within the margin of error I would expect when moving between randomly selected PCs. Whether you would care is impossible for me to say. You have two layers of OS managing the disk, so some I/O overhead is inescapable.

OTOH, slow graphics givers a greater perception of poor performance. The Guest Additions fix that, though they do nothing for disk or network I/O.

[aarelovich]

I'm sorry I wasn't clear.

The answer that you gave is very helpful. I was just referncing the fact that your first reply said "impossible to answer". The fact that these programs are VERY KNOWN for generating a ton of files and sometimes creating huge files on disk. However (it depends on the simulation type ). So I get this from your answer: "I/O will probably cause slowdown. Straight up CPU intensive tasks to RAM should not". Is this about right? This is helpful.

[mpack]

So I get this from your answer: "I/O will probably cause slowdown. Straight up CPU intensive tasks to RAM should not". Is this about right? This is helpful.

Yes, in general that would be correct: bear in mind however that a lot of little files being created inside the guest doesn't necessarily translate into lots of I/O on the host. VirtualBox is working at a hardware level: it doesn't see files, it sees sector (or cluster) reads and writes. Furthermore if you use the VDI format then the sectors are aggregated into 1MB blocks, which will be cached in memory somewhat. So it very much depends on the details: are these small files being allocated to consecutive disk clusters (so all inside one 1MB block)? And related: how congested is the guest disk? Congested would mean that new clusters may be spread far apart, so not in the same 1MB block. Etc.

If you care a lot about this then it's possible to keep your guest disk in good condition: defragmented on the host, defragmented block order in the VDI, plenty of free space in the guest filesystem. Some people would consider fixed size disks (to avoid the early growth overheads), but I would avoid them unless you are prepared to make them really big, assuming the host can afford that without itself being congested.