Ng-spice and SMP was: Re: [ng-spice-devel] Catching up
On Mon, 05 Feb 2001, Gillespie, Alan wrote:
> Ng-spice and SMP
> I agree with Al's comments about the main CPU-time hog being
> the evaluation of the device model equations, rather than the
> actual matrix calculation itself. However, I don't know if I agree
> with his conclusions, i.e. that the best we could hope for with
> SMP would be a 3x improvement.
When you use multi-processing, the best speedup you can hope for is
proportional to the number of processors. If you have 4 processors,
you can get at best 4x improvement. In practice it is not this good.
You can't parallel everything. There is overhead. If you wait a
year, single CPU speeds will improve as much.
Contrast, improving the algorithms in general has much more potential.
If you want to do research or experiments in multi-processing for
your own education, or for other purposes, go ahead. I am just
saying that if the goal is to simulate circuits faster, there are
other approaches that will accomplish more.
> Surely, in a circuit with thousands of devices, it would be
> relatively easy to split the model evaluation up between as many
> CPU's as you like. As long as the final loading of the results into
> the matrix doesn't become a bottleneck, then surely we can get an
> almost arbitrary speedup limited only by the number of CPUs. The
> amount of data each CPU needs to do the evaluation will easily fit
> in it's own local cache, so they shouldn't be fighting over access
> to shared memory.
"final loading of the matrix" takes longer than solving it. This is
an area that needs work, both in Spice and ACS. The ACS matrix
package is designed with reducing this as a priority, yet still it
takes longer to load it than to solve it.
I have an idea for a data structure change that should improve the
matrix load time by making better use of the cache. I did it on an
AWE simulator I was working on a few years ago with good results. It
uses proxy objects to hide a different data structure underneath, so
time critical data is stored in dense vectors. It makes it so the
"final loading of the matrix" can be a vector operation, rather than
a loop of scalars.
> It might be fun to try SuperLU-ing the matrix code, though ;-)
> although I think we already discussed the fact that the code in
> spice is rather specialist, and a general matrix solver would
> probably be a step back. If one of us understood it properly,
> though, we might be able to get the best of both worlds.
The Spice matrix code is general purpose. The ACS matrix code is
customized to the application, but has a general purpose interface
and is valid as general purpose. The fact that the interface is
general purpose should make it relatively easy to try alternatives.
If you want to do this, it would be more useful to first understand
what the differences are. You should understand theoretically why
the performance should be different. The differences could be as
subtle as cache hits. More likely, it depends on what you are doing
with it. Better performance in one application often comes with
worse performance in another. Different packages make different
tradeoffs.
The biggest difference is likely to be in how to interact with it.
This is why ACS uses its own sparse matrix package.
Partial thread listing:
- Ng-spice and SMP was: Re: [ng-spice-devel] Catching up, (continued)