Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!think!samsung!cs.utexas.edu!sun-barr!newstop!texsun!smunews!ti-csl!islington-terrace.csc.ti.com From: pf@islington-terrace.csc.ti.com (Paul Fuqua) Newsgroups: comp.lang.lisp Subject: Re: FUNCALL question, fun facts Message-ID: <111103@ti-csl.csc.ti.com> Date: 16 Feb 90 20:05:53 GMT References: <26@paradigm.com> Sender: news@ti-csl.csc.ti.com Organization: TI Computer Science Center, Dallas, Texas Lines: 31 Moon: Waning Gibbous (59% of full) Date: Monday, January 29, 1990 1:11pm (CST) From: gjc at paradigm.com Subject: Re: FUNCALL question, fun facts Newsgroups: comp.lang.lisp (1) In the MIT CADR or LMI LAMBDA lispmachine (FUNCALL F X) and (F X) compiled into *exactly* the same machine instructions. (2) The case (FUNCALL F X) where F was a local variable was very slightly, but measurably FASTER than the case of (F X) where F was a "global" (3) Symbolics and then later Texas Instruments improved on the instruction set such that (FUNCALL F X) and (F X) were indeed different, resulting in some extra overhead for the FUNCALL case, although it is very difficult to measure the difference. Regarding the TI Explorer, I beg to differ. I wrote the Release 3 function-calling microcode, which is substantially unchanged through the current release, so I have some idea what I'm talking about. There is only one batch of CALL instructions, used identically by both (FUNCALL F X) and (F X). A CALL will be slightly faster if the function is a local variable, an argument, or popped from the stack, because stack references don't involve an external memory access. If the function is global, the additional overhead is two memory references. The additional overhead of a lexical closure is mostly just extracting the environment structure and setting it up in a local variable. Paul Fuqua pf@csc.ti.com {smu,texsun,cs.utexas.edu,rice}!ti-csl!pf Texas Instruments Computer Science Center PO Box 655474 MS 238, Dallas, Texas 75265