SPICE Differentiation

So just why is LTspice better than other SPICE programs?

Economics. If I write a SPICE program for an EDA company, it's possible to gross some smallish number of millions of dollars revenue. But if I write the same program for an IC company and it's used to both design and sell the ICs, then that same simulator is mission path to 1.5 billion dollars in revenue.

Sure, but what's the big TECHNICAL difference between LTspice and any other SPICE out there? Aren't all SPICE's based on Berkeley SPICE and essentially the same solver?

LTspice is a dramatically improved version of SPICE over any other SPICE program available. While most of these improvements are proprietary, here is an article that discusses a few of the differences between LTspice and other SPICE programs:

     SPICE Differentiation, LT Journal of Analog Innovation, 2015

Note that article uses screen dumps from an old version of PSpice for comparison to the better solver in LTspice, but the netlists are machine readable and you can run them in the current versions of commercial simulators to see that (i) the problems persist and (ii) SPICE solver development as stopped at SPICE software companies.

Fine. I understand that article. It's pretty lucid, really. But when a boutique SPICE company comes by my office to promote their $100K/seat SPICE, they use a bunch of terms about numerical methods I don't understand. Do you have anything like that?

Sure, LTspice includes the following original methods:

• Stochastic Cooling of process threads: Eliminate inter-thread communication deadlocks -- it's the difference between a light bulb and a laser.
• Node Reduction: simulations run both faster and more accurately (like an FFT is both faster and more accurate than computing the DFFT from definition because there's less accumulated round off error because there so many fewer floating point operations to do).
• Predication Coalescence: Behavioral expressions are analyzed. Duplicate content is cached. Statistical analysis is applied to conditional evaluations. The result is that the speed of evaluation of runtime-parsed behavioral expressions approaches that of SPICE devices written in native C-code. The global optimizer is based in graph theory.
• Self-authoring Assembly Language: Because of dynamic memory allocation, memory access is slow because when software is written, the return result from malloc() isn't know until runtime. Hence LTspice writes a unique solver for each simulation run at runtime after the addresses returned malloc() are known. The speeds things up 3x.
• Opportunistic 32-bit Addressing: 64-bit programs need 64-bit pointers. For equal quality object code generation from the compiler, the 32-bit version of a program will run faster than the 64-bit version. However, since LTspice doesn't write the solver until malloc() is called, it can use 32-bit addressing if malloc() returned an address sufficiently close to the program counter(it almost always does). Not only does the smaller code execute faster, more of it fits in CPU cache, so opportunistic 32-bit addressing in a 64-bit program is a big win.
• Routines optimized to execute entirely in CPU cache: Disciplined guidance for writing fast numerical methods focuses on using CPU cache over CPU cores.

How can you possibly know whether a routine runs in on-chip CPU cache or the PCB mounted RAM?

Formerly I'd slice open the outer layer of insulation of my computer power cord so I could clamp an ammeter over one conductor to measure the current draw for different algorithms. That's not so effective on current machines -- even if you increase the computer's SMPS input filter capacitance(to reduce the power factor correction so a small change in power draw makes an exaggerated change in RMS current and needle deflection) -- so I just profile the code.

OK, I get it. But what about that GUI?

LTspice's GUI was based on a statistical analysis of the keyboard entry and mouse motion required to enter a schematic. Besides the overwhelming empirical success of LTspice's GUI, it actually is the easiest GUI to use for schematic entry.