From: Ben Goertzel (ben@webmind.com)
Date: Tue Jul 17 2001 - 17:42:51 MDT
> > I'm afraid you may be underestimating the vast amount of work
> required to
> > make a scalable, efficient programming language.
>
> Perhaps. On the other hand, it doesn't need to be a vast amount of work
> put in by people on the SIAI payroll.
Creating an innovative new programming language that will operate scalably
in a clustered SMP setting is a *big* project which will involve a
roughly-Linux-scale global collaboration. (Ok, making an OS is harder than
making a language. But not more than an order of magnitude harder.)
Of course, it's hard to predict which open-source efforts will blossom into
significant global initiatives, and which will remain tiny. But it's worth
realizing that if this one does remain tiny, it will produce a prototype
language that will be useful only for prototyping.
For instance, Gofer is one of my favorite Haskell interpreters. It's a
one-man project. But it's not at all efficient or scalable -- it takes one
outstanding computer scientist and some of his students just to create and
maintain the inefficient prototype Gofer version that exists.
> While Webmind may be currently recoding some operations in C++, I'm not
> sure you'd have been so successful if you set out to work in C++ from the
> beginning. I certainly don't think C++ would be a good idea for SIAI.
C++ is a poor prototyping language. We should have switched to it sooner
than we did, but I agree that for initial exploratory prototyping, it is not
the way to go.
> As I recall from your own discussions, Java isn't scalable.
After much study and analysis, our conclusion is that the problem with Java
is that it uses a simplistic and crappy garbage collection algorithm. This
is a problem that could be easily remedied by the JVM team if they cared
enough.
A JVM, being 32 bit as all current ones are, has only 2GB max memory
available to it, no matter how much memory is in the machine itself. And a
standard Baker-style copying GC needs two spaces: from-space and to-space.
That cuts the effective available memory by 50%. And you want to-space to
be mostly empty after a GC, otherwise you'll just do another GC again really
soon and spend all your time GCing. So you'd want only half of from-space
to be actual live object at the time of the GC, and the rest dead. (Really
you'd want much less than half to be live for good efficiency, but certainly
more than half is going to kill you.) So there goes another 50%. Well,
50%+.
Based on this analysis, one would want to load < ~400 MB of objects into a
Java process...
And this analysis accords roughly with our experience. The Java Webmind
core always performed much more badly when one loaded > 500MB of objects
into it.
Ah, the power of hindsight ;>
> Maybe a more
> modern programming language, designed in an era of Beowulf networks, will
> be nicely and transparently scalable - if we handle it right.
Networking in Java is not a huge problem. There is some overhead in the
serialization and deserialization of objects, however. In modern networks,
this is slower than the actual time required to transmit an object across an
Ethernet cable. [Even if you override the readObject() and writeobject()
methods appropriately]
I am not convinced that there is a much more efficient way than the Java way
to do *general* serialization and deserialization of objects. The sure way
to make this process more efficient is to introduce *specialized* methods as
one can do in C/C++.
> Perhaps
> that will take an army of coders, but if an open-source project is cool
> enough, it can *get* an army of coders.
Agreed. I hope that Flare grows into something cool enough that it attracts
an army of great coders!! I'm all for having more and more cool,
interesting languages in the world!
> And our alternative is Python; I
> don't know whether that's more or less scalable than Java, but my guess
> would be less.
I think that using Python or Java or Lisp or whatever to build easily
manipulable prototypes, and then using C/C++ to build the real scalable
system, is the best way for you to go.
I think that one mistake I made in the early days of Webmind was to focus
too much on tool-building rather than on clarifying the concepts and designs
at the heart of the AI system. Tools are important, and most of the tools I
wanted really were good ones, but once you know exactly what AI system you
want to build, you can get a much better sense of which tools are truly
important and which are just nice-to-have.
I admire your concerted focus on your mission, Eli. But I hope you can
focus even more narrowly on the core of your mission -- the actual design
and creation of an AI. (that way, perhaps Webmind will have another species
of AI to talk to!) for this reason, I think that finding someone else to
take over your Flare project is a great idea. But if this doesn't happen, I
hope you'll be willing to let it slide for a while, and let theorizing about
Friendliness slide for a while, and get down to the nitty gritty of
clarifying your very interesting intuitions about how to actually make
intelligent software...
> I think that you strongly overestimate the degree to which providing
> a mathematical representation for code is progress toward understanding
> programs.
It's a necessary precursor, but it certainly doesn't get you all the way
there.... Understanding the intention behind the code is just as important
as understanding the mathematical structure of the code, and that's a
tougher nut to crack of course...
-- ben
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT