[Proposal] Introspection Engine for Automatic Backend Tuning & Advisory (GSoC 2026)

[ayush4874]

Hi @mstimberg and @thesamovar,

Following up on the discussion in #1729 regarding Dan's idea of an "Auto-Switch" or "Smart Heuristic" for backend selection, I have drafted a preliminary technical proposal for GSoC 2026.

The Core Concept

I propose building a ComplexityCrawler that runs inside Network.before_run(). It inspects the computational cost of the network (neuron count, synapse sparsity, duration) and serves two functions:

1. Runtime Optimization: Automatically selects the most efficient Runtime target (numpy, cython, or the upcoming cppyy) based on startup cost vs. execution speed.
2. Scalability Advisor: Detects when a simulation is too heavy for any Python-driven runtime (due to the Network.run loop overhead) and explicitly warns the user to switch to set_device('cpp_standalone') for massive speedups.

The Draft Proposal

I have outlined the technical mechanism, the "Tiered Cost Model", and implementation phases here:
https://gist.github.com/ayush4874/d2bf639b772049bd3465951bfea8c307

Technical Note

My initial idea considered "seamlessly swapping" to cpp_standalone automatically. However, swapping to Standalone mode inside before_run (after objects are already initialized in Python) is likely architecturally unsafe.

Therefore, this proposal focuses on advising for Standalone mode (Tier 3) via warnings, while reserving automatic switching for the Runtime targets (Tier 1 & 2) where it is safe to do so.

I’ve prototyped the "Scoring" logic locally (prototype_v2_crawler.py) and it successfully distinguishes between "toy", "standard", and "heavy" networks. I would love your feedback on this architecture.

[arybhatt4533]

Hi @mstimberg @thesamovar, this proposal for a ComplexityCrawler looks very promising for optimizing the dev-loop!

I had a few thoughts/questions:

Persistence: Instead of re-calculating heuristics on every before_run(), could we implement a lightweight caching mechanism to store benchmark results for recurring network structures?

Transparency: For Jupyter Notebook users, would it be beneficial to have a 'logging/advisor' mode that explicitly notifies why a certain backend was auto-selected?

Fallback Safety: How will the engine handle cases where a suggested backend (like Cython) isn't correctly configured on the user's environment?

Looking forward to your thoughts on this!

[ayush4874]

Hi @arybhatt4533,

To clarify on those points:

• Persistence: The introspection strictly sums integer attributes (neuron counts, connectivity, etc.). This is a microsecond-level operation, so adding a caching layer is overkill and would likely introduce more complexity than it saves.

• Transparency: Agreed. The "Advisor" component mentioned in Phase 3 is specifically designed to log info/warnings so the user knows exactly why a switch was triggered.

• Fallback Safety: The engine will naturally check codegen.is_available() before attempting any switch. If a backend like Cython isn't configured, it will gracefully degrade to numpy.

[Legend101Zz]

@ayush4874 thanks for putting this up given the ongoing work on the cppyy backend in #1769 , which could potentially replace Cython with sub-second compilation times (vs. 10-60s for Cython), does the auto-switching proposal remain relevant?

If cppyy becomes the default runtime backend, the primary motivation for switching between numpy ↔ cython (avoiding slow compilation during development) would largely disappear. Would then the project's scope need to shift toward numpy ↔ cppyy switching, or would cppyy's fast compilation make the entire auto-tuning mechanism unnecessary for runtime backends ?

Also how do we if we plan to add this structure it in such a way that adding a new codegen target ( like in this case we re introducing cppyy ) automatically makes the ComplexityCrawler you are proposing adjust to the new codegen target ?

[ayush4874]

@Legend101Zz valid point. If cppyy becomes the default with sub-second JIT, the specific need to toggle numpy ↔ cython to avoid compilation wait times definitely diminishes.

However, I think this shifts the primary value of the Introspection Engine to the Runtime vs. Standalone decision.

Even with cppyy, the simulation is driven by the Python Network.run loop. For massive networks, that Python iteration overhead is often the bottleneck, regardless of how fast the underlying kernels are. The engine’s role would be detecting when a simulation is too heavy for any Runtime backend (including cppyy) and advising the user to switch to cpp_standalone to break out of the Python loop entirely.

Regarding extensibility: I plan to design the ComplexityCrawler to query the device for a "performance profile" rather than hardcoding backend names. That way, cppyy would just register as a low-startup backend, and the logic adapts automatically.

[ayush4874]

@mstimberg Quick question on GSoC proposal now that the portal is open.

I noticed Introspection Engine idea isn't on the official INCF list. Are you open to custom projects this year, or is INCF strictly requiring applications to be from the published list?

If we have to stick to the list, I can easily pivot my application to Idea 3 (Improved parser for model descriptions). Since I just got familiar with the pyparsing logic and error handling during my work on PR #1766, so it's a very natural fit for me.

Just let me know what you'd prefer.

[ayush4874]

Hi @mstimberg and @thesamovar,

Since the GSoC portal is now open and the deadline is approaching, I am going to make the strategic pivot to Idea 3 (Improved parser for model descriptions) for my official application.

Given my recent work on PR #1766 dealing with pyparsing and error handling, I already have a deep familiarity with the current parsing architecture and its bottlenecks, making Idea 3 a very natural and immediate fit for me.

I will submit my draft proposal for the Parser improvements directly to the GSoC portal so you can review it there when you have time. If we ever want to revisit the Introspection Engine in the future, we can easily reopen this discussion!