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-7-bit Path: g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad.newshosting.com!newshosting.com!novia!transit4.readnews.com!news-out.readnews.com!postnews3.readnews.com!not-for-mail Date: Thu, 30 Oct 2008 07:23:43 -0400 From: "Peter C. Chapin" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Interesting performance quirk. References: <4903c066$0$28676$4d3efbfe@news.sover.net> <49045079$0$28711$4d3efbfe@news.sover.net> <4906f908$0$5781$4d3efbfe@news.sover.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4909993f$0$5756$4d3efbfe@news.sover.net> Organization: SoVerNet (sover.net) NNTP-Posting-Host: f3a909d3.news.sover.net X-Trace: DXC=lbW9nkSeX\2_9K0=lMlDW4K6_LM2JZB_3\HMM2i_nEc9:WUUlR<856?Q^UHEST`?Z>`oNI:m8o 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. My program doesn't do any I/O during its main loop. Also 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). In some respects the program is ideal for performance analysis in that there are relatively few complicating factors involved. In fact, that was my intention when I wrote it. One complicating issue that remains is the behavior of the memory cache. I wonder if one of the programs is missing the cache more than the other. I'm not clear on why it would do that, however. The same hardware is being used after all. Perhaps the Windows compiler has organized the executable in some cache un-friendly way. Peter