spice3f5 benchmark


To ng-spice@ieee.ing.uniroma1.it
From jvercamm@roam.agfa.be (Jan Vercammen)
Date Mon, 20 Mar 2000 15:00:54 +0100
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice@ieee.ing.uniroma1.it

hello,

I have been following ng-spice closely since 1/2 year. This is my 2nd posting 
to
the mailing list.

I have had the chance to test a commercial spice simulator against spice3f5. 
As
I am specialised in electromagnetic compatibility and signal integrity my work
is concentrated on (large) passive circuits and transmission line circuits. I 
have
simulated 2-dimensional planar structures (= power supply planes) using RLCK 
circuits.
The results between the commercial spice simulator and spice3f5 are shown 
below.
The first column list the number of components or circuit equations (sum of 
resistors,
inductors, capacitors and mutual inductors), whereas the second and third 
column 
list the run times of the commercial spice and spice3f5 simulator. The 
spice3f5 is
the original Berkeley version which my company acquired in 1997. There is no
performance difference between ngspice and the 3f5 code. The code ran on a 
170MHz two-processor Sun workstation.

#comp           spice           spice3f5
1125            25              43          
3225            88              154            
6405            168             360          
10665           329             712          
16005           566                    
22425           934           
29925           1307            
38505           1848            
46165           2580            
70725           4021            
97605           7342            
146025          14894           

Large passive circuits were tested with almost 150K circuit equations. The 
spice3f5
upper limit is 10K circuits because of memory leaks.

The conclusions are:
- spice3f5 is about 2 times slower than the commercial spice
- spice3f5 is limited to smaller circuits because of memory leaks

I tested also the multi-threated code using two processors. The results are 
displayed 
below. The 2nd column is the 2-cpu run time, the 3rd column the single cpu.

#comp           spice_2_processor       spice           relative improvement
70725           3871                    4021            96%
97605           6450                    7342            88%

The speedup of the dual processor code is small, but seems to improve with 
larger 
circuits.  I have tested the multi-threaded code on coupled transmission 
lines and 
monte-carlo simulations with similar results: the multi-processor code does 
not seem
to be beneficial.

Other conclusions are that both spice and spice3f5 can efficiently handle 
large
(passive) circuits. The cach size does not seem t be a limitation.

My overall (and personal) conclusions are that:
- the spice3f5 code is still fast enough, though there is a 1 over 2 
performance 
  difference, which is, probably, due to the LU decomposition. However, which 
aspect
  of the sparse matrix LU-decomp is unclear. I would guess that the matrix 
fill ins 
  are lower in spice than in spice3f5. A proplem is that the 'rusage' command 
does 
  not work for spice3f5 which would allow us to compare details of both 
simulators.
- memory leaks are a nuisance and they limit the use of spice3f5

I hope that this benchmark information is useful to help the ng-spice team to
find the best possible path to get spice running and to a broad public. I 
like the
ngspice initiative verry much.

I suggest that the ngspice team should consider the following aspects: (1) 
use what you 
have, (2) solve the license problem and (3) deliver a kernel code to get 
people
started.

(1) use as much code you have. I think that the spice3f5 code is not bad. The 
only
messy things are the interfaces to the operating system and the memory leaks. 
Maybe
 you could separate that
from the code. I read in the mailing that some people have spice code in 
which they 
solved the memory leaks and have a simple interface: string in, result 
vectors out. 
This kind of simple interface is useful because it allows other programmers 
to 
interface it without much problems and it would also allow other code to be 
wrapped
around the spice code: for example python is a nice candidate. I also think 
that 
the post-processor works good, however, it should be reworked or possibly be 
abandonned
in a later stage.

(2) as far as I understand the license, spice3f5 is still not GPL. However, I 
do think
that spice3f4 is freely available (???) and can be converted into GPL. Maybe 
you
should use that as a starting point. Spice3f4 (not Spice3f5) is available 
from Berkely 
sing a software on-line permission statement.  

(3) A kernel code should be distributed as fast as possible. This would allow 
many
others to work on the spice code and on the interface. Instead on rewriting 
large
portionsof the code the sparse matrix code could be reworked or fine-tuned. 
In a later
stage multi-processing should be considered.

Please keep on with what you are doing! I have used ngspice for my thesis. 
Thank you.


regards,

Jan Vercammen






Partial thread listing: