Support reporting kernel timings via profiling_summary()

[denisalevi]

I added a network_get_profiling_info function to the GeNNDevice in order to get the recorded kernel timings for my benchmarks. Here is the function in case you want this in brian2GeNN.

After a run with prefs.devices.genn.kernel_timing = True a call to print(brian2.profiling_summary()) now returns something like this:

Profiling summary
=================
neuronUpdateTime          1.52 s    96.81 %
presynapticUpdateTime     0.05 s     3.19 %
initTime                  0.00 s     0.00 %
postsynapticUpdateTime    0.00 s     0.00 %
synapseDynamicsTime       0.00 s     0.00 %
initSparseTime            0.00 s     0.00 %

Currently, calling run with profile = True raises an NotImplementedError. Instead, one has to set the kernel_timing option. But the way it is right now, running profiling_summary() without kernel_timing = True, will raise the CPPStandaloneDevice error stating that one has to run profile=True.

I don't know what way around you want this (if at all). Either letting this be recorded when profile = True or leave as is and raise another error when kernel_timing = False.

I've allowed edits by maintainers, feel free to modify :)

[mstimberg]

Well, well, it has been a while 😅 I updated the PR and will merge it as soon as the tests pass so that it can go into the next release (necessary to make everything compatible with the most recent Brian 2 release).

Currently, calling run with profile = True raises an NotImplementedError. Instead, one has to set the kernel_timing option. But the way it is right now, running profiling_summary() without kernel_timing = True, will raise the CPPStandaloneDevice error stating that one has to run profile=True.

I changed the PR so that it will run the profiling if profile=True has been set. The device.genn.kernel_timing preference is still supported, but deprecated. It is not given exactly the same kind of profiling information that Brian's standard modes are giving, but I think that's ok, profiling has always been a bit device-specific (the profiling info is already different between runtime and standalone mode).