From: Michael Roy Ames (michaelroyames@hotmail.com)
Date: Sun Mar 03 2002 - 10:47:22 MST
Ben,
Your recounting of experiences with Webmind makes for fascinating reading.
I have many questions - but for now I'll limit myself to two.
You wrote:
>
> Dealing with distributed processing so early in our project was a
> significant mistake, because it took a lot of effort, and a distributed AI
> system is vastly harder to debug than an isolated one. There are no real
> testing tools that handle distributed nondeterministic self-organizing
> systems. Testing tools for distributed systems that exist at present are
> *very* simplistic and limited, mostly focused on application server
> setups.
I have thought on this problem a little - the problem of how to
monitor/track/debug a process distributed across multiple independent
machines. Most of my 'implementable' ideas (as apposed to 'crazy' ideas)
have been based on the 'transaction' paradigm. Processes churn away in
multiple threads, multiple machines, at different speeds, and when they have
a result of some kind, they 'commit' that result to a central location. At
this point the result becomes visible to any other process that cares to
look, and also to the operating console - or debug module - whatever it is
you want to call it.
Your reply didn't say how you solved this problem... did you? Or haven't
you got there yet?
>
>
> Consider two scenarios:
>
> A) You have X amount of RAM on one machine, with P processors on
> that one machine.
>
> B) You have the P processors and X amount of RAM spread among K
> machines, where P/K is small (commonly 2-4)...
>
> Our experience was that the speed of configuration B was *after copious
> optimization* about 1/5 that of configuration A. This is not because of
> network latency, it's because of all the software stuff you have to do to
> make your system distributed-processing-friendly. It's possible this could
> be improved to 1/3 or so. We did a lot of work on this in Java but also
> some prototyping in C.
>
> Also, the effective amount of information you can store in configuration B
> is about 2/3 that in configuration A, because of the need to repeatedly
> cache information to achieve reasonable time-efficiency.
>
This jives with both my own experience building
boring-old-business-applications, also with my study of other's software
solutions to difficult problems, and with personal experimentation.
My current guestimate as to how CPU cycles will be allocated to run a
General Intelligence is:
40% - What ve's thinking about
- Keeping track of Data - Basically: Database services
40% - How ve's thinking about it
- Keeping track of Process - Messaging/IPC, O/S, Load Balancing,
Clustering/Parallel-Processing
20% - Actual thinking
- "AI" algorithms - Sensory Modalities, Concept Manipulation, Goals,
Predictions, Decisions, Actions.
It might seem strange/inefficient/just-plain-nuts to expend 5 units of
'effort' in order to make 1 unit of 'progress'... but I cannot see any way
around it. <---(Super Geniuses please insert 'Way Around It' here)
Ben, how closely does this correspond with your experience so far?
Michael Roy Ames.
Ottawa, Canada - michaelroyames@hotmail.com
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:37 MDT