OverviewFilesCommitsIssuesDocsReleasesPeers

opencog-learn commits / 013b4aa

ParallelLink
013b4aa38c662584aa4efee9c2e590f77ef770c2
by Linas Vepštas <linasvepstas@gmail.com> · 2026-01-30T00:54:09.000Z

Changed files (1) +120 -0

learn-lang-diary/learn-lang-diary-part-ten-F.lyx +120 -0
……@@ -8622,6 +8622,126 @@ Hmm.
86228622 Later.
86238623\end_layout
86248624
8625\begin_layout Subsection*
862629 January 2026 Later
8627\end_layout
8628
8629\begin_layout Standard
8630Well,
8631 there is a way of queuing agents in Atomese:
8632 just say (CollectionOf (Type 'ParallelLink) (FooLink ...)) where FooLink returns a list of agents.
8633 Bingo:
8634 L–systems in Atomese are about this trivial.
8635 So first,
8636 two obvious caveats,
8637 and a meta–issue.
8638\end_layout
8639
8640\begin_layout Standard
8641The caveat is that the ParallelLink creates (Linux) OS threads (via c++ std::thread),
8642 so this is heavyweight,
8643 and only
8644\begin_inset Quotes eld
8645\end_inset
8646
8647make sense
8648\begin_inset Quotes erd
8649\end_inset
8650
8651 for complex,
8652 long–running agents.
8653 Now,
8654 of course one could try to optimize:
8655 perhaps by designing a GreenParallelLink that would use green threads.
8656 But this founders:
8657 when do you use which?
8658 If the agents are tiny,
8659 then running them in parallel is wild overkill;
8660 just run them serially.
8661 There's also a different way of thinking about this:
8662 inventing the GPUParallelLink,
8663 which would dispatch the agents to GPU's,
8664 one each.
8665 This then struggles,
8666 because each agent needs to access certain unknown data in the AtomSpace,
8667 and there's no way for the GPU to
8668\begin_inset Quotes eld
8669\end_inset
8670
8671reach back
8672\begin_inset Quotes erd
8673\end_inset
8674
8675 into the AtomSpace to get it.
8676 Perhaps with cleverness,
8677 this could be engineered around,
8678 but in the end,
8679 misses the point.
8680 And the point is ...
8681\end_layout
8682
8683\begin_layout Standard
8684The point is that ParallelLink is a declarative element.
8685 At this time,
8686 it is tightly coupled to a specific C++ implementation,
8687 but abstractly speaking,
8688 it should not have been.
8689 The actual implementation,
8690
8691\begin_inset Quotes eld
8692\end_inset
8693
8694under the covers
8695\begin_inset Quotes erd
8696\end_inset
8697
8698 or in some
8699\begin_inset Quotes eld
8700\end_inset
8701
8702execution context
8703\begin_inset Quotes erd
8704\end_inset
8705
8706 could be Linux pthreads or greenthread or GPU threads,
8707 or maybe just serial.
8708 This
8709\begin_inset Quotes eld
8710\end_inset
8711
8712execution context
8713\begin_inset Quotes erd
8714\end_inset
8715
8716 would be a property of ...
8717 of what?
8718\end_layout
8719
8720\begin_layout Standard
8721Well,
8722 the Atom::execute() method has the signature Atom::execute(AtomSpace* scratch) with the pointer pointing at the scratch space inside of which the execution happens.
8723 So we could create a custom AtomSpace that replaces execution methods by other algos that run,
8724 e.g.
8725 on GPU's,
8726 or green threads or whatever.
8727 So this is...
8728 well,
8729 at least partly solvable.
8730 Interesting.
8731 This is not impractical,
8732 either,
8733 it's a realtively easy project,
8734 even,
8735 to implement this.
8736 Huh.
8737 Good.
8738\end_layout
8739
8740\begin_layout Standard
8741Break for dinner.
8742 The meta issue is ...
8743\end_layout
8744
86258745\begin_layout Section*
86268746The End
86278747\end_layout