From: Samantha Atkins (samantha@objectent.com)
Date: Mon Apr 16 2001 - 20:58:58 MDT
Ben Goertzel wrote:
>
> hi,
>
> >Do you have much experience with C++?
>
> Yes, and I fucking hate it. It's an awkward, oversized, nasty language,
> which is intensely painful to debug. That's why i chose Java for Webmind.
> What a disappointment to find that, all in all, for large-scale projects
> Java is even ~worse~ ;(
>
They are both inelegant languages to express ideas and patterns of much
interest. Java reminds me of Pascal in how much I have to hold the poor
brain-dead compiler's hand before it deigns to admit that it can do some
small part of what I wished it to do. It is not reflective and dynamic
enough byfar to suit me. I need a language that I can hack to fit the
work rather than hacking the work to fit the language. Lisp and Scheme
are
the closest I've seen. Ruby is great for small to medium programs and
for protyping and for "glue". It is a much cleaner, fully OO scripting
language with full GC and many lisp-ish features thrown in.
> > What did you find was more of a problem: memory
> > consumption, execution speed,
> > or distributed interfaces?
>
> Execution speed was only a problem in one sense: the strict OO nature of
> Java forces you to use design patterns that create a lot of objects all the
> time.
It would help if their library was written a bit more efficiently or
with tunability (implementation) interfaces also available. It would
also help if the JVM could just concede that a primitive type could be
used like an object for many methods that take an object as parameter.
And why the compiler cannot admit it knows what you wish when you assign
to a variable of a particular type and insert the dumb casting
constructs for you is beyond me. It is also beyond me why more
reasonable protection and visibility constructs where not included and
why synchronization is not something that can be specified in an
interface contract.
>Implementing a similar design in C++ and in Java, and using Hotspot
> to optimize Java, there isn't much speed difference. But C++ is a larger
> and nastier language, and as a consequence gives you more design flexibility
> to use an object-less, down-and-dirty pure C approach to implementing some
It also gives you the flexibility to create real pluggable frameworks
(with a bit too much finagling). This is much harder in Java and far
less efficient.
> things, when it's really necessary. In this sense, sometimes, the optimal
> Java program for solving a problem can be slower than the optimal C++
> program. Because in C++ you always have the option to revert to the most
> nasty and efficient type of C when you need to.
>
C is the universal assembly language. This is good and bad.
> Memory consumption is a really big problem with Java, and there's no way to
> get around it. You can mitigate it by using object pools and other fancy
> design patterns, but even so, Java uses at least 4 times as much memory as
> C++ for doing the same things. And that's a comparison with OO C++, not
> with down-and-dirty C written with a view toward memory conservations.
>
> > Even more mature languages only have a
> > few years on
> > Java in terms of distributed architectures, so I suspect that
> > while you had a
> > challenge on your hands with that, it wasn't the limiting factor.
> > Am I wrong
> > about that?
>
> Doing distributed programming in Java is REALLY REALLY NICE.
>
Did you use RMI or CORBA or ??? If CORBA (which has more capabilities)
then you could do that from multiple languages and/or implement
different parts of the system in whatever language most was most
efficient and palatable.
For an AI I would suspect that many things would be most elegantly and
quickly coded, debugged and easily (relatively) maintained in Lisp or
some variant. Was everyting in Java? If so, why?
> The main problem is that Java's obscene memory consumption, combined with
> the 1.2 GB memory limit on every existing JVM, forces you into distributed
> programming when dealing with relatively small datasets ("relatively"
> meaning "relative to all human knowledge" ;).
>
> There are some other technical issues too. For instance, RMI is elegant and
> easy to use, but, it wasn't made for high-volume message throughput, and
> this shows sometimes.
>
And it is synchronous only and language bigoted and too rooted in clinet
vs. server.
> Also, if you need to send messages between machines really fast, the
> serialization/deserialization of objects becomes your main bottleneck --
> it's much slower than sending messages across cables these days. And
> there's no way to fix this without going inside the JVM.
>
Or using CORBA or rolling your own message passing across sockets and so
on.
>
> Now we have a few quads left, and some smaller machines... running in the
> basement of another WM die-hard along with the mailserver, intranet, etc.
>
Under Linux, windoze or what?
> In practice, we rarely ran a Webmind with more than 7-10 of the quads at
> once
>
> > How many JVMs did you run on each machine, and how many
> > threads in each JVM?
>
> 1-3 JVM's per machine, depending on all sorts of things
>
> In terms of threads, generally less than half a dozen per process. We used
> to have an architecture that used more threads than that, but that was
> before we implemented our own internal scheduler.
>
I would be very interested in what this scheduler was like if it isn't
all tied up in the bankruptcy stuff
>
> Millions of nodes, billions of links between them. All in RAM, on a cluster
> of machines.
> That's what it takes to make an object-oriented mind!
>
Interesting. So was there an ability to migrate nodes and links around
to get improved locality of reference? It looks from the sidelines
like having your own message protocol and distribution system would have
been a win.
How much of this is either Open Source or do you and the others have
continuing rights to work with?
- samantha
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT