Integrating POLite simulator and parallel placement?

[m8pple]

I've built up a bunch of changes to POLite, which are just sort of hanging around. The main changes are:

• POLite simulation : functional simulator for POLite apps
• router/mapper parallelisation : various stages have been parallelised using TBB
• PGraph/Graph optimisations : improving locality and reducing allocations in various places
• Testing : Creating a basic suite of tests based on compiling and running various apps
• Logging/timing : PGraph exposes hooks to monitor execution time and parallelism in various stages
• Hostlink retries : hostlink will try a few times to grab the TCP lock

I'm afraid it's a bit of a sprawling mess, but the tests pass. There is also a framework for SNNs in there that probably shouldn't be, though it ended up in there as part of the reason for all the parallelisation and optimisation.

I don't know how you want to handle this, as it is probably a fair bit of work to look at all the changes, and at the moment it doesn't really match the standards of the rest of the repo.

I guess one option is to rebase this branch into distinct chunks, then do pull requests for each of them? Alternative is just to keep this branch separate in order to avoid potential problems with integration and so on, as it does make some changes to hostlink, and stability is important. What's easiest for you?

[mn416]

So MUCH good stuff here! (I am intrigued to see the parallel mapper performance.)

But yeah, quite an overwhelming PR :) It would indeed help to split it up, but perhaps better would be to fork POLite into its own repo/project to explore a more ambitious feature set, and leave the basic prototype in the tinsel repo for demonstration purposes (which was one of the original intentions for it). If the PR includes any important bug fixes or useful tweaks (and maybe the testing stuff?), we should definitely incorporate those back into the prototype.

If forking a "POLiteExtra" is too much work, then the obvious thing is to keep it in a branch, however it should be advertised from the README on master, perhaps at the end of the "release log" section? Feel free to write a para, otherwise I will have a go when I get a moment.

Hope all is well with you.

[m8pple]

I felt a bit guilty after sending, as there is a lot of cruft in there. My commit discipline broke down quite early in the chain, and I've never been very good at cherry picking and rebasing - well, git in general.

There are some POLite bug fixes in there, plus some useful stuff for hostlink, so what I'll try and do (time allowing) is:

• Create a pull request for pure fixes (that will be small)
• Create a pull request for the testing (purely additive to existing stuff)
• Create a pull request for simulation (as students have asked for it, and almost all additive)

Everything else I'll think about splitting off into a separate repo if it looks like some time becomes available. Otherwise the approach of sign-posting to an unstable branch makes sense.

[m8pple]

To be continued as fragmented PRs....