| … | … | @@ -239,6 +239,47 @@ To what degree can the AtomSpace and the BackingStore API's be |
| 239 | 239 | consolidated into one? |
| 240 | 240 | |
| 241 | 241 | ### Recap |
| 242 | I've confused myself. There seems to be some interesting ideas above, |
| 243 | but I'm failing to see the reprecussions. So lets review the main points |
| 244 | again. |
| 245 | |
| 246 | * AtomSpaces contain data held in RAM. |
| 247 | * By converting a handful of methods to virtual methods, the AtomSpace |
| 248 | API would allow subclassing, such that these other AtomSpaces have |
| 249 | more complex data control behaviors, possibly by working with disk |
| 250 | or network storage. |
| 251 | * Such "more complex" behavior would be "under the covers", with the |
| 252 | atomspace user unaware of the underlying algorithms being employed. |
| 253 | The user would also lack control over these. |
| 254 | * The user would have to pick one of these, before starting to use |
| 255 | it, and is commited to using it. The user could, of course, copy |
| 256 | between this and some other AtomSpace. |
| 257 | |
| 258 | This is in contrast to ProxyNodes (and StorageNodes) which can be |
| 259 | connected (opened) and disconnected at any time. Atoms are individually |
| 260 | fetched and stored, or done in bulk. So, in this sense, the ProxyNode |
| 261 | interface is more flexible and genric. So what, exactly, are we trying |
| 262 | to do here? There was some point, but what was the point? |
| 263 | |
| 264 | Well, two: |
| 265 | * The AtomSpace API could be slapped onto any ProxyNode. This doesn't |
| 266 | "hurt anything", it just allows arbitrary proxies to be used as if |
| 267 | they were AtomSpaces. |
| 268 | * The in-RAM code then becomes "yet another" StorageNode, the |
| 269 | RamStorageNode |
| 270 | |
| 271 | What are the downsides? |
| 272 | * Cost of c++ method call increases, because it has to go through the |
| 273 | vtable for C++ calls, maybe trhashing the CPU insn cache. Whatever. |
| 274 | * Or we could leave the AtomSpace API non-virtual, and instead have |
| 275 | it call directly into the StorageNode. So this is a re-invention |
| 276 | of virtuality in C++, badly. It may be unavoidable, during the |
| 277 | porting effort. |
| 278 | |
| 279 | Anyway, this sounds like a pretty slick idea, worth doing based on |
| 280 | it's own merits. But does it solve the original issue, which was |
| 281 | that of interfacing to GPU's, and specifically, being able to |
| 282 | re-interpret and compile PlusLink, TimesLink in this new setting? |
| 242 | 283 | |
| 243 | 284 | |
| 244 | 285 | ### Are SensoryNode's AtomSpaces? |
| … | … | @@ -259,3 +300,10 @@ Writhing the above, the TODO list expands: |
| 259 | 300 | * Benchmark the AtomSpace layers/frame performance. Maybe with a variant |
| 260 | 301 | of the `LargeZipfUTest` layout, but this time with different count |
| 261 | 302 | data at each layer. |
| 303 | |
| 304 | Spin-off TODO List |
| 305 | ------------------ |
| 306 | Not immediately relevant, but tangled in: |
| 307 | * Add MessagesOfLink support to StorageNode |
| 308 | * Migrate examples and wiki pages away from cog-open, etc. |
| 309 | * Migrate examples away from TV; |