Context
Performance degradation in a MOD file with GLOBAL variables
Overview of the issue
If a MOD file has GLOBAL variables then performance seems to be degraded with the latest master (i.e. new data structure implementation). This is due to the use of generic data handles for GLOBAL variables.
By the way, this is somewhat related to #2787 because we end up with a nrntest/thread/perf2.hoc when simplifying the provided example. But, #2787 has additional issues and those need to be investigated.
Expected result/behavior
Performance should be similar to the pre-SOA version or 8.2.4.
NEURON setup
- Version:
- we can eiher compare pre-soa commit b4ade55 vs master
- or, master version with hh.mod having GLOBAL vars vs master version with hh.mod where GLOBAL is replaced with RANGE
- Installation method: from source
- OS + Version: any
- Compiler + Version: any
Important NOTE:
- Make sure to disable coreneuron because
hh.mod is automatically updated with GLOBAL/RANGE in CMakeLists.txt
- when you modify
hh.mod by hand, it is needed to comment out the toggle code in CMakeLists.txt.
Minimal working example - MWE
We can use nrntest/thread/perf* for this purpose:
git clone https://github.com/neuronsimulator/nrntest.git -b pramodk/generic-handle-bench
cd nrntest/thread
With two different versions we should see something like below:
# master branch where we have GLOBAL in hh.mod
$ ../../nrn-home/nrn-master/build-gcc/install/bin/nrniv perf2.hoc
NEURON -- VERSION 9.0a-243-g30b42a1b8+ master (30b42a1b8+) 2024-05-14
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2022
See http://neuron.yale.edu/neuron/credits
1
1
1
1
nt cache1
1 5.15195
# master branch where GLOBAL is replaced with RANGE in hh.mod
kumbhar@bbd-1dlczt3:~/workarena/repos/bbp/266806/nrntest/thread$ ../../nrn-home/nrn-master-range/build-gcc/install/bin/nrniv perf2.hoc
NEURON -- VERSION 9.0a-244-g81ddd0edf+ master (81ddd0edf+) 2024-05-23
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2022
See http://neuron.yale.edu/neuron/credits
1
1
1
1
nt cache1
1 3.6898
Here we can see the time difference from 5.15 sec to 3.68 sec.
git clone git@github.com:neuronsimulator/nrn.git
mkdir build && cd build
cmake -DNRN_ENABLE_CORENEURON=OFF -DCMAKE_INSTALL_PREFIX=`pwd`/install` ..
make -j8
make install
Logs
As mentioned during the weekly dev meeting on the BBP side, the profile shows the generic_data_handle parts:

Possible Fix
On BBP Slack channel, @1uc provided following suggestion:

(Any function accepting a _thread should also accept a _globals pointer.)
@alkino : maybe I can assign this to you as Luc's suggestion seems straightforward to implement (in old nocmodl though)
Context
Performance degradation in a MOD file with
GLOBALvariablesOverview of the issue
If a MOD file has
GLOBALvariables then performance seems to be degraded with the latest master (i.e. new data structure implementation). This is due to the use of generic data handles for GLOBAL variables.By the way, this is somewhat related to #2787 because we end up with a
nrntest/thread/perf2.hocwhen simplifying the provided example. But, #2787 has additional issues and those need to be investigated.Expected result/behavior
Performance should be similar to the pre-SOA version or 8.2.4.
NEURON setup
- we can eiher compare pre-soa commit b4ade55
vsmaster- or, master version with
hh.modhavingGLOBALvarsvsmaster version withhh.modwhereGLOBALis replaced withRANGEImportant NOTE:hh.modis automatically updated with GLOBAL/RANGE inCMakeLists.txthh.modby hand, it is needed to comment out the toggle code inCMakeLists.txt.Minimal working example - MWE
We can use
nrntest/thread/perf*for this purpose:With two different versions we should see something like below:
Here we can see the time difference from
5.15 secto3.68 sec.Logs
As mentioned during the weekly dev meeting on the BBP side, the profile shows the

generic_data_handleparts:Possible Fix
On BBP Slack channel, @1uc provided following suggestion:
(Any function accepting a _thread should also accept a _globals pointer.)
@alkino : maybe I can assign this to you as Luc's suggestion seems straightforward to implement (in old
nocmodlthough)