[NEST Users] problems with step_current_generator parallelization

Dear NEST developers, In our group, we're working on a model of the primary visual cortex and use step_current_source generators to simulate the input current of the LGN neurons. We noticed that the simulation time of our model was very sensitive to the number of step_current_sources. When trying to narrow down the cause, we found out that this might be due to an issue with the parallelization of the step_current_source_generators. The resulting simple system in which the problem can be observed is attached below, simple_example.py. It essentially creates NSstep_current_generators and injects them into NLneurons with fixed indegree. The iaf_cond_exp neuron model is used here. The increment in the number of step_current sources does not benefit from a multithreading performance boost as one would expect. This is compared to the performance boost for the number of neurons; see the technical details below. Our estimated guess is that the difference between 1 and 32 threads is 10 to 20 times slower than the parallelization suggests. Technical details: The relative slowdown due to the parallelization of step_current_sources was measured using linear regression over simulation time = a NL + b NS. See slowdown_example.png. The ratio b/a was then calculated. This ratio was then measured in dependence on the number of threads. A bigger difference between the ratio for 1 thread and 32 threads means a greater problem in parallelization in step_current_generators. Some additional results: - interval_dependence.png - the slowdown does not depend on amplitude_times in the step_current_source function - indegree_dependence.png - the slowdown depends on the indegree of nest.Connect(source, neurons). Specifically, the slowdown is worse for low indegree values. This shows the slowdown depends on the number of step_current_sources created, not on the injections themselves. Are you aware of some lack of parallelization of the step_current_source or current the injection itself? If so, are there any plans for improving it? best regards, Jan Střeleček