Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.acsu.buffalo.edu!news.uoregon.edu!arclight.uoregon.edu!nntp.primenet.com!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!news.reference.com!cnn.nas.nasa.gov!eos!kronos.arc.nasa.gov!chucko
From: chucko@kronos.arc.nasa.gov (Chuck Fry )
Subject: Re: ANSI CLISP: strengths vs. weaknesses?
Message-ID: <1996Oct22.184022.11736@ptolemy-ethernet.arc.nasa.gov>
Sender: usenet@ptolemy-ethernet.arc.nasa.gov (usenet@ptolemy.arc.nasa.gov)
Nntp-Posting-Host: cassini.arc.nasa.gov
Organization: Caelum Research Corp., Code IC, NASA Ames, Moffett Field, CA
References: <slrn55n3fg.5p.psci@teleport.com> <TMB.96Oct19010039@best.best.com> <1996Oct20.112936.25643@wavehh.hanse.de> <vrotneyDznMB1.CC@netcom.com>
Date: Tue, 22 Oct 1996 18:40:22 GMT
Lines: 65

In article <vrotneyDznMB1.CC@netcom.com>,
William Paul Vrotney <vrotney@netcom.com> wrote:
>In article <1996Oct20.112936.25643@wavehh.hanse.de> cracauer@wavehh.hanse.de (Martin Cracauer) writes:
>> This begins to be off-topic, but the lookup mechanism of ObjC requires
>> one pointer indirection more than the C++ virtual function
>> call. Pointer indirections can be very expensive given today's memory
>> bandwidth/CPU speed relation. 
>
>Actually, I was always in complete agreement with the original poster's
>remarks comparing C++ to Objective-C.  I was also under the impression that
>pointer indirection was not very expensive on many modern day computers.  So
>could you please explain what you mean by this last sentence.

It's very simple.  CPUs are increasing in speed very rapidly.  By
contrast, main memory has not improved in performance nearly as
rapidly.  80 nanosecond memory worked well with the 25 MHz
processors of a few years ago; today processors are an order of
magnitude faster, but memory performance has hardly improved.

For an example, let's take my wife's Mac clone, a PowerCenter 150, a
midrange personal computer by today's standards.  This machine has a
PowerPC 604 as its central processor, running at 150 MHz.  The 604 can
execute multiple integer instructions in one clock cycle, which is
about 6.6... nanoseconds (ns).  I think memory reference instructions
take at least 3 cycles, and that's when the on-chip cache already has
the data.

Main memory on this machine has an access time rating of 70 ns;
various intervening devices and speed-of-light delays add another few
ns.  By my reckoning, it takes at least 12 processor clock cycles to
retrieve data from main memory, and the bus is busy for some time
after that.  The only other PowerPC instructions that take this long
are floating point divisions.  *That* is the cost to chase a pointer
in today's systems!  And that's in addition to the usual function
calling overhead of saving and restoring registers, etc.

When you are trying hard to squeeze cycles out of an inner loop, that
~100 ns per indirection starts to add up.  Caching can help somewhat,
but only for the most frequently referenced routines.

Like it or not, the implications for Lisp aficionados are obvious.
Modern processors work fastest when memory references are minimized,
and when the remaining memory references are primarily in linear order
to maximize cache hits.  C++ has a performance edge on CLOS in this
respect.

One thing that can help is optimizing out unneeded indirections, both
in source code (e.g. by using vectors or vector-based structures
instead of lists, inlining short functions, etc.) and in the resulting
compiled code.  Here the compiler builders can definitely give us a
boost.

For example, CLOS code in particular could benefit from partial
evaluation and faster method discrimination strategies that reduced
the number of memory references.  As another example, Symbolics some
years ago provided the Optimize World feature, which performed such
optimizations as replacing indirect function calls through symbols
with direct calls to the corresponding compiled functions.  The old
Lisp Machine CDR-coding hack would be a help too, especially now that
64-bit processors are becoming commonplace.
 -- Chuck
-- 
 Chuck Fry  Work: chucko@ptolemy.arc.nasa.gov  Play: chucko@best.com
	I alone am responsible for the contents of this post.
	      Keep NASA and Caelum Research out of this.
