Date: Thu, 17 Jun 1999 10:16:58 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Tom St Denis cc: salvador , djgpp AT delorie DOT com, allegro AT canvaslink DOT com, balug-lst AT balug DOT org DOT ar Subject: Re: [AL] Compilers comparisson, some opinions about the generated , assembler In-Reply-To: <47568953.6.19732@mx1-13.onmedia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 16 Jun 1999, Tom St Denis wrote: > >Interestingly enough, if I do something else while > >the compilation runs, like read my mail with Emacs, or type some code > >into the editor, the compilation time is unchanged. So apparently > >multi-tasking other virtual machines is NOT what steals the CPU cycles. > > Well typing into an editor has high delays which will give time back > to windows. The 'dos idle interrupt' is used by keyboard handler > which will give up time while you are typing (remember that the comp > works at 200 or so MILLION cycles and typing requires so little > time). I suppose you never looked at the Emacs sources. If you did, you would have noticed that for each keystroke Emacs runs gobs of code which takes a lot of CPU power just to keep up with my typing. Here's a short sample of the avalanche of activities that take place when I press a key in Emacs: - at least two keymaps (one local to the current editing mode, another global) are looked up for the key, to find which function this key should invoke; - for a self-inserting key, like `a', after the character is inserted into the buffer, several chains of functions that hook the buffer-change event are run in sequence; - the editor checks whether I changed the buffer enough for it to be auto-saved, and if so, invokes the automatic auto-saving; - if enough memory has been requested since the last garbage collection, the editor collects garbage, which involves sweeping the entire space of allocated Lisp objects; - the redisplay code runs, which involves looking up the character code in at least two large tables (because I can reprogram every character to be displayed as another character, or even as some string), and also the internal multi-byte representation of non-ASCII characters istranslated to their displayable glyph (that's how Emacs supports text that mixes non-ASCII characters from different languages in the same buffer); - the portion of the buffer that is affected by the insertion is scanned to change its syntax-sensitive highlighting. And those are only the immediate things that come to mind, I'm sure that I left out a lot. As another data point, consider this: the CPU Usage display jumps to 90% on an otherwise idle machine when I type. So typing into Emacs is not something I would dismiss when discussing CPU load. > If you ran two builds you would notice a huge slow down. It's not huge, it's almost exactly 50%, since the two virtual machines simply share the CPU. Which again means that Windows multitasking between VMs is quite good, at least as far as execution time is concerned. > The intitial slow down is from windows which will still swap and give > time to explorer and the start menu (I think they are seperate > tasks...). The WinTop program shows that the Explorer consumes 0% CPU. The only Windows task that consumes something visible while I type is SYSDOC32.EXE (whatever that means), and it takes something like 0.5%, sometimes goes up to 0.84%. Everything else is idling. > Also disk/io is buffered differntly under windows (VCACHE). In my experience, the disk caching in Windows is better than on DOS, because VCACHE has a smarter write-back strategy, and also because VCACHE is typically larger. For example, I usually see VCACHE using between 17 and 20 Megabytes of memory on a 64MB machine, but in the DOS configuration, I don't define such a large cache, because the allocation cannot be changed on DOS without rebooting, and I sometimes need to run programs that are _real_ memory hogs. > btw, what is this thread (in the subject) actualy about? testing > compilers or windows? The former. Given my strange experience with comparing the same programs run on Windows and on DOS, I was worried that some of the results presented by Salvadore might be skewed by these factors, since they all were performed on Windows.