Feature- Can the simulation be made multithreaded?

[MatNieuw]

Some of my simulations run for hours, and my CPU indicator shows it only used one thread. Multithreading would help a lot here. But I am not sure the simulation engine allows for multithreading.

[esaruoho]

CircuitJS1 is compiled from Java to JavaScript via GWT and runs in the browser. JavaScript is inherently single-threaded — true multi-threading with shared memory is not available in the browser environment.

Web Workers exist for background tasks but operate in isolated contexts with no shared memory, requiring message-passing for all communication. The simulation's Modified Nodal Analysis (MNA) solver in CirSim.runCircuit() builds and solves a matrix where each node depends on others — this tight coupling makes it very difficult to partition across workers without the overhead of serializing/deserializing the entire circuit state each timestep.

The main performance bottleneck is typically the matrix solve (lu_solve/lu_factor in CirSim.java). For large circuits, the most practical speedups would be:

• Sparse matrix techniques (the current implementation uses dense matrices)
• Reducing the number of internal nodes (e.g., combining series resistors)
• GPU-accelerated linear algebra (WebGPU is emerging but not widely supported yet)

For the offline Electron version, Node.js native addons could potentially use threads, but that would be a significant architectural change and would not benefit the web version.

[MatNieuw]

Thanks for the explanation. If each node depends on other, how can it then be un-serialized? Or is this dependency only between time steps?

• The matrix is for a very large part only zeroes, when I dump it.
• My largest matrix currently is 2500x2500, with internal nodes already reduced where possible.
• If the matrix solve is suitable for parallel processing, then GPU use would certainly help.
• I only use the offline version, more screen space. I wouldn´t mind if the offline version could use multithreading (CPU or GPU) even if the web version could not, it might be auto-detectable at start up time.

[esaruoho]

@MatNieuw Great questions. To answer them:

Dependency between nodes: The dependency is within each timestep, not just between them. The MNA matrix encodes how every node voltage depends on every other node via the circuit's conductance relationships. You can't compute node A's voltage without knowing node B's voltage if there's a component connecting them. The matrix solve handles all of this simultaneously — that's why it's a matrix equation (Ax = b) rather than sequential updates.

Sparse matrix: You're absolutely right that the matrix is mostly zeroes — each node typically only connects to a few neighbors, so most off-diagonal entries are zero. The current implementation uses dense LU factorization, which means it's doing O(n³) work on a matrix that's mostly empty. A sparse solver (like Sparse LU or conjugate gradient methods) would dramatically reduce the work for your 2500×2500 case. This is probably the single biggest performance win available and wouldn't require any threading at all. SPICE simulators use sparse matrix techniques for exactly this reason.

GPU: GPU-accelerated dense linear algebra (via WebGPU compute shaders or, for Electron, CUDA/OpenCL native addons) could help with the matrix solve, but GPUs really shine on large dense matrices. Since yours is sparse, a sparse CPU solver might actually outperform a dense GPU solver. That said, if the circuit has many independent nonlinear elements needing Newton-Raphson subiterations, those evaluations could potentially be parallelized on the GPU.

Offline-only multithreading: For the Electron version specifically, Node.js worker threads share memory via SharedArrayBuffer, which is much more efficient than the Web Worker message-passing approach. The matrix solve could potentially be offloaded to a worker thread, keeping the UI responsive during heavy computation. This would be the most practical path for multi-core utilization in the offline version. It wouldn't require restructuring the solver itself — just running it in a separate thread and synchronizing the results back.

In priority order, the biggest wins would be:

1. Sparse matrix solver (no threading needed, biggest single speedup)
2. Worker thread for matrix solve (Electron only, keeps UI responsive)
3. GPU compute (WebGPU for browser, CUDA for Electron, most complex)

[pfalstad]

Someone contributed a sparse matrix solver, but I didn't merge it because it made the simulation slower for some circuits. I wanted to make the solver type selectable at some point, so it could be optional. (I also have another branch which has a solver optimized for digital circuits.)

[esaruoho]

PR #267 implements the selectable sparse solver. It ports H-Dynamite's sparse CSC LU solver from sharpie7/circuitjs1 PR sharpie7#920 and adds a 3-way dropdown in Other Options: Auto / Dense (Crout's LU) / Sparse (CSC LU). Auto mode uses dense for small circuits and switches to sparse at 150+ nodes, so small circuits don't take a performance hit.