Hi Luke, On Wed, Dec 29, 2021 at 7:14 PM Luke Peterson <[email protected]> wrote: > > Hey Linas! > > That said, I can experiment faster in Rust than I ever could in C++.
Heh. I'm not advocating for C++. In the early days of the AtomSpace, I argued strongly against it, but I was over-ruled. So it goes. I've come to peace with it. Then again, there weren't many viable candidates, way back then. > And I never ever lose days to debugging memory stompers or data races. Which > is pretty huge for me as those cost me a lot of momentum on past projects. "Doctor Doctor, it hurts when I do this" ... "well, don't do that!" FYI, some stats: * The AtomSpace itself is 2KLOC grand total, and has one mutex in it. It's used in only one file, that's under 300 LOC in size. The protected region is tiny. * The basic Atoms are under 3KLOC and have two mutexes: one for the incoming set, one for the key-value store. Both protect miniscule regions. * The atom factory is 700 LOC and uses one mutex. * The RocksDB backend is 1.6 KLOC and two mutexes So about 7.5KLOC grand total. This is not a system with great complexity. The hardest part is to figure out how to further simplify it, without hurting performance. The subsystems that actually are complex and hard to maintain: * The pattern engine. Static analysis: 8KLOC plus 8KLOC runtime: so 16KLOC total, which is more than 2x larger than the atomspace itself (!) Zero mutexes * guile bindings: 6KLOC of C++ (same size as the atomspace itself!) 7 mutexes for stuff. * assorted scheme utilities (including docs) 5KLOC * python bindings: 4KLOC has 4 mutexes, including the global python GIL lock. * rainbow of assorted atom types: 20+ KLOC of which 7KLOC is GPL boilerplate! Zero mutexes. * The vector/matrix API: 8KLOC of scheme; a handful of mutexes * Unit tests: 71 KLOC -- Note that this is larger than everything else combined, which is about 60KLOC The above numbers are meant to give you an idea of where the *actual* complexity is. Don't imagine that it is in the atomspace: the atomspace is small, and getting smaller. I'm comparing 7.5KLOC to 130KLOC of "other stuff"; the atomspace itself is about 5% grand-total of what's in the github repo of the same name. The git repo could (should?) be broken up into disjoint parts to make it more manageable. Other github repos: * "unified" rule engine: 12 KLOC source plus 43KLOC unit tests * PLN 13 KLOC plus 2KLOC unit tests * Miner: 9KLOC plus 10KLOC unit tests > So, what I wrote was not to suggest Rust is a bad fit for Hyperon’s Atomspace. Well, I'm suggesting that since the current atomspace is 7KLOC, and is "done", stable and debugged, just use that. Don't reinvent it. The issue is, I guess, the 200 KLOC of "other stuff" built on top of the atomspace; not clear to me how much of that other stuff you want to replicate. I don't understand where the boundaries are being drawn. > our use case I've been unable to find any public descriptions of hyperon. Are there any? -- 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/CAHrUA34Q7k_kgA6LjNM5cuLkQm3aEREZ_0C6zX2eLZ3a3UEkEQ%40mail.gmail.com.
