Do we have performance numbers for SDR library?


I was wondering if anybody in the community or at Numenta had done any recent performance numbers only on the SDR library as far as creating unions, checking agains’t a union, or other SDR operation with 1000s, 1M or more operations/sec?

Anybody interested in trying to do it? If nobody has done it, I may perform some performance analysis.

As much as I think SDRs are essential, our current implementation doesn’t scale on multiple machine, and could one day be an issue. I think we want all the benefits of what SDRs give us (as per Matt’s incredible HTM School videos) but I am wondering if anybody but me thought about implementing them with current parallel graph engines technology?




Good questions. @mrcslws might have some insight into fast SDR operations using sparse matrices in C++?

I would be interested in writing a paper that compares Numenta’s SDR implementation with (any other) libraries for that.
And on technical side that measures the performance and tries to optimize it.

I think there is a github issue on nupic , nupic.core for that.

@breznak I’ll like to help out if possible. I’m interested to see how it stacks up with Eigen’s Sparse Matrix or Blaze’s version.

I have set up a Visual Studio solution with nupic.core and setting up tests should be easy for me on Windows.

1 Like

Cool, let’s write a study together!

I’ve been toying with eigen too… Are you suggesting to compare HTM with Eigen (HTM would lose heads down, imho), or to test in implementation atop of eigen?

Let us brainstorm what could be benchmarked and whether to base it on nupic.core / nupic (py), or doesn’t matter.

My ultimate goal is to evaluate if we can use Eigen or Blaze in nupic? The way I understand it is that nupic works with sparse matrices and extends it with some nupic specific functionality. Think, extending Eigen version with some more member functions.

I would prefer testing on c++ first.

My some people in community have some ideas what the best tests might be?

@rhyolight this being an experiment/example, we should place it in nupic.research, right? (it will use nupic, nupic.core as needed)

No, but:

1 Like