Re: [Help-gnucap] subcircuits and speed

[Felix Salfelder]

On Mon, Jan 16, 2012 at 01:45:11AM -0500, al davis wrote:
> On Sunday 15 January 2012, Paul Reichl wrote:
> > I am fairly new to gnucap and spice and I have a question
> > regarding the  use of subcircuits and the solution times
> > when using them. I have a circuit network with about 500 or
> > so sets of either; R and L, R, L and C, or R, L, C and
> > I,  elements in series. If I perform an AC analysis when
> > using this circuit it takes only about 3 seconds to run
> > (which is great:-) ).
> > 
> > However, if the same circuit is written in terms of a number
> > of  subcircuits (essentially RL subcircuits, RLC subcircuits
> > and RLCI subcircuits, with roughly 500 or so subcircuit
> > elements in total) and I performs the same AC analysis
> > again, it now takes roughly 1500 seconds to run. (i.e. the
> > same analysis with the same underlying circuit when using
> > subcircuits is roughly 500 times slower than the one done
> > without using them).

i had different phenomena with a series-of-inverters benchmark
circuit. depending on the order option i got *very* different results.
obviously this is caused by the matrix structure and roughly the
bandwidth of the matrix is crucial.

i have hacked the code a bit to support node allocation _after_ all
i_want_matrix have been called. also i have implemented a component-wise
allocator. this yields a matrix

*00000000000000000000000000000000
0***00000000000000000000000000000
0***00*00000000000000000000000000
0***00*0000000000000000000000000*
0000***0000000000000000000000000*
0000***00*0000000000000000000000*
00*****00*000000000000000000000**
0000000***000000000000000000000**
0000000***00*000000000000000000**
00000*****00*000000000000000000**
0000000000***000000000000000000**
0000000000***00*000000000000000**
00000000*****00*000000000000000**
0000000000000***000000000000000**
0000000000000***00*000000000000**
00000000000*****00*000000000000**
0000000000000000***000000000000**
0000000000000000***00*000000000**
00000000000000*****00*000000000**
0000000000000000000***000000000**
0000000000000000000***00*000000**
00000000000000000*****00*000000**
0000000000000000000000***000000**
0000000000000000000000***00*000**
00000000000000000000*****00*000**
0000000000000000000000000***000**
0000000000000000000000000***00***
00000000000000000000000*****00***
0000000000000000000000000000*****
0000000000000000000000000000*****
00000000000000000000000000*******
000000***************************
000******************************

instead of

*00000000000000000000000000000000
0*0000000000**0000000000000000000
00*000000000****00000000000000000
000*00000000******000000000000000
0000*0000000********0000000000000
00000*000000**********00000000000
000000*00000************000000000
0000000*0000**************0000000
00000000*000****************00000
000000000*00******************000
0000000000*0********************0
00000000000*********************0
0*******************************0
0*******************************0
00******************************0
00******************************0
000*****************************0
000*****************************0
0000****************************0
0000****************************0
00000***************************0
00000***************************0
000000**************************0
000000**************************0
0000000*************************0
0000000*************************0
00000000************************0
00000000************************0
000000000***********************0
000000000***********************0
0000000000***********************
0000000000***********************
000000000000000000000000000000***

with the 'auto' allocator. i guess this is just a corner case, but it
shows there are possible improvements.

i was planning to give reverse-cuthill-mckee a try (see
http://math.temple.edu/~daffi/software/rcm/)
due to lack of time, i am stuck in the preprocessor 'tricks' in
rcm.{c,h}, so i couldnt compile it in the end (yet).
if anybody around likes to play with it: the current state is in my
'rcm' branch (amongst other unimportant things).

> If you are so inclined, the best way to improve the run time is 
> to make plugins that implement the combinations you use as 
> single elements without internal nodes.  Making such optimized 
> models is not easy, but can be done.  There is work in progress 
> on porting the ADMS model compiler, but I don't think it will 
> help with the simple devices.

so theres another model compiler in production? (we have worked on
porting the admsXml spice-wrapper stuff to generate native gnucap code,
some parts are missing though).
are you proposing to use a model compiler just because the internal
nodes are currently allocated unluckily by gnucap? (what am i missing?)

regards
felix