M
Mike Engelhardt
Guest
Jim,
considerably faster that PSpice 10.0.0 on your circuit. But
I'm glad that since I'm distributing over 1000 times as many
copies of LTspice as Cadence is of PSpice, it's nice they still
take notice and try to catch up as they've done with other
performance improvements and features first introduced to the
industry by LTspice.
still lags in performance. Here are run times from a 1yr plus
old 3GHz P4:
PSpice 9.2 200.86 (trolt=7)
PSpice 9.2.3 165.55 (trolt=7)
PSpice 10.0.0 164.56 (trolt=7)
LTspice 2.11e 117.98 (trolt=7)
LTspice 2.11e -P4 Only 89.50 (trolt=7)
Now, I did remove some unused libraries, but I can send back
the exact deck I used if you wish. I can't remember if these
were under a gentleman's NDA or not, so I haven't and won't
share them with anyone else.
Since SPICE uses successive linearizations of a non-linear
system there's enough heuristics going on that you can't
use a single circuit to determine if one SPICE is faster
than another. The experience I get from working at a foundry
with hundreds of IC engineers is that LTspice ran BSIM
circuit 3 to 6 times faster than PSpice. The latest PSpice
version as reduced that to 2 to 4 times faster, but it still
has more convergence problems. Ya know, these kids these days
just want to simulate the whole IC all at once and not think
about what they're doing.
Of course, you should still remember the other benchmark you
send me. PSpice gave you the wrong answer and LTspice immediate
gave the right one. Also, you could make LTspice duplicate
PSpice's erroneous results by setting the integration method to
Gear and it still ran substantially faster than PSpice. I
believe that was done with PSpice 10.0.0. Anyway, that was
a time where LTspice's improved integrity of solution helped
you catch a design flaw in a circuit you inherited.
Now, I used a P4 and 10.0.0 instead of an ATH64 and 10.0.0i.
Maybe the AMD machine speeds up PSpice more than it speeds
up LTspice. But the general LTspice distribution is optimized
for a P3, not a P4. The version called "LTspice 2.11e -P4" is
a P4 version, at it runs 30% faster still, but won't run on
a P3. Older AMD's could do the full P4 instruction set, but
it might run on your ATH64, that executable is at
http://ltspice.linear.com/software/P4scad3.exe
Just put it in the same directory as scad3.exe, usually
C:\Program Files\LTC\SwCADIII, and run it. It uses the
P4's ability to do two double precession floating point
operations at the same time, as also mentioned by JD.
Periodically I make a P4 specific version of LTspice
availible, so now an up-to-date P4 only is availible.
I'm not very interested in the AMD vs. Intel debate, but
I'm certainly not going to quit using Intel machines.
They've the market share and my machines are ultimately
all test beds, not for personal use.
--Mike
I wasn't able to duplicate this. I find that LTspice is stillI had never done the comparison between PSpice and LTSpice
myself, relying on the reports of others.
This noon hour I ran the latest version of LTSpice with
exactly the same setups, save-waveforms, and waveforms-to-
be-plotted. (See below.)
LTSpice came out very slightly slower.
considerably faster that PSpice 10.0.0 on your circuit. But
I'm glad that since I'm distributing over 1000 times as many
copies of LTspice as Cadence is of PSpice, it's nice they still
take notice and try to catch up as they've done with other
performance improvements and features first introduced to the
industry by LTspice.
Yes, they did seem to fix some of their BSIM problems, but it(I should also point out that, since Mike E. last did a
comparison, PSpice added a new "Solver" to their algorithm.)
still lags in performance. Here are run times from a 1yr plus
old 3GHz P4:
PSpice 9.2 200.86 (trolt=7)
PSpice 9.2.3 165.55 (trolt=7)
PSpice 10.0.0 164.56 (trolt=7)
LTspice 2.11e 117.98 (trolt=7)
LTspice 2.11e -P4 Only 89.50 (trolt=7)
Now, I did remove some unused libraries, but I can send back
the exact deck I used if you wish. I can't remember if these
were under a gentleman's NDA or not, so I haven't and won't
share them with anyone else.
Since SPICE uses successive linearizations of a non-linear
system there's enough heuristics going on that you can't
use a single circuit to determine if one SPICE is faster
than another. The experience I get from working at a foundry
with hundreds of IC engineers is that LTspice ran BSIM
circuit 3 to 6 times faster than PSpice. The latest PSpice
version as reduced that to 2 to 4 times faster, but it still
has more convergence problems. Ya know, these kids these days
just want to simulate the whole IC all at once and not think
about what they're doing.
Of course, you should still remember the other benchmark you
send me. PSpice gave you the wrong answer and LTspice immediate
gave the right one. Also, you could make LTspice duplicate
PSpice's erroneous results by setting the integration method to
Gear and it still ran substantially faster than PSpice. I
believe that was done with PSpice 10.0.0. Anyway, that was
a time where LTspice's improved integrity of solution helped
you catch a design flaw in a circuit you inherited.
Now, I used a P4 and 10.0.0 instead of an ATH64 and 10.0.0i.
Maybe the AMD machine speeds up PSpice more than it speeds
up LTspice. But the general LTspice distribution is optimized
for a P3, not a P4. The version called "LTspice 2.11e -P4" is
a P4 version, at it runs 30% faster still, but won't run on
a P3. Older AMD's could do the full P4 instruction set, but
it might run on your ATH64, that executable is at
http://ltspice.linear.com/software/P4scad3.exe
Just put it in the same directory as scad3.exe, usually
C:\Program Files\LTC\SwCADIII, and run it. It uses the
P4's ability to do two double precession floating point
operations at the same time, as also mentioned by JD.
Periodically I make a P4 specific version of LTspice
availible, so now an up-to-date P4 only is availible.
I'm not very interested in the AMD vs. Intel debate, but
I'm certainly not going to quit using Intel machines.
They've the market share and my machines are ultimately
all test beds, not for personal use.
--Mike