Step 8 - tidying

[neworderofjamie]

This has reached the stage where things can't be seperated so nicely so this encompasses the following:

Deletions

• SpineML + test - the deletion can easily be reverted down the line if we need it again and nothing we've changed is fundamentally incompatible
• Script for creating statically-linked C++ projects - post Step 3 - Dynamic loader #602 these aren't used
• Makefile infrastructure for installing C++ GeNN at a system level - C++ is a minority concern and the concept of a system-level install is totally incompatible with Python.
• C++ userprojects - if people want to play with them they can check out an old version of GeNN

Fixes

• Spike timings were pretty broken after Step 6 - Fused event generation and postsynaptic spike-like events #609 and I introduced a very nasty thread synchronisation bug - have fixed
• Parameters were not being correctly wrapped in PyGeNN when creating sparse/toeplitz connectivity snippets
• Re-enabled lazy-compilation so nothing gets compiled when models don't change (this was disabled mostly because it's very annoying when heavily developing GeNN itself!)
• Re-enabled NCCL in a slightly nicer way via a new backend-specific State object owned by Runtime (previously it was hacked in and just threw an exception if you weren't using CUDA)
• Presynaptic update groups should only output via shared memory if all groups are smaller than block size - at some point I broke this
• Fixed BITMASK connectivity, made memory layout the same whatever algorithm is used and moved selection of 'word-packed' algorithm (Bitmask connectivity optimizations #280) to per synapse group SynapseType::ParallelismHint rather than backend preference.
• In general I had been switching from tree-based std::map and std::set to hash-based std::unordered_map and std::unordered_set as access time is O(1) rather than O(log(N)) but after much debugging, turns out these containers have a really nasty behaviour that I was totally unaware of. I had always assumed that when you iterated through these containers it did so over the underlying bucket structure which would mean the order would always be the same as long as the hashes remained the same but this is not the case. It's implementation specific but, in the MS and GCC standard libraries, iteration order ends up being insertion order. Most of the time this is fine because we populate most maps once and don't edit them but, nonetheless, hashing these containers for merging etc was dubious at best. This showed up in customUpdate.cc always wanting to recompile itself due to the unordered set holding dynamic parameter names but could cause all kinds of weirdness. Therefore, I've just switched to using std::map/std::set everywhere anything is ever hashed - annoying but non-problematic change as the APIs are identical

New things

• Have tidied up implementations of Potjans microcircuit, Superspike image-by-spike generator and MNIST mushroom body classifier, added simple CLIs and put them in userprojects.
• Allocating spike-recording buffers as zero-copy makes a lot of sense when doing closed-loop stuff with Jetson - this is now possible!
• Expose generation of integer random numbers i.e. gennrand() % MAX function, atomic or (does nothing on CPU) and count-leading-zeros
• Added EGP references to Custom Connectivity Updates
• Expose row lengths to Custom Connectivity Update code

Further syntax tweaking

• Renamed SynapseType::SpanType to SynapseType::ParallelismHint
• 99% of the time you pass zero as the axonal delay to addSynapsePopulation . This is now set via a method (property in PyGeNN) like other sorts of delay (the signature for this method has totally changed already so this won't really increase the annoyance of porting models)
• As discussed renamed sim_code, post_learn_code and friends and (in PyGeNN) added backward compatibility with deprecation warnings
• On the C++ side, ModelSpec::addSynapsePopulation, ModelSpec::addCurrentSource and ModelSpec::addCustomConnectivityUpdate all referenced neuron/synapse populations by name - this was inconsistent with variable reference creation syntax, required some ugliness and ModelSpec and didn't match PyGeNN. These functions now take pointers
• As discussed, renamed var_name_types to vars in create_XXX_model PyGeNN methods with backward compatibility + deprecation warnings
• On systems with multiple GPUs, the CUDA backend used to try and select the 'optimal' device by device. This is slow and pretty silly as, having multiple identical GPUs is the common case. Have changed the default to just running on device 0.

Python build system

I have made some build system improvements meaning that you can now build PyGeNN from source using a single command on Windows and Linux:

• Editable: python setup.py develop or pip install -e .
• Install: python setup.py install or pip install .

While the build system still uses setuptools "legacy" mode rather than full PEP 517 (https://peps.python.org/pep-0517/), it is enough to enable the pip-based installs to work on Python 3.12 (where directly running setup.py is no longer allowed). At some point I will fully PEP 517 it but, currently, various functionality is still missing such as the ability to pass options through pip to setuptools which we use to create debug and coverage PyGeNN builds.