From: Stephen Reed (reed@cyc.com)
Date: Sat Jun 01 2002 - 18:10:59 MDT
On Sat, 1 Jun 2002, Eugen Leitl wrote:
> Lisp was invented in late 50s of last century. Common Lisp by 1984. Since
> when can I buy a mature C# compiler, again? (Assuming, I'm dumb enough to
> trust a single-source "standard", especially considered the source it is
> coming from).
>
> Please demonstrate any advances in C#, Java, Eiffel or any language which
> have not been there in Lisp years to decades before.
The Cyc knowledge base was developed on Symbolics Lisp machines. Now we
perform development with Franz Allegro Lisp developement software on
Linux. We actually program in SubL (Subset of Lisp) which is a
simplified lisp dialect of our own design which trivially translates into
C code for compilation and deployment on any gcc-supported platform. Our
SubL system compiled into C contains a complete SubL interpreter and every
feature required to port arbitrary Common Lisp into SubL with the notable
exceptions:
Graphics (Cyc uses HTML almost exclusively for GUI).
Lambda closures (write functions instead)
SubL requires explicit returns from all functions via RET function
Two years ago I ported the open-source SHOP planner from Common Lisp to
SubL and it is now a part of Cyc's deductive inference engine.
So our experience at Cycorp building a Good Old Fashioned AI system proves
your assertions about the preference of Lisp for our activities. If we
represented our object store in Java rather than in our own SubL
(lisp) implementation, the storage requirements would balloon, because
Java has about a one hundred byte overhead for representing an object
instance. Regarding performance, Java doesn't know for example that the
great majority of KB objects are not going to be garbage collected, and
will have long interruptions dealing with a 400MB image. And like
Smalltalk and Allegro Common Lisp, but unlike Java, our KB is implemented
as a memory-mapped file in Linux/Win32, so you save your state by saving
the file. Java requires the creation or import of individual objects upon
application startup. Java is fine for the applications to which Cyc
interacts and I have written the Cyc Java API to facilitate system
integration.
I don't really care about whether software science has made substantial
progress in my (long) career, because my study of software engineering led
me back to the idea that AI is what software engineering needs to make
breakthrough progress. My idea for Cyc, which I will soon circulate among
my Cycorp co-workers and OpenCyc collaborators, is to represent large
grained functional activities as Actions in the KB according to the
requirements of our Planner. So each action has preconditions and
effects, and methods for accomplishing useful tasks are decomposed in a
hierarchy of sub-methods that bottom out at operations having direct code
support. Then an interpreter can use the sequence of actions generated
from the planner (or a precomputed action sequence template retrieved
from a case library), to provided the desired behavior. So the
software science advance would be the use of KB modifications alone to
produce changes in Cyc's behavior, rather than further enlarge the 1.5M
lines of generated C code.
Regarding hardware progress, our compiled C runtime produces execution
traces that use the expected RISC-like handful of integer memory and
register instructions on the x86 architecture. We use few floating point
operations. So in my opinion, processor speed/performance improvements
following Moore's Law, are just fine. Our Cyc benchmarks show speed
improvements directly proportional to the CPU MHz ratings. There is some
debate here as to how to use multiple CPU/clusters/loose peer-to-peer
configurations. I expect that Cyc would use multithreading on a multi-cpu
system, and server-to-server message-passing on clusters or P2P. Most of
the research applications for which Cyc has been used would benefit from
parallel delegation of work.
-Steve
--
===========================================================
Stephen L. Reed phone: 512.342.4036
Cycorp, Suite 100 fax: 512.342.4040
3721 Executive Center Drive email: reed@cyc.com
Austin, TX 78731 web: http://www.cyc.com
download OpenCyc at http://www.opencyc.org
===========================================================
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:39 MDT