Path: utzoo!utgpu!watserv1!watmath!att!att!emory!wuarchive!sdd.hp.com!ucsd!ucbvax!agate!shelby!neon!lucid.com!jlm
From: jlm@lucid.com (Jim McDonald)
Newsgroups: comp.ai.neural-nets
Subject: Re: Simple C Source
Message-ID: <2302@heavens-gate.lucid.com>
Date: 29 Oct 90 23:32:03 GMT
References: <945@heurikon.heurikon.com> <1990Oct24.024710.7346@murdoch.acc.Virginia.EDU> <1990Oct26.174757.2607@ecst.csuchico.edu> <85041@lll-winken.LLNL.GOV>
Organization: Lucid, Inc. Menlo Park, CA
Lines: 44
In-reply-to: loren@tristan.llnl.gov's message of 29 Oct 90 16:44:03 GMT

In article <85041@lll-winken.LLNL.GOV> loren@tristan.llnl.gov (Loren Petrich) writes:

   In article <1990Oct26.174757.2607@ecst.csuchico.edu> num44@ecst.csuchico.edu (Terral Jamison) writes:
   >
   >I have a few other NN source examples (mostly in C, but one in Lisp).  If there is any interrest, I'll post them, too.

	   I'll bite.

	   I'd like to see some more examples, preferably relatively
   general ones. Why is one of the examples in Lisp? I get the impression
   that a language like C is a lot faster than one like Lisp for general
   programming tasks -- no lists or other such things to keep track of.


Most of the time in NN software is spent computing numerical values--
dot products or whatever.  If those inner loops are fast, then your
application will be fast.  

In fact, since lisp compilers tend to be more flexible than those in
other languages, it is (at least in some lisp products) easier to
create hand-optimized machine-code templates that are invoked when
such inner loops are recognized.  The result can be inner loops that
are 5 or 10% faster than those in the most highly optimized C
applications now on the market, resulting in complete applications
that are overall comparable or faster than similar (but less
functional) applications written in C, even after all the "lists and
other things" have been accounted for.

If there were C compilers that allowed you to write macros to emit
hybrid hand/machine optimized assembly code (each doing what it's best
at), and if someone actually wrote such macros, applications built
with them would probably regain a few percent lead over the fastest
lisp implementations.

In practice, however, no one seems to really care about that last 2%
of speed, so it's hard to even make a business case for investing a
few days to write the macros.

In general, the lisp/C speed issue is largely a myth, but of course
poorly written lisp code and/or poor lisp implementations can be
arbitrarily slow, so your mileage may vary.  I imagine the same is
true with C compilers.

  jlm