On Sat, Apr 17, 2021 at 2:04 PM Ben Goertzel <[email protected]> wrote:
> Hi, > > > Shall I repeat again? The atomspace is already distributed, and there > are now several different ways in which this works. Actually, N ways, to be > precise. I'll describe them below. Again, I invite anyone and everyone to > try it, use it, find out if or how it meets or doesn't meet current needs > and expectations. > > Cool, yes def. Vitaly & Alexey and co. (who are leading the Hyperon > effort) will check out the current state of the distributed Atomspace > code... > The current state is that "it works". It provides "mechanism" not "policy". For example, if you want to aggregate search results from 23 other nodes, it's as easy as writing a (simple) agent such that, whenever it gets a request, it sends it out to 23 other nodes, and collects up the results, and passes those on to the next guy. Each result comes with a time stamp, so you can decide (for example), to use cached results, if they are recent enough. If I recall correctly, I designed it so that it will return any kind of executable result (not just pattern matches) so its really more of a "remote procedure call" -- you ask a remote atomspace to do something, and wait, or not, for the results. That is, you just ask for some EvaluationLink or ExecutationOutputLink, or whatever, to run on a remote node, and you get results back: Atoms or TV's. I forget the details; this got coded up last summer, as a side-effect of agi-bio work. > > Well, I'm hoping that you don't succumb to an urge to rewrite everything > from scratch. I fear that you are tempted to do this. I'm fairly certain I > won't be able to talk you out of it, if that is what you choose to do. > > We are trying to approach this decision as rationally as we can, via > thinking pretty hard about requirements first so we can carefully > assess what in the current OC codebase is best rewritten from what > isn't > > There is a Hyperon prototype now which is totally distinct code from > current OpenCog, but what relation this prototype ends up having w/ > the actual Hyperon system is also currently unclear and up for (not > that far) future decision... > I spotted that. I think it would be a mistake to reinvent the atomspace. I doubt you could do better, and I suspect you might be underestimating the amount of work it would take. This is a classic, well-known issue in software development: confusing easy-to-understand ideas with the amount of time/effort to implement/debug them. Programmers always think "this is easy" and say to themselves "I can do it in an afternoon" and it always takes days if not weeks. They're not liars, nor are they self-deluded: simple concepts really do feel like it should be quick. If the boss is asking for an estimate, the software devs are more careful. They look at a project and say "oh this should take 3-6 months". Managers take this estimate, and (secretly) multiply it by a factor of 2x to 4x. The managers report the estimates to the second line or executive, who secretly multiplies by another factor of two. The executive is usually the one with the best estimate. Again, don't take my word for it; ask a neurotypical software exec. (The green-horn execs get tripped up by this. You can google up "death march" and find hundreds of horror stories. Books are written on this kind of stuff.) You've been through this kind of stuff, certainly at iCogLabs, if not HK. It's not the employees. It's endemic to the entire industry. > > This seems an important observation, and (among other points) seems > worth remembering in the context of the goal of making a > distributed-Atomspace-DB that has "Decentralized control and > ownership" in various senses > Again, I've just offered up mechanism, not policy. The mechanism ships atoms around, and enables remote-procedure calls. Deciding who owns what, what permissions are granted, etc. -- all that is "policy". The policy layer lies above, and makes those kinds of decisions. I'm just offering a fleet of semi-trailer trucks to move things around. What you do with them is at a different level. > > You might not be aware of the AtomSpace RocksDB StorageNode. > > I'm aware of it and have seen the work on GitHub, but have never tried > it out... (whereas I did actually play w/ the postgres backing store > at one point...) > It is infinitely simpler. There's no setup! Zero setup! > > There are a lot of fancier things we want for Hyperon, but I don't > currently have any strong opinion regarding whether building them on > top of your RocksDB back-end is a workable approach. It's not my RocksDB, its facebook's. This one: https://rocksdb.org/ > Efficient > distributed pattern-matching of an appropriately (but not overly) > broad class of static pattern-matching queries is the main thing. > This has been working since last summer - it got added for the agi-bio project. It's not just "distributed pattern matching" it's "distributed execution of whatever". -- static patterns, dynamic patterns, simple ones, complicated ones - things that aren't patterns at all but are something else -- it doesn't care, it does them all. Again: its mechanism, not policy. The route to efficiency is subtle. Clearly, bad policy ruins efficiency (if your truck freight dispatcher is telling empty trucks to drive around, then, yes, you get terrible efficiency. That's bad policy, and you can't pin the blame on the truck driver. Again - I'm providing the atomspace equivalent of trucks. How you use them is... up to you.) To continue the analogy: maybe the trucks are too slow. Making them faster is called "performance tuning" and its ... well, most software devs hate to do it. Don't know how to do it. It's an art usually left to specialists. And then more analogies: perhaps you realize you needed boats, not trucks. Well, that's a different matter. There are any number of software-dev stories where half-way through the project, the executive realizes that boats don't work on dry land. I kid you not. "Requirements gathering" and "writing code that meets requirements" is what made the Dilbert comic strip funny. People laughed, because it was a microcosm of real life. The only way out that I know of is iterative prototypiing. You build one, and use it, and if it works, great, and if it doesn't you make it better. The more build/use iterations you can go through, the faster you learn. (The biggest problem with the atomspace (or opencog in general) is it has very few users. Which breaks the prototype/use iteration cycle.) --linas -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34XMKWBxEdBabi866k81GxQ0DLF%2BqksiU-3o%2BvuakMrhQ%40mail.gmail.com.
