Re: Interesting performance quirk.

[Gene <gene.ressler@gmail.com>]

On Oct 31, 9:41 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On Thu, 30 Oct 2008, Peter C. Chapin wrote:
>
> |------------------------------------------------------------------------||"Colin Paul Gloster wrote:                                              |
>
> |                                                                        |
> |> Earlier this year I had used QEMU on Windows (possibly not Windows XP)|
> |> to have a GNU/Linux distribution (possibly RedHat) emulated. I ran a  |
> |> Bourne shell script or a Bourne Again Shell script in the emulated    |
> |> system which made thousands of fairly short I/O transactions. The     |
> |> emulated system including its pretend harddisk were kept small enough |
> |> (no more than a few hundred megabytes) to be kept solely in the real  |
> |> physical primary memory instead of relying on virtual memory.         |
> |>                                                                       |
> |> It was faster than running the same script on Cygwin on the same      |
> |> machine.                                                              |
> |                                                                        |
> |That's interesting. I think it's probably conventional wisdom that doing|
> |I/O in a VM would be slower than outside the virtual machine. I'm sure  |
> |that's true in many cases, although the situation you described shows   |
> |that it's not always true."                                             |
> |------------------------------------------------------------------------|
>
> For clarity, I explain that the I/O of the virtual machine which I
> referred to was merely I/O to its emulated filesystems, all of which
> together plus the emulated memory were small enough to fit into the
> genuine physical memory of the host operating system.
>
> |------------------------------------------------------------------------|
> |"My program [..] the memory                                             |
> |block I work over is only 1 MB long so I don't think paging would be an |
> |issue (there is no disk activity when I run it). [..]                   |
> |                                                                        |
> |[..]"                                                                   |
> |------------------------------------------------------------------------|
>
> Your program's memory block's size might be of the order of one
> megabyte, but I do not know whether the emulated filesystems which you
> used were also small enough to fit into emulated memory. However, this
> does not explain why one program you have tried has been sped up by
> emulation whereas another has not been sped up.

Exactly right.  The most obvious explanation is that system-dependent
code or build conventions have led to some important difference in the
run-time support.  Detailed profiling is probably the only way to
figure how where.  FWIW, I remember a similar situation that finally
turned out to be explained by compilation with the Windows
multithreaded debugging libraries.  When we switched to production,
single-threaded libraries, the differences vanished or went in favor
of Windows.