From: Ben Goertzel (ben@webmind.com)
Date: Sun Apr 15 2001 - 10:07:14 MDT
Obviously, this is an issue about which I have a great deal of practical
experience
I'll just make a few points, gained from 3 years doing AI development
experience in Java
Firstly, development is clearly faster in Java than in C/C++. Not having to
debug malloc() errors is nice.
Java, if you use HotSpot, is no slower than C++. It is surely still slower
than a speed-optimized C program, but not by an order of magnitude
A Java program uses about 4 times as much memory as a comparable C++
program. There's not much you can do about this. Also, all current JVM's
on all current OS's are limited to about 1.2 GB of RAM per Java process.
(Sun promises a 64-bit JVM, someday, but, well...). So, if you want an AI
program with a lot of data in it, and you want to use Java, you're pushed to
deal with distributed processing pretty early in your work. Distributed
processing, however, slows down processing a lot. With a lot of work, we
got the performance of a distributed system in the range of 5-10 times
slower than that of a comparable 1-JVM system with the same amount of data.
The bottleneck turns out to be, not the actual network bandwidth, but the
time required for Java to serialize/deserialize objects. One can minimize
this by overriding the readObject() and writeObject() methods [custom
serialization], but this has limited value, unfortunately.
Furthermore, garbage collection in existing JVM's is fantastically
inefficient for programs creating billions of objects. It seems that the
JVM is not tuned for truly large-scale applications.
And, there are no existing Java profilers that will profile a large-scale,
multi-threaded Java system. Quite literally, they all crash when applied to
such a program. For this reason we have created our own Java profiler. [The
reason the commercial profilers crash is that they try to report all events
in the program to their GUI's, and the Java GUI tools are not able to deal
with such a high volume of data. Our profiler just saves events in a log
file, which avoids the problem.]
There are also no adequate debuggers in Java, when one is creating a
large-scale software system.
Finally, there are not as many useful 'peripheral' software tools in Java as
in C++. To take a random example that's come up in my own work, graph
visualization toolkits in java are vastly worse than those in C++. Advanced
math libraries are harder to come by. Etc.
The main practical problem we've found using Java, then, is this. Using
Java, we created a system that uses so much memory that we were pushed to
work with distributed processing very early on. Distributed computing is a
whole science unto itself, which we've mastered, but it took a lot of time.
No one had ever built a really adequate Java distributed computing framework
before we did. (I'm aware of things like JINI and Voyager, but they all
have pretty dire shortcomings.) Next, because of requiring distributed
processing to do anything involving large volumes of data, we have a system
that's pretty hard to fiddle around with, due to the slowness of the system
and its multi-machine nature. But the nature of a complex AI system is that
it does require a lot of informal adjustment and experimentation by the
human programmer. (Sure, maybe you can come up with a simple panacea for
artificial thought that doesn't require any experimentation to "get right."
If so, you'll be doing a lot better than evolution did -- evolution spent
millions of years doing adjustment and parameter tuning.)
What a few of us are doing now is taking the most essential aspects of the
system and re-coding them in C in a very simple and specialized way. We're
not dealing with distributed processing in this experimental version yet.
We just want a simple system in which we can play around with the
interaction of the various AI components of the system, freely and easily.
In a couple months we'll deal with the reintegration of this into the main
codebase, using JNI, which works very nicely BTW.
In sum, I'd highly recommend Java for small-scale engineering projects.
It's a fun language to work with. But for large-scale projects (meaning,
systems that will use a lot of memory and a lot of threads), my advice is to
stick with C/C++. Java is just not tuned for such projects, and you run
into a hell of a lot of annoying problems that waste a huge amount of time
and effort, far outweighing the savings in programming time.
LISP is a nice language too, and there are some fast LISPs. But in
large-scale use cases, they have the same garbage collection inefficiency
problems as current JVM's.
Even if your artificial brain consists of 100 lines of code because your
theory of mind is so beautiful, it's still going to need to use up all
available RAM, and it's still going to want to use multiple processors when
available (i.e. multiple threads). You'll still have a large-scale program,
for which Java will cause memory bloat, forcing you use distributed
processing, which will turn your 100 lines of code into many more, which
will mean you'll need a profiler and debugger, which don't work for
large-scale programs like yours, blah blah blah ... you get the picture.
-- Ben
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT