Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!news-peer.gsl.net!news.gsl.net!news.sprintlink.net!news-peer.sprintlink.net!newsfeed.internetmci.com!news.webspan.net!ix.netcom.com!netcom.com!vrotney
From: vrotney@netcom.com (William Paul Vrotney)
Subject: Re: ANSI CLISP: strengths vs. weaknesses?
In-Reply-To: chucko@kronos.arc.nasa.gov's message of Tue, 22 Oct 1996 18:40:22 GMT
Message-ID: <vrotneyDztM4I.Bzp@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <slrn55n3fg.5p.psci@teleport.com> <TMB.96Oct19010039@best.best.com> <1996Oct20.112936.25643@wavehh.hanse.de> <vrotneyDznMB1.CC@netcom.com> <1996Oct22.184022.11736@ptolemy-ethernet.arc.nasa.gov>
Date: Fri, 25 Oct 1996 07:29:05 GMT
Lines: 73
Sender: vrotney@netcom4.netcom.com

In article <1996Oct22.184022.11736@ptolemy-ethernet.arc.nasa.gov>
chucko@kronos.arc.nasa.gov (Chuck Fry ) writes:

> 
> 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.
> 
>     ... Stuff about his wife's Mac clone and cpu on chip caches ...

Gee wiz, I already knew about on chip caches as I suppose most people that
read this newsgroup do.  I appreciate Mr. Fry response to my question but
I feel like he is mixing apples and oranges to make a point.  I will explain
what I mean by this later.  But first, correct me of I am wrong, keeping
apples and apples, would not a pointer indirection into cache and a non
pointer reference into cache make the pointer reference only be the usual
extra one fetch cycle more costly?  And would not the pointer indirection
into RAM and the non pointer reference into RAM also only be the usual extra
one fetch cycle more costly?  If this is true, gee I thought it was, then
the statistics of pointer hits out of cpu cache can be treated now as a
separate argument (see below).

> 
> 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.
> 
> ... Stuff about using arrays instead of lists and CLOS optimizations ...

This is where I think Mr.  Fry is mixing apples and oranges to make a point.
True, Lisp suffers from this pointer cpu cache hit phenomena, but C++ does
as well.  Oranges and oranges.  Arrays in Lisp can be created with objects
of a specific type just like in C++.  C++ function calls will jump out of
cache just like in Lisp.  You can have typed local variables in Lisp just
like in C++.  If you build any pointer structures in C++ you have the same
cache problem that you would have in Lisp.  Look at any large complex C++
program and you will see a huge number of char* variables, how are these any
different from a Lisp pointer?

To say that C++ has a performance edge on Lisp (or CLOS) has elements of
truth but it is too simplistic and is not provably true for complex enough
programs.  I won't go into the reasons why this is so since it has been
repeated here so many times it sounds like a broken record.  But one thing
that I believe is easily observed and bears repeating, "The most
inefficiently created working Lisp program is by far more efficient than the
most efficiently created non-working C++ program".  And this has been
observed, at least by me, far more than any noticeable problems with Lisp
pointing out of cache.

Once again, I appreciate Mr Fry's response to my question, and this last
paragraph strays from Mr Fry's response.  But I didn't want to leave the
impression that it is somehow bad to write programs in Lisp simply because
of the cpu cache pointer problem prompted by my stupid question.
-- 

William P. Vrotney - vrotney@netcom.com
