1. Home
  2. Electronics Design
  3. LTspice speed

LTspice speed

As you probably know, in many occasions LTspice cannot take advantage of multiple CPU cores because many operations are not easily parallelizable. In fact, most simulations I make use less than 20/25% of CPU (intel i5, 4 cores/8 threads).

However, running more processes of LTspice to execute different simulations at the same time should overcome this limitation: each simulation is distinct, they can be fully paralleled. If I run two simulations that individually would use the 20% of CPU and last 10 minutes, I should see a

40% CPU occupation but they still should take 10 minutes to complete. Maybe a little more for the Windows scheduler overhead.

Instead, what I'm seeing in reality is indeed a 40% CPU occupation, but both simulations would take almost exactly twice as much to complete, 20 minutes.

I've already tried to manually fiddle with Task Manager and the processor affinities, for example assigning two cores to a process and two other cores to the other process. No difference.

Why? Is this some crappy Windows scheduler behavior, or do I miss something else?

Reply to
dalai lamah
Loading thread data ...

In theory, a sim could be broken into a bunch of small subsystems connected by a few wires, and each would run faster. Small matrix on a dedicated CPU.

Reply to
John Larkin

Un bel giorno Don Y digitò:

Yes, I think this is it: cache misses and probably also I/O overhead. In absolute terms the disk write speed is moderate (not more than 1 or 2 MB/s) but the I/O operations are in the millions.

Moreover, I've just noticed that every LTspice process uses a lot of threads, even if you limit the "max threads" parameter from the LTspice control panel. At least ten. Right now I'm running three simulations at once, and in total there are 46 LTspice threads running...

I think that LTspice is quite similar to AAA games: the number of cores does not matter much, and clock speed is king.

Reply to
dalai lamah

A biggish circuit generates gigabytes of .RAW file and can bog down a slow hard drive. SS drives help, as does limiting the data that is saved.

.SAVE has the disadvantage that you can't freely probe after the sim is done. .SAVE V(*) will save only voltages.

LT Spice doesn't allow a fixed or minimum time step, does it?

Reply to
John Larkin

Un bel giorno John Larkin digitò:

Yes, I have a SSD and each RAW file grows around 15 GB. Unfortunately I need all the data and also some precision; I've set the maximum timestep to

10 ns, it's still slightly inadequate, but I need the simulations to end within a day. :)

There would be the spice option "dtmin", but I don't know if LTspice supports it. I've never tried it.

Reply to
dalai lamah

Even with code that is optimised for multiprocessor operation like chess engines a rule of thumb is that about 75% of fast cores running flat out you saturate memory bandwidth and so allowing more than 6 cores out of 8 to run merely increases power consumption and may even slow down the computation. Chess is even more insidious in that certain pruning techniques don't lend themselves to parallelism so you lose both ways.

The computation is almost certainly memory constrained. The matrix solver needs to have plenty of cache to solve the sparse equations and is likely making assumptions about cache lines remaining in cache.

Two processes trying to do the same sort of thing will fight like hell for the available resources. I expect LT Spice is very cache aware even if it is only single processor friendly.

Try looking at resource manager and I expect you will find memory access pegged to the maximum. I'm pretty sure it would be the same on any OS.

Reply to
Martin Brown

What about disk access? AFAIK an LTSpice instance by default saves its work to disk as it goes along, see e.g.

formatting link
Reply to
bitrex

Quite likely it is also a factor and putting the machine on a UPS and using the more dangerous disk write caching strategy might speed it up.

I'm assuming that anyone half serious about doing this will have the fastest possible SSD and on the fastest interface (which is very good when compared to spinning rust). You can gain almost another factor of two by having a matched RAID pair if your hardware supports it.

But first you need to identify which bottleneck is the real problem and holding back performance. Doubling physical ram is fairly cheap.

Reply to
Martin Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.