Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!star.cs.vu.nl!jms
From: jms@cs.vu.nl (Jan-Mark)
Newsgroups: comp.os.minix
Subject: Re: task-switching performance again--BUG?, and gcc-386 first impressions
Message-ID: <8347@star.cs.vu.nl>
Date: 27 Nov 90 18:03:29 GMT
References: <1990Nov27.015513.27748@jarvis.csri.toronto.edu>
Sender: news@cs.vu.nl
Reply-To: jms@cs.vu.nl (Jan-Mark Wams)
Organization: VU Dept. of Computer Science, Amsterdam, The Netherlands
Lines: 31

In article ...  wayne@csri.toronto.edu (Wayne Hayes) writes:
> 
> Comic(1) is the big surprise.  It runs about 25% faster, the object
> is 53K (bcc==33K), but bcc's only needs 16K of stack where gcc's comic
> needs a whopping 135K!!!  I have *no* idea why the gcc version of comic
> needs 8 times as much stack space as the bcc version.  As has been said,
> gcc assumes you have Big $$$, Big Machine, Big Memory, etc, etc.  If you
> have the disk space and memory, it's definitely worth it.
> 
	COMIC has a ``#ifdef __BCC__'', there for the difference in
	memory space and speed. Try ``comic -V'' with both versions.

	COMIC has a speed vs. memory tradeoff. (Whereas compress has a
	compression rate vs. memory tradeoff.) So COMIC is faster if you
	compile it with 256x256 (=128K) hash table. If you can use gcc,
	(and thus have the Big $$$, Big Machine, Big Memory, etc, etc.)
	135K shouldn't be a problem for your system. If you want the
	same hash table size (and speed) with (32-bit) bcc, add (yet an
	other) #ifdef in COMIC to distinguish between the 32- and 16-
	bit version of bcc. The COMIC 1.3 has it in it. If I reach COMIC
	2.0 (more SM-DOS suffix support) I'll post it to some source
	newsgroups (and comp.os.minix).

	Jan-Mark.
> 
> Wayne Hayes	INTERNET: wayne@csri.utoronto.ca	CompuServe: 72401,3525
--

				 (:>	jms
				(_)
			========""======