From: James Rogers (firstname.lastname@example.org)
Date: Tue Mar 13 2001 - 11:10:21 MST
At 01:19 PM 3/13/2001 +0000, Dale Johnstone wrote:
>So you're saying that (A) memory size/speed is more of a bottleneck to
>AI than processor time, and (B) it's not worth doing anything about
>because in a few years time we'll have that anyway?
No. What I am saying is that improvements of the sort you were talking
about are marginal, assuming the basic design isn't itself
pathological. The stuff you were talking about would make things run
faster, but it would not make the difference between success and
failure. The object is presumably AI design, not performance
tuning. Differences on the order of three orders of magnitude might make a
qualitative difference, but performance differences merely by a factor of
three probably won't produce substantial qualitative differences.
So no, I wasn't saying anyone should wait (I'm not), just that Moore's Law
will generate more substantial improvements faster and most likely cheaper
than code performance tweaking; as you stated, design is more
important. However, that said, I am a performance tuning fanatic; I just
don't pretend that it will make a substantial difference in design outcomes.
>I've used Java for memory demanding apps in the past and found it to be
>a terrible memory hog, mainly because of it's poor garbage collection.
>I found it didn't scale very well at all. It seems like an odd choice,
>that's why I was asking.
I don't disagree with this at all. Most of my stuff is in C (no particular
reason, other than my C-code on Unix is always disturbingly bug-free --
must be the way my brain works) and I've been writing my own memory and I/O
managers for years. You can tweak Java to be more efficient than it is
with blind vanilla development, but I'd rather not if I can avoid
it. Generally, I just prefer to handle internals myself as long as there
isn't any substantial downside, this way I get to choose the algorithms and
implementations to suit my particular application. There are a lot of
apparently trivial internal details of any system (e.g. the specifics of a
mutex implementation) that can have large performance impacts in some contexts.
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT