Faster communication with host/chip

nengo / nengo-loihi

Run Nengo models on Intel's Loihi chip

https://www.nengo.ai/nengo-loihi/

Other

35 stars 12 forks source link

Faster communication with host/chip #256

Open hunse opened 4 years ago

hunse commented 4 years ago

This PR makes a number of changes that speed up superhost <-> chip communication:

Use a host snip that communicates to the superhost via a socket (faster than RPC).
Use a larger packet size.
Have chip and superhost running simultaneously (rather than one, then the other). This will add a single timestep delay between superhost and chip.

TODO:

[x] Implement communication between host and learning snip.
[x] Clean up commit history: squash timing commits, squash input channel buffering into larger packet size (the latter makes the former obsolete)
[x] Clean up code (run black on each commit, ensure pylint etc. passing)

hunse commented 4 years ago

The larger packet size 825a680 fixes #254.

xchoo commented 4 years ago

Just a comment that you need to do: sudo apt-get install g++-arm-linux-gnueabihf to get the host snips to compile. Might be something to add to the documentation (it might already be in the nxsdk docs though).

hunse commented 4 years ago

I've added a number more commits to make things faster for learning specifically.

a384ca2 takes advantage of nengo/nengo#1581 to not do checking on the outputs of our internal nodes (from builder/inputs.py), since we control the outputs of these nodes and can ensure they're safe.

6e49272 is the one I'm least sure about, since it does add a one time-step delay between host and chip (I think), but with the benefit that host and chip can be running at the same time so things are faster. It might be nice to have a way to turn this on or off.

arvoelke commented 4 years ago

since it does add a one time-step delay between host and chip (I think), but with the benefit that host and chip can be running at the same time so things are faster. It might be nice to have a way to turn this on or off.

Can this be generalized in the same way as https://github.com/ctn-waterloo/nengo_brainstorm/pull/22 in particular by allowing multiple steps of delay to buffer on both the input and/or output sides while things run asynchronously? This would be to generalize cases for both before and after this change.

hunse commented 4 years ago

It could be generalized (that's what #26 was doing way back in the day), but that's using a different mechanism (we actually buffer things), rather than just having the chip and superhost running at the same time. And even if we buffer, there would still be a performance advantage in running the chip and superhost at the same time. So I think they're independent features.