From xemacs-m  Tue Apr 15 18:33:46 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id SAA03999
	for <xemacs-beta@xemacs.org>; Tue, 15 Apr 1997 18:33:43 -0500 (CDT)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.5/8.8.5) id QAA18016;
	Tue, 15 Apr 1997 16:46:19 -0700
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Cc: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
Subject: [comp.emacs.xemacs] Re: multi-threaded XEmacs lisp interpreter
X-Url: http://www.miranova.com/%7Esteve/
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Apr_15_16:46:19_1997-1"
Content-Transfer-Encoding: 7bit
Date: 15 Apr 1997 16:46:19 -0700
Message-ID: <m2wwq3svck.fsf@altair.xemacs.org>
Lines: 105
X-Mailer: Gnus v5.4.45/XEmacs 20.1

--Multipart_Tue_Apr_15_16:46:19_1997-1
Content-Type: text/plain; charset=US-ASCII

> If you take a deep look at the results you see that XEmacs's data
> segement is *HUGE* compared to others.

Just for grins try a size on src/?emacs to compare against temacs.
This looks like a bug in unexecelf.

$ size src/?emacs 
text    data    bss     dec     hex     filename
1281483 792860  184532  2258875 2277bb  src/temacs
1281483 2183496 0       3464979 34df13  src/xemacs

Something is fishy.  I thought dumping was supposed to move the
purespace into shareable text not data?  Emacs' unexecelf has the same
flaw.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

--Multipart_Tue_Apr_15_16:46:19_1997-1
Content-Type: message/rfc822

X-From-Line: News2Mail@Miranova.com Tue Apr 15 14:20:05 1997
Path: zinger.callamer.com!svr1.gstis.net!news-chi-8.sprintlink.net!news.sprintlink.net!news-chi-13.sprintlink.net!www.nntp.primenet.com!nntp.primenet.com!EU.net!newsfeed.Austria.EU.net!cosy.sbg.ac.at!sbg.ac.at!03-newsfeed.univie.ac.at!r40.cc.univie.ac.at!01-newsfeed.univie.ac.at!CARNet.hr!news
From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
Newsgroups: comp.emacs.xemacs
Subject: Re: multi-threaded XEmacs lisp interpreter
Date: 15 Apr 1997 21:33:07 +0200
Organization: CARNet Infrastructure
Sender: zcalusic@atlas.infra.CARNet.hr
Distribution: world
Message-ID: <87ohbgxerc.fsf@atlas.infra.CARNet.hr>
References: <c29208k44wg.fsf@mit.edu>  	<617micxi0i.fsf@anthem.cnri.reston.va.us> <u0tzpv7ixws.fsf@oink.mcom.com> <vwj912k4hnl.fsf@thor.dcs.aber.ac.uk>
Reply-To: Zlatko.Calusic@CARNet.hr
NNTP-Posting-Host: atlas.infra.carnet.hr
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Face: -{{$jeB1W-K.U*M}?5mPbqpi4lh3mpjD9T,~LDH/7U]*Xf9["_k>Ijnnce{CZ-ZK_%]g=vL
 cAZD>]jb0OwfLx4*;XgFN0=P7\,5a(k;szUfM0\sKEv?*MLehyoE@!M1mY:`P1w)s7WHkOg8&8oE";
 0_&*NFyrQMzNv^NW2}:Ifyx`#Rc%]7kazg49XSW>[Pe)s-0^O!Lttfv9-EYr,M2fp)VEE8p]GOiMzA
 6Zad,9ZXunk1k9MO'Yamy(?el@B8Fj1
X-Newsreader: Gnus v5.4.37/XEmacs 19.15
Xref: altair.xemacs.org comp.emacs.xemacs:989
Lines: 55

pcg@aber.ac.uk (Piercarlo Grandi) writes:

> friedman> on my poor little linux machine.
> 
> Despite some neat work by Stephen Tweedie, the Linux paging policies are
> extremely bad. In practice consider Linux as not having paging -- all
> programs should be memory resident or else if there is memory contention
> trashing will almost always happen.
> 

It's hard for me to believe this. As a matter of fact, I always
thought of Linux as system with great memory management (starting with
2.0.0 kernel, of course, because it's known that 1.2.13 wasn't very
good).

Second thing that comes to my mind is that PC machines (386, 486,
586...) "conveniently" come equipped with IDE disks, and you know what
that means when your OS start swapping.  Not only are you short of
memory, but you soon become short of CPU power. IDE disks are far from
being perfect. To experience the real power of Linux you *must* have SCSI
disks on PC (I'm assuming here that most today's Linuxes are running
on Intel architecture).

And, in the end, I did a little investigation on my own:

_XEmacs vs. others_:

A few big binaries from my Linux system:

-rwxr-xr-x   1 root     root      2042772 Feb 23 19:45 /usr/X11R6/bin/XF86_S3
-rwxr-xr-x   1 root     root       980804 Mar 16 19:17 /usr/bin/gdb
-rwxr-xr-x   1 root     root       989176 Mar 17 23:38 /usr/bin/gs.real
-rwxr-xr-x   1 root     root      4505716 Mar 26 15:56 /usr/lib/netscape/netscape
-rwxr-xr-x   1 root     root      2886684 Apr  3 14:15 /usr/local/bin/xemacs-19.15

What "size" command produces when ran on them:

text	data	bss	dec	hex	filename
3756712	737456 	55384  	4549552	456bb0 	/usr/lib/netscape/netscape
1013590	1865656	0      	2879246	2bef0e 	/usr/local/bin/xemacs-19.15
1947809	52172  	72480  	2072461	1f9f8d 	/usr/X11R6/bin/XF86_S3
806520 	27636  	62056  	896212 	dacd4  	/usr/bin/gdb
843671 	138608 	10352  	992631 	f2577  	/usr/bin/gs.real


If you take a deep look at the results you see that XEmacs's data
segement is *HUGE* compared to others.

And we know what that means when it comes to sharing memory, don't we?

-- 
Posted by Zlatko Calusic           E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
	 No sense being pessimistic. It wouldn't work anyway.


--Multipart_Tue_Apr_15_16:46:19_1997-1--

