On Sun, Apr 18, 2021 at 1:34 AM Ben Goertzel <[email protected]> wrote:
> Linas, > > About DAS (Distributed Atomspace), this file > > > https://wiki.opencog.org/wikihome/images/1/16/Distributed_Atom_Space_-_Requirements.pdf > > reviews four potential use-cases in moderate detail. > > It would be very interesting to understand what you think is the > It takes real effort to provide reasonable and accurate revisions and commentary. Perhaps I could take you up on your earlier offer? In the meanwhile, some quick remarks: shortest path to fulfilling the requirements outlined for these > use-cases, Please be careful about putting the cart before the horse. In what is called "the spiral model of development", one builds a prototype, examines the issues, and then addresses those as appropriate. My somewhat ill-tempered response to distributed atomspaces is that it is a solution looking for a problem. If we had an algorithm that ran on the AtomSpace and it failed to fit into RAM, then one can examine strategies for making the problem smaller, or for using larger (and slower) SSD to hold those things that you don't need right away. (This is not a DAS) If there is an algorithm that runs too slowly, and would run faster in parallel, then you can build a "compute farm": distribute the data to a bunch of workers, and aggregate the results (this is also not DAS) If... well I can imagine that there are scenarios where having a DAS is useful .. but we don't have working code for any of those. The problem of building a technology like DAS for some non-existent users who might show up in the future... well, you might discover that the DAS is built wrong. It might have the wrong performance profile. It might be too clunky. It might have lots of features you don't need, and be missing features you do. Designing and building things that don't have a current use is a very risky business. This is why I encourage everyone to use what we've got: use it, come back with an actual use-case that can be benchmarked and debugged. I would also be interested to understand what if any are the key > differences between your approach and Figure 6 of > Without spending a lot of time and energy examining that document, I can't say. That figure seems overly complexticated, to me. I know that the name "Elon Musk" is very polarizing, but I do like one of his quotes: "The best part is no part. ... Undesigning is the best thing. Delete it." He's absolutely right. He's not even the first one to say that. Einstein beat him by a century: "Make it as simple as possible, but no simpler". My knee-jerk reaction is that Figure 6 is violating these maxims. Without spending a lot of time and effort to comprehend the intent of that diagram, I can't really tell. (People have remarked that Musk's latest rocket engines are the most complex engines ever built.) So in the distributed Atomspace architecture high level sketch linked > above, the sharding of the distributed Atomspace is packed into the > internals of the key-value store. If you want to have a > distributed AI process that acts separately on each shard, that is > do-able but subtle-ish. Suppose we have N machines, each of which > has on it > > -- an AI process (e.g. say some PLN logical reasoning) > > -- a local Atomspace (in RAM) > > -- a piece of the distributed persistent Atomspace, say in RocksDB > > Then of course the AI process on machine X can query the local > Atomspace specifically as it wishes. If it wants to query the > persistent backing store, it can query RocksDB and it will get faster > response if the answer happens to be stored in the fragment of RocksDB > that is living on the same machine as it. There will be some bias > toward the portion of the distributed RocksDB on machine X having > Atoms that relate to the Atoms in the local Atomspace on machine X ... > but this depends on the inner workings of RocksDB. Or at least > that's how I'd think it would work, this is speculative... > This is not quite how it works, but, roughly speaking, I've got prototypes that do this today. At this very basic level, its just not that hard. We (meaning SingularityNET) have a decently-funded commercial project > that uses the current Atomspace/OpenCog (Awakening Health, a JV with > Hanson Robotics). We are also doing, as you know, genomics research > using bio-Atomspace and PLN. And exploratory R&D using both Hyperon > prototype and current Atomspace to control agents playing Minecraft > (still early stage). So OpenCog improvements that are genuinely > useful in these applications... will be used... > Please be careful with benchmarking. The Christmas-before-last, Mike Duncan came to me and asked that I look into making AGI-Bio run faster. There was kind of this sense that the atomspace was too slow, and needed tuning. I decided to give him this Christmas present ... By restructuring the agi-bio code, I got it to run 20x faster. That's correct! Twenty times faster! This did not need any changes to the atomspace! Thus, blaming the atomspace for bad performance was inappropriate. Don't fall into the same trap with "agents playing Minecraft"! Careful making assumptions. Another thing that was careful analysis showed that the agi-bio code was performing certain types of pattern matcher queries that could benefit from caching. That caching mechanism *was* added to the atomspace. So this provides a hands-on, real-world example of where having an actual, running, testable, probable, measureable block of software allows performance tuning and design changes. Without it, no one would ever have guessed that this particular optimization was possible or interesting or useful. Having something measurable is key. (the caching did bump performance by another factor of 30%) BTW, the fixes to agi-bio were not one commit that made things run 20x faster. It was 10 or 15 commits, each of which added 5%, 10%, or 30% each. Just like compounding interest, these multiplied up. A change that improves something 10% may not feel like a lot, but it does reveal where the next bottleneck is. -- Linas -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- 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/CAHrUA34hB2a6F2cBEEDpkeOx9FShg-NWyZi1Aomr%2B01G4AP58Q%40mail.gmail.com.
