LTSpice: Low CPU utilization?

[IDEngineer]

My son is in his fourth year of a BSEE at CalPoly. They have the students using LTSpice. Since he also uses SolidWorks and a few other CPU-intensive programs, he has a rather unsexy (to the typical student) but powerful laptop as his primary computer - i9 CPU, higher end Nvidia GPU, 32GB memory, only SSD's, etc. He has a 32in monitor, separate keyboard and mouse, etc. so it feels like a regular workstation when at his apartment but he can backpack it to class and labs too.

He called me for advice but I'm no LTSpice expert, so here's the question. When he's running LTSpice, some simulations take a while. No problem there, that's a complexity issue or component parameter choice or whatever. He knows to not run anything else, we've pared down his machine so it doesn't have a bunch of crapware on it, etc. All the usual tweaks one does to optimize a machine. He's sadly stuck with Win11 since the machine is rather new, but otherwise it's pretty lean.

The problem is, LTSpice never exceeds ~30% CPU usage. Other programs happily consume 100% of the CPU if nothing else is running. But LTSpice just sits there at 1/3rd throttle, not taking advantage of all the available horsepower.

I seriously doubt LTSpice is written to use hardware acceleration in the GPU, which would otherwise be an explanation since that would not appear in Task Manager's CPU info. Another thought which occurred to me just now is that perhaps he's memory bottlenecked, with the CPU waiting around for external memory fetches, but I don't know if that would appear in CPU utilization. I'll have him check memory performance.

It seems like he could cut his simulation times by 2/3rds if LTSpice simply used 100% of the CPU.

Failing a memory bottleneck... what would prevent LTSpice from running at full CPU speed? Regardless of the number of threads it does or doesn't create, there's a lot of CPU cycles available that aren't being used. What would cause that?

[Benta]

The different flavors of Spice don't use that much CPU. What they do use is a lot of memory. I think that's the limiting factor.

[IDEngineer]

So are you suggesting that it maxes out allocatable memory and the CPU is waiting on swaps to/from external RAM? It's sitting at 30% total utilization because the on-die cache isn't large enough to hold the short-term working set?

[tom66]

You didn't mention how that CPU usage is measured.  I am assuming since it is a modern laptop with an i9, it is something like an i9-13900H, which has 14 cores and 20 threads (asymmetrical power architecture like ARM's big.LITTLE).

These processors are very fast at work that is well-parallelised.  Computer scientists call this kind of work "embarrasingly parallel".  Examples include video compression and decompression (as each macroblock can often be examined as one individual item), 3D raytracing on the CPU, compiling large packages of software and some types of file compression.

However, for applications that cannot be parallelised so well, they may exhibit little to no performance benefit on these processors.  Circuit simulation does seem like something that would be hard to parallelise, because you might well have to wait for all of the results from one simulation iteration before the next is started. In fact in some cases higher parallelism can slow tasks down if the problem does not partition well. 

Most of the performance improvements in modern computing have not come in the form of faster single threaded performance.  There is no doubt that processors today are faster on single thread benchmarks, but the massive performance increases noticed are primarily in multithreaded workloads.

LTspice is not particularly good, in my experience, at using multiple threads.    I just tried a test with the LT3496 example with threads set to maximum.  It runs at  around 1.1ms/sec, and CPU utilisation is 20%.  I have a Ryzen 3800X, which is an older generation Zen architecture processor from AMD, it has 16 threads over 8 cores and runs at 4.1GHz normally.  The CPU utilisation chart from Task Manager looks like this, it is clear that it is dominating four cores, but actually really only using two at any one time.  To maximise performance the Windows kernel is swapping between cores to get the best benefit from the on-core cache (32KB I+D per core).  But otherwise the other 12 threads I paid for are going unused.  Shame!  I set the max threads to 1, and LTspice is only barely slower: 1.02ms/sec vs 1.1ms/sec.  This shows whatever benefits it gets from a multicore processor are minimal, at best.

To get this display you need to switch on the multiple CPU view in Task Manager.  By default it only shows one CPU.

This is not a memory limit, this is entirely a CPU limit, but you have hit the single threaded CPU limit of the laptop I expect. 

Edit: corrected error, re-read your post.

[iMo]

At ltspice@groups.io there is a database with performance benchmarks.
What the people there indicate - no improvement with using more than 4 threads, and the gpu does not help as well..

https://groups.io/g/LTspice/table?id=16697&lv=1&p=5%2C%2C%2C20%2C1%2C0%2C0
https://groups.io/g/LTspice/topic/building_a_fast_ltspice/85590859?p=

The newest version 24 may work a little bit faster, however..

[SiliconWizard]

It definitely doesn't use any GPU.
The average CPU use is completely dependent on how the Spice simulator is multithreaded, and it's notoriously hard to write a Spice simulator that can use parallelism very efficiently. LTSpice is no exception, but I can just say that they have improved parallelism a lot in LTSpice 24, so if your son hasn't updated yet, he definitely should. That'll make a big difference. Still never hits 100% CPU use, but it certainly does better than the previous major version.

As to technical details, I'm pretty sure they haven't really written any really specific parallel code, and they probably use OpenMPI or something like this, with just some hints here and there in code about what it should try to run in parallel.
The performance boost in LTSpice 24 is likely not a revolution, but possibly just the sign of having updated to the latest version of OpenMPI, and maybe marking a few more "critical" sections of code appropriately, but I doubt it's much more than this. But I don't blame - a more efficient parallel implementation would imply rewriting the whole simulation engine from scratch, and getting better results would still be questionable (it's hard stuff.)

[IDEngineer]

Thanks all!

I've written quite a bit of fully parallel code, running on dedicated threads to take advantage of multiple cores, for the Win32 environment so I'm painfully familiar with how people can do it incorrectly. I accept that LTSpice isn't fully optimized to take advantage of all the cores in modern processors - indeed, as some here have noted, some problems cannot be made fully parallel.

Side note: It is possible to create too many threads and DEcrease performance due to the overhead of thread scheduling, cache overwrites, and other things. Optimizing that is usually a moving target. I don't expect LTSpice to be a tour de force of parallel processing authorship.

If we presume that LTSpice is running on multiple threads, then the maximum possible CPU utilization would be (threadcount / corecount). I'm not located where the machine is, but I'll get my son to provide screenshots of Task Manager showing not just total CPU but also how the workload is distributed across the cores.

More when I have it... thanks so far!

[DimitriP]

Laptop CPU models look similar to their deskttop counterparts but not as fast.
I9-something on a laptop, without knowing the exact model including any suffices is vague.

Although balanced power more is supposed to ramp up speed "as needed", there are times where setting the machine to  Performance mode does make it run faster.
As for LTSPICE, there is a temporary folder setting that if you have multiple drives, specify a folder on a different disk other than C:
On the same tab in settings-Operation there is also a RAM % for fast access conversion.

On the SPICE Tab there is also a setting for thread priority  and max threads.

Worth taking a look at and experimenting...unless you've already "been there done that".
Good luck
 

[iMo]

..but I can just say that they have improved parallelism a lot in LTSpice 24, so if your son hasn't updated yet, he definitely should. That'll make a big difference. Still never hits 100% CPU use, but it certainly does better than the previous major version..

From my observation they mostly improved the convergence of the solver and perhaps the intrinsic models in the 24. Some of my sims here run just fine in the 24 and the exact sources when opened in the XVII struggle heavily to show any results at all..

[hans]

Thanks all!

I've written quite a bit of fully parallel code, running on dedicated threads to take advantage of multiple cores, for the Win32 environment so I'm painfully familiar with how people can do it incorrectly. I accept that LTSpice isn't fully optimized to take advantage of all the cores in modern processors - indeed, as some here have noted, some problems cannot be made fully parallel.

Side note: It is possible to create too many threads and DEcrease performance due to the overhead of thread scheduling, cache overwrites, and other things. Optimizing that is usually a moving target. I don't expect LTSpice to be a tour de force of parallel processing authorship.

If we presume that LTSpice is running on multiple threads, then the maximum possible CPU utilization would be (threadcount / corecount). I'm not located where the machine is, but I'll get my son to provide screenshots of Task Manager showing not just total CPU but also how the workload is distributed across the cores.

More when I have it... thanks so far!

Multi core also doesn't mean all cores. Workloads "that partition well" is still a qualitative measure. More quantitatively you could look at e.g. Amdahl's law. The "embarrassingly parallel" workloads previously mentioned are probably in the order of 90%+ parallelization. That makes them still scale well up beyond 8 or 16 cores. Some video encoders such as H264 are already topping out though on modern CPUs, so to "benchmark" H264 performance on such CPUs you would have to run multiple instances in parallel to truly stress all cores.

LTSpice is a very simple SPICE program. It gets the job done for simple projects, but its simulation options leaves a lot to be desired. But that's OK.
I wouldn't expect it to utilize 100% on modern CPUs with 8 cores or more. I have never seen it at least, at most a few threads at full blast. And the more cores/threads newer CPUs will have, the lesser overall CPU utilization it looks to be in total.

Other SPICE packages such as ADS or Cadence have more sophisticated tools for batch job processing (e.g. sweeping a parameter which then requires 50 simulation runs). Those batches could be parallelized easily as each job is independent from others. LTSpice can also do parameter sweeps, but still runs each simulation job sequentially.
But if the course material or university doesn't use those 'better' tools , then that's a moot point.

Now I still want to add that an i9 will run LTspice marginally faster than say an i5. Even if the workload maxes out at a handful of threads.. its very likely such chip has a higher boost clock and potentially even TDP limit to cope. However, these differences are fairly small. E.g. a i9-13900 desktop chip is only 15% faster than a i5-13600 desktop chip in Geekbench 5/6 single-thread (5.6GHz vs 5GHz = +12%).

[tooki]

A much more important tip, which I only learned about just recently, is that in LTspice, some generic components (semiconductors, not passives, IIRC) consume vastly more CPU power to simulate than the “specific” ones. So choose an actual component model rather than a generic one.

[iMo]

..and with the LTspice (or better to say with Spice) there is still the fundamental issue with Temperature (for a half of century already)..

You cannot simulate the circuits with the real temperatures of the components used.
What you can do is to "step" through the temperature of entire schematics, or, through an individual component.
During a "simulation run" (== the step) the temperature(s) is kept constant today (what is a nonsense in reality).
So the results we get today might be unrealistic (and they are "imprecise" always). What we need is to be able to feed the temperature back into the intrinsic models (the temperature of any intrinsic component used "on the fly"), based on the actual power loss (or any arbitrary temperature) of any particular component, thus we may simulate the "thermals affecting" the component (that is easy in LTspice today as we get actual power loss and we may simulate the thermal flows outside the intrinsic models).
You can/may today easily simulate a complete nonsense, and many will be happy with the results.

.. and when the issue will be "fixed" (hopefully ADI will think about seriously), the computational performance of the LTspice starts to be challenged even more.. 

[Siwastaja]

A much more important tip, which I only learned about just recently, is that in LTspice, some generic components (semiconductors, not passives, IIRC) consume vastly more CPU power to simulate than the “specific” ones. So choose an actual component model rather than a generic one.

Yes and this was highly unintuitive for a beginner who would expect that the generic models are "simpler" and thus faster to simulate...

Another point is, I have no idea if it's true in $current_year because I always choose specific, real part numbers since... 2006 or so... but those generic components might not work at all, or have really weird characteristics. I remember trying to simulate some voltage doubler circuit thinking that surely default diodes would be "ideal" but in fact they simulated breakdown at some (surprisingly small) voltage, so one had to choose an actual HV diode part number!

[Ian.M]

The problem is due to maintaining Berkeley SPICE 3 compatibility.  The SPICE 3 diode default parameters are somewhat unhelpful.  See https://ltwiki.org/files/SPICEdiodeModel.pdf

For an ideal diode, (or at least as near to one as LTspice is happy with) use:

Code: [Select]

.model Dideal D(Ron=1n Roff=1G Vfwd=0) ;Ideal diodewhich you can paste straight onto your schematic then invoke by name.
It uses a piecewise linear model with a breakpoint at 0V, which can still be problematic solving the transition if there is no or very little capacitance across the diode.
N.B older LTspice versions were unhappy with more than about 12 orders of magnitude between Ron and Roff.

[RoGeorge]

From LTspice menus, go to Tools -> Control Panel -> SPICE, and in the 'Engine' group you can change '"Max threads: (how many cores are allowed to LTspice), and/or "Thread Priority:" (how intense usage is allowed for each core).

Regarding some simulations that can take very long, that is usually because of convergence problem, not because of the complexity of a circuit.  For convergence issues there are a few workarounds if you search online, though the solution depends from one case to another.  Most often it is enough to change "Default Integration Method:" from the same panel as the number of cores.  Other times changing one of those numerical limits on the right hand column might help speeding up all from minutes to seconds.

The Integration Method can also be change from inside the schematic drawing (and for that schematic only), if you place a spice directive near the circuit.  For example, to change from the default (modified trapezoidal) to "gear" you add in the schematic this spice directive:  .option method=gear, or .option method=trap.

Similar (a .options line) can be done for the values of "Reltol:", "Gmin:", etc. in case they have to be changed for a specific schematic only,  see the LTspice wiki for more details:  https://ltwiki.org/LTspiceHelp/LTspiceHelp/_OPTIONS_Set_simulator_options.htm

Random search result for LTspice speed up simulation:
https://ltwiki.org/?title=Pure_Inductor_and_Voltage_Source_Modelling_(and_how_to_speed_up_simulations_with_them)_using_LTspice
https://electronics.stackexchange.com/questions/262663/how-to-trace-down-why-ltspice-simulation-is-slow
https://www.analog.com/en/resources/technical-articles/ltspice-speed-up-your-simulations.html