You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#407 allows large models to be compiled on Windows if you have sufficient RAM but, trying to link the multi-area model code now fails with "LINK : fatal error LNK1189: library limit of 65535 objects exceeded". As the multi-area model has about 70000 synapse populations and, even with all the runner-size-reduction optimizations in place, there is still more than one symbol exported for each one so this is hardly surprising. Seemingly this isn't even a Visual Studio limitation but rather a limitation of the Windows PE executable format which, somewhere, uses 16-bit indices for symbols (https://developercommunity.visualstudio.com/t/fix-msvc-65535-symbol-limit-in-lib-files-lnk1189/220174).
Obviously lol Windows but, while #286 has meant that while the size of kernels generated for complex models are kept manageable as long as the model's relatively homogeneous, the runner can still get really big. This means that, even on platforms where this particular limit doesn't apply, the compilation time and memory requirements for huge runners currently limits the maximum model size (in terms of number of populations). Generating runner code that looks more like the following would be one option but quite how it would handle heterogeneous populations is another question:
#407 allows large models to be compiled on Windows if you have sufficient RAM but, trying to link the multi-area model code now fails with "LINK : fatal error LNK1189: library limit of 65535 objects exceeded". As the multi-area model has about 70000 synapse populations and, even with all the runner-size-reduction optimizations in place, there is still more than one symbol exported for each one so this is hardly surprising. Seemingly this isn't even a Visual Studio limitation but rather a limitation of the Windows PE executable format which, somewhere, uses 16-bit indices for symbols (https://developercommunity.visualstudio.com/t/fix-msvc-65535-symbol-limit-in-lib-files-lnk1189/220174).
Obviously lol Windows but, while #286 has meant that while the size of kernels generated for complex models are kept manageable as long as the model's relatively homogeneous, the runner can still get really big. This means that, even on platforms where this particular limit doesn't apply, the compilation time and memory requirements for huge runners currently limits the maximum model size (in terms of number of populations). Generating runner code that looks more like the following would be one option but quite how it would handle heterogeneous populations is another question:
The text was updated successfully, but these errors were encountered: