spice3f5 benchmark
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: