Are you both sure of your setup for the *.core version ?
especially wrt those values:
“4500 potential radius and 75% potential pool over a 1D 9000 input, 9000 output SP ?”
htm.core ain’t even able to finish “initializing” segments on my desktop in any bearable amount of time, swallowing gigabyte after gigabyte with that setup.
“Default-init” at radius 16 and 0.5 for those results was more likely…
cuz calling spGlobal.setPotentialPct(0.75f); and spGlobal.setPotentialRadius(4500); after sp constructor won’t help…
That would be 17 potential synapse per input cell. (Which was reported in the output of “HelloSPTP” on my run when leaving everything as it was).
When instead, full radius over 9000*75% is more like 6750 synapses. Per input cell. There are 9K of them. Everything blew up, with htm.core way of storing those synaptic info on SP (60.75 millions times a ‘SynapseData’ structure weighting 32 bytes, was part of the problem), when those radius and ‘pct’ (a ratio, but, well) values were indeed the ones used at init.
Now, that issue aside,
htm.core Compiled MSVC2017, Release x64, run under Xeon CPU E5-1620 v3 @ 3.5 GHz, I get:
with 1D, 9000 input, 9000 output, potential radius 16, potential ratio 0.5:
about 0.55 ms/iteration for SP alone (global inhib, no boosting, learning enabled)
which is great. However, it also scales quite strongly with radius…
with 1D, 9000 input, 9000 output, potential radius 32, potential ratio 0.5:
about 0.68 ms/iteration for SP alone (global inhib, no boosting, learning enabled)
with 1D, 9000 input, 9000 output, potential radius 48, potential ratio 0.5:
about 0.78 ms/iteration for SP alone (global inhib, no boosting, learning enabled)
So, in 2D, with even default radius of 16… you’re brought down significantly to:
with 2D, 95x95 (9025) input, 95x95 output, potential radius 16, potential ratio 0.5:
about 4.5 ms/iteration for SP alone (global inhib, no boosting, learning enabled)
… after a several-seconds-long init phase… (of SP only)
@gmirey Thanks for re-visiting this issue.
Yes, the plot in my original post is measure using NuPIC.core. (Not HTM.core (NuPIC.cpp at the time))
I have recently posted an issue regarding the exact problem. It seems that somehow, HTM.core is super fast in their test case but super slow in my code. But non of us (both framework authors) knows why. Maybe the code there can help? Maybe we missed something important.
Hi Martin, Yes, I know you used the original nupic in your plots
I haven’t looked up the TM part of .core in detail yet.
But I’m quite positive the reported good results of htm.core SP wrt your setup this summer is due to a wrong test setup for htm.core
@marty1885 I’m pleased to see that Etaler has made quite a bit of progress and that you’ve been trying to use it in practical applications. I’m seeing a lot of parallels in the design decisions you made with our internal HTM implementation at our company. Of course, I think you’ve made much more extensive use of C++ templates, the tensor approach, and threading libraries.
We have an OpenCL backend as well, a python wrapper, as well as a client-server model. We also have a number of tools that we developed for practical use as well as some new things that haven’t been developed before. We’re targeting a public release of our project in April some time.
I think yours and our project could benefit from some merging or at least integration of various parts since I think we used the same languages but have complementary strengths. I think you focused a lot more on speed, but we focused more on applied algorithms and some research.
Regardless, I’m looking forward to your eyes in April and sharing what we’ve been working on. I think you will be very interested and excited.
@jacobeverist, not to put a fire beneath your (company’s?) buns, but if you don’t release something, I’ll be doing that here by end of June, serving my take own HTM as a platform (send in a JSON config file of your HTM graph and connected layers, send in data, get compact SDRs (spatial pooler and temporal predictions along with anomaly score).
Already doing some early prototyping of HTM-based state machines for IO modulation and control that I’m trying to cram in as an optional top-level module.
Sadly no. We are still going through the release process which requires several layers of management approval. This is not something our company is accustomed to doing, so the process is a little rusty. Things are in motion our software is looking pretty neat. I think people will be very interested in some of the new things we’ve done.
