From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,f03ffdf470e3c559
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!postnews.google.com!b38g2000prf.googlegroups.com!not-for-mail
From: Gene <gene.ressler@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Interesting performance quirk.
Date: Sat, 1 Nov 2008 08:41:01 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <bfcb4911-b11e-4d5a-ab12-c8990155b0b1@b38g2000prf.googlegroups.com>
References: <4903c066$0$28676$4d3efbfe@news.sover.net>
 <w-CdneaEgsk6ZZ7UnZ2dnUVZ_v3inZ2d@comcast.com>
	<49045079$0$28711$4d3efbfe@news.sover.net>
 <a630b4e2-2aab-4fc6-a015-15610e70f26d@j22g2000hsf.googlegroups.com>
	<4906f908$0$5781$4d3efbfe@news.sover.net>
 <Pine.WNT.4.64.0810291542190.4032@teor1>
	<4909993f$0$5756$4d3efbfe@news.sover.net>
 <Pine.WNT.4.64.0810311333110.3988@teor1>
NNTP-Posting-Host: 74.44.134.91
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1225554062 4207 127.0.0.1 (1 Nov 2008 15:41:02
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sat, 1 Nov 2008 15:41:02 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: b38g2000prf.googlegroups.com; posting-host=74.44.134.91;
	posting-account=-BkjswoAAACC3NU8b6V8c50JQ2JBOs04
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
	1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR
	3.0.04506.648),gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:2547
Date: 2008-11-01T08:41:01-07:00
List-Id: <comp.lang.ada>

On Oct 31, 9:41=A0am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On Thu, 30 Oct 2008, Peter C. Chapin wrote:
>
> |------------------------------------------------------------------------=
||"Colin Paul Gloster wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |> 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 =
=A0|
> |> Bourne shell script or a Bourne Again Shell script in the emulated =A0=
 =A0|
> |> system which made thousands of fairly short I/O transactions. The =A0 =
=A0 |
> |> emulated system including its pretend harddisk were kept small enough =
|
> |> (no more than a few hundred megabytes) to be kept solely in the real =
=A0|
> |> physical primary memory instead of relying on virtual memory. =A0 =A0 =
=A0 =A0 |
> |> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> |> It was faster than running the same script on Cygwin on the same =A0 =
=A0 =A0|
> |> machine. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |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 =
=A0|
> |that's true in many cases, although the situation you described shows =
=A0 |
> |that it's not always true." =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> |------------------------------------------------------------------------=
|
>
> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> |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). [..] =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 |
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> |[..]" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> |------------------------------------------------------------------------=
|
>
> 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.