Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!sdd.hp.com!usc!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: Forth under Unix
Message-ID: <9012191351.AA00174@ucbvax.Berkeley.EDU>
Date: 18 Dec 90 18:15:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV>
Organization: The Internet
Lines: 31

> > ... spped comparison of C Forth 83 vs. assembly language Forth
>
> The System overheads [when running under Unix], even if you are the only
> job, will matter for small sized fast benchmarks.
>
>  Mitch, could you clarify please ?

Actually, I was comparing apples to apples; C Forth 83 and the assembly
language Forths were all running in the same environment (on a Sun
workstation under Unix, with one user).

The Unix time measurement tools separately display the time spent
executing the user program and the time spent in the operating system,
so you can get a good idea of what is really happening.

In my experience, a good Unix implementation will not slow down a
compute-bound application by more than 2 or 3 percent.  This is certainly
true on a Sun; it may not be true on a machine whose resources can
just barely support Unix (i.e. hardware optimized (crippled?) for DOS).

However, if you are running a fancy window system on a system with
inadequate memory, you can see some significant slowdowns.  The operating
system itself is not the problem though, the problem is that you have
chosen to use the machine resources for the comfort and convenience
of the user.  Even then, the slowdowns only occur when you are doing
screen I/O, and only if you don't have enough memory (at $50/megabyte,
memory is cheap; why skimp?).  Presumably, when you are doing screen
I/O, you are about to stop anyway (to give the user a chance to respond
to the information), so even this isn't a problem.

Mitch