From xemacs-m  Sun Feb  9 17:18:19 1997
Received: from jupiter.scs.Ryerson.CA (root@jupiter.scs.Ryerson.CA [141.117.18.31])
	by xemacs.org (8.8.5/8.8.5) with SMTP id RAA17495
	for <xemacs-beta@xemacs.org>; Sun, 9 Feb 1997 17:18:18 -0600 (CST)
Received: by jupiter.scs.Ryerson.CA id <11153(1)>; Sun, 9 Feb 1997 18:18:31 -0500
From: Dave Mason <dmason@scs.Ryerson.CA>
To: xemacs-beta@xemacs.org
Subject: Re: wot i need
In-Reply-To: <199702092241.OAA19401@xemacs.eng.sun.com>
References: <199702091140.AA266538445@martigny.ai.mit.edu>
	<m2d8uaduc0.fsf@proletcult.slip.ifi.uio.no>
	<199702092241.OAA19401@xemacs.eng.sun.com>
X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB
 !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP<lkW*7FT|:Dm
 9ejO^{)GHJdPQaa"C\<Ak`K27?328'V(u*|jAEZR9-z!o\^j:Cb&*tx_9\KbXD*2
Message-Id: <97Feb9.181831edt.11153(1)@jupiter.scs.Ryerson.CA>
Date: 	Sun, 9 Feb 1997 18:18:27 -0500

Martin Buchholz writes:
>[...describes benchmark...]
>
> Results (consistently reproducible to within 1%):
> 
> XEmacs/Mule:
> 7.564292073249817
> 1.530727028846741
> 
> XEmacs/Latin-1:
> 8.440415978431702
> 1.488647937774658
> 
> Emacs 19.34:
> 7.0935319662094116
> 1.3591480255126953
> 
> All were compiled with SunPro cc -xO4 and no debugging options.
> 
> It's highly bizarre that for XEmacs 20.0, the presence of the Mule
> feature makes the interpreted code faster, but the byte-compiled code
> slower.  It's well worth understanding the anomaly, and closing the
> performance gap, but it's less than 20%, and so one can live with it.

Unfortunately, while Sparcs are nice fast, cheap processors,
benchmarking with them can be a nightmare.

I have seen and heard from others (including some *big* names in
C.S. Academia) inconsistencies in benchmarking of this order.  I have
no good model to explain the inconsistencies, but they might well have
to do with instruction/data placement and cache/MMU interferences and
could be affected by something as simple as extending a string
literal!  We published a paper with a big performance spike at one
particular set of parameters because we tested many times and it was
*always* there, even thought there was no obvious explanation.

While Sparcs are the most problematic at the moment, we can only
expect things to get worse for all processors as the hardware types
try new tricks to wring a few more nanoseconds out of their chips.

There was another significant performance hit on Solaris release 2.5:
they went from making 7 register windows available to the application
level to making only 6 of them available (it might be 6 and 5, but
they did decrease by 1).  This means that anything that traverses 7
levels of call depth frequently will invoke a system trap each time
down and each time up.  This slowed TeX/LaTeX down by a *very*
significant factor (I think almost a factor of 2!).  But this effect
should not make any difference between Emacs 19.34 and Xemacs if
compiled with the same compiler.

../Dave

