LTSpice runs slow on Apple Silicon M1 - Page 1
Forum section: electronics / general

author: ts125rider
author_rank: Newbie
timestamp: December 04, 2021, 06:06:51 pm
content: Hi folks!I've got this new Apple Macbook Air M1 with 8 CPU, 8 GPU cores and 8GB of RAM.I've tried to run an LTSpice simulation on this machine. The simulation took about 20 minutes to finish on a Dell XPS 13 (i5-1135G7, 8GB RAM) and about 30 minutes to finish on a desktop PC (i5-6600K, 16GB RAM).The simulation never finished on the Macbook, because I've stopped it after 1.5 hours (around 45% completion). There was no convergence issues, since other two machines could run it perfectly fine, also the Macbook never stuck in a single timestep, however it calculated the timesteps very slowly.I have to admit that the simulation isn't the most optimized, but it is definitely can be solved.I'm using the latest version of the program which is ported to Apple Silicon M1, so it runs natively, however the activity monitor only about 15% processor utilization when I run the simulation. The backside of the Macbook is cold so there is no thermal throttling.Have anybody experienced similar thing? Do you have any idea how can I increase the simulation performance?Thanks,Mate

author: JDW
author_rank: Frequent Contributor
timestamp: September 02, 2022, 05:35:39 am
content: It always frustrates me to no end when people never reply to my posts. Thousands of views of your post, but my reply is the first. Crazy!While I don't have an answer for you, I am experiencing a major slowdown after upgrading from MacOS High Sierra to MacOS Mojave, as I mentioned in a post today on the ADI EngineerZone forum:https://ez.analog.com/design-tools-and-calculators/f/q-a/562293/lt-spice-unbelievably-slow-after-upgrading-macos-from-high-sierra-to-mojaveI would encourage you to post there because it's quite obvious no one here seems interested in LT Spice, which I find rather odd. Or maybe it could be that everyone is on Windoze rather than MacOS.

author: 3roomlab
author_rank: Frequent Contributor
timestamp: September 02, 2022, 05:48:17 am
content: post a sample work which has problems, files schema models etc

author: JDW
author_rank: Frequent Contributor
timestamp: September 02, 2022, 06:44:56 am
content: Trust me, it's not tied to my ASC files because those were the exact same simulation files I used on the exact same version of LT Spice just a day ago prior to upgrading from High Sierra to Mojave. It's not the files. I am searching through the LT Spice group right now to see if others have similar unexpected slowness after doing a MacOS upgrade...https://groups.io/g/LTspice/

author: RoGeorge
author_rank: Super Contributor
timestamp: September 02, 2022, 07:00:10 am
content: As a temporary workaround, I would try running the Windows version of LTspice with the help of WineHQ:- install WineHQ for Machttps://www.winehq.org/- download theWindowsversion of LTspice (not the Mac LTspice)https://ltspice.analog.com/software/LTspice64.exeand install it inside WineHQPlease note that Wine is not a Windows simulator, Wine only translates the Windows OS calls into host OS calls (here BSD calls, because Mac is a BSD type of OS AFAIK). I am using the same setup (Windows version of LTspice installed and run with Wine) to make use of LTspice on either Linux or FreeBSD.Don't have a Mac, so can not test this workaround for Mac, but it might work.Later edit:Doh, the M1 mac is the ARM based mac, right? If so, I don't think that workaround would work, my bad, sorry.

author: JDW
author_rank: Frequent Contributor
timestamp: September 02, 2022, 07:09:19 am
content: The original creator of this thread is the only person here thus far who has an M1. I myself have a mid-2015 5K 27" Intel Mac. As such, I will consider WINE-HQ and the Windows version, but even if that works, it is still nevertheless disappoint to me that LT Spice became unusably slow when I merely updated the OS from High Sierra to Mojave.

author: onsenwombat
author_rank: Contributor
timestamp: September 02, 2022, 01:56:13 pm
content: Not contributing to the problem here, but I've had my Mac LTSpice (M1 native) getting stuck here and there on (possibly not very well set up) simulations quite easily while precisely the same asc runs just fine on Windows. Would not be surprised therefore if the Mac port had a whole bunch of other problems.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 02, 2022, 07:23:35 pm
content: Quote from: onsenwombat on September 02, 2022, 01:56:13 pmNeither would I. LTSpice is great when it works (especially because it's fast - at least compared to many other spice simulators - and contains a lot of AD/LT models which are relatively faithful to the original parts, which is good if you uh, actually want to use their parts), but it has a lot of unfixed bugs: the LTSpice XVII that replaced the IV series introduced a number of annoying bugs and quirks that never got fixed. Since this "evolution" from IV to XVII was somewhat hectic, I wouldn't be surprised if any port to a different platform was even more so.I dunno if the IV to XVII came with a change of development team. I suspect so.

author: iMo
author_rank: Super Contributor
timestamp: September 02, 2022, 07:32:45 pm
content: Could it be in some differences in FPU units? LTSpice most probably is using some special features within FPU units in the Intel CPUs (as it is a number cruncher)..

author: JDW
author_rank: Frequent Contributor
timestamp: September 05, 2022, 01:03:45 am
content: Well, only two replies in theLT Spice Group here(I am "James W."), but neither were of any help to resolve the current slowness. I absolutely HATE running any Windoze apps on my Mac, but per the previous comment here about WINE, that seems to be my ONLY recourse, sadly. While I did install WINE and the Windoze version of LT Spice on it, I've previously spend hours installing many parts into my MacOS install, so none of my ASC files will work in LTSpice for Windows on my iMac without major tweaks. I just don't have the time to fiddle around with that right now. It's a big frustrating problem!As an example, here's aZIP filecontaining one of my ASC files with linked Spice models embedded, and with 2 of the required *.asy files which cannot be embedded in the ASC file, so you would need to put those in lib>sym. Sadly, even with this improved ASC file, the Windoze version of LTSpice still gives me the following error:Unknown sub circuit called in:xu3 n006 n001 0 in 744877004Where 744877004 is the Wurth coupled inductor in the ASC file required to make the entire power supply simulate. Still haven't figured out how to fix that. Please let me know if any of you can.Quote from: imo on September 02, 2022, 07:32:45 pmMy Mac and its chips have not changed. Only the OS changed. I don't see how a change in the OS would affect how floating point operations are used on an OS level. But clearly something has changed in terms of how LT Spice works in Mojave. It was so seamless under High Sierra!

author: iMo
author_rank: Super Contributor
timestamp: September 05, 2022, 06:35:15 am
content: Your model name there is wrong, it seems..It should be7345_744877004_4.7u

author: RoGeorge
author_rank: Super Contributor
timestamp: September 05, 2022, 06:35:17 am
content: When I try to open your ASC, there is an error, LTspice "Couldn't find the symbol(s): GRM31CR72A105KA01_DC0V_25deg CTMK325B7226_MHP", which means some libraries are missing.Did the simulation used to work in the former native Mac LTspice install?If yes, then you'll need to copy or to symlink the directory of LTspice libraries from the native LTspice install to the Wine LTspice location for libraries. I don't know where these directories are by default in Mac, in Linux/Wine default installs, the LTspice libs are in~/Documents/LTspiceXVII/lib/Copy or symlink there all the files from "former/place/for/MacLTspiceXVII/lib" to "~/Documents/LTspiceXVII/lib/", and it should work.To fix the missing symbols error, you have to either inform LTspice where to look for them (for example by adding an .include in the schematic), or to just put the .sym files where the .asc is (meaning to copy "LTspiceXVII > lib > sym > AutoGenerated/TMK325B7226_MHP.asy" and "JDW_Example_ASC/LTspiceXVII > lib > sym > AutoGenerated/GRM31CR72A105KA01_DC0V_25degC.asy" in the same directory where .asc is. (generally, I would avoid spaces and weird characters like ">" in names)Another way will be to reinstall the missing libs and symbols in Wine/LTspice the same way as you did in Mac/LTspice.TL;DR those are generic advices, the attached zip should run now (it runs on my Kubuntu-Wine-LTspice). Just unzip all the files in the same directory and open the ASC with the wine LTspice.The model for the U3 transformer was missing, I've downloaded it fromhttps://www.we-online.com/catalog/en/WE-DD#744877004(the PSpice models are compatible with LTspice), and added an .include in the schematic, and changed the former 744877004 into the proper name (and put it as value, not as spice model).Use the attached .zip file and it should run, all the extra models and symbols are in the zip already.The general idea is to make available the missing files, and eventually to include them in the simulation using .include spice directive (in the schematic) in case LTspice does not know where the models are.

author: JDW
author_rank: Frequent Contributor
timestamp: September 05, 2022, 06:39:15 am
content: The two ASY files are indeed inside that ZIP archive. Another Windows user in the LT Spice group complained about the same, but he eventually found the files. Here's what he said about that:https://groups.io/g/LTspice/message/140161And here is my reply:https://groups.io/g/LTspice/message/140166You may also wish to read the full discussion because it might be helpful in informing you about every single thing that I have tried (sadly in vain)...https://groups.io/g/LTspice/topic/93414694Thanks!

author: iMo
author_rank: Super Contributor
timestamp: September 05, 2022, 06:48:31 am
content: See above my post on the wrong model name. The one there is the correct one, imho, nothing special to include is needed (ie. open the Wurth's lib and see the proper subckt names).Also delete the line with your link to the file on your filesystem from the 2 autogenerated files..For example this oneSYMATTR ModelFile /Users/james/Documents/LTspice/GRM31CR72A105KA01_DC0V_25degC.mod

author: JDW
author_rank: Frequent Contributor
timestamp: September 05, 2022, 06:54:07 am
content: Incorrect. There appears to be a difference between Mac and Windows versions when it comes to part naming. The full discussion in the LT Spice group I started explains all that in detail here:https://groups.io/g/LTspice/topic/93414694Take note that I am running the Windows version via WINE too, which allows me to test the Mac and Windows versions. The Mac version will let me simulate (albeit slowly), but I've not yet found a way to get the ASC file to simulate in Windows. I give an exhaustive set of things I tried in that LT Spice group.

author: iMo
author_rank: Super Contributor
timestamp: September 05, 2022, 07:07:50 am
content: OK, I've just read your chat on groups, but you write there your Windows version shoots the error with 7345_744877004_4.7u as well. My Windows version works fine with that name.Thus it seems to me you have a problem with installation, imho.Mind there are 2 different places with libraries in Windows LTSpice - one is in Documents, the second one in LTSpice installation, one is read only and they are syncing when you do an upgrade.. So perhaps an issue there with the libs.. Your Win version has to work fine with that transformer name..Speed - also mind there are various options/methods and switches in LTSpice you have to master when coping with speed of your simulation..Also ".ic" (initial condition) directive sometimes helps with speed as well..

author: JDW
author_rank: Frequent Contributor
timestamp: September 05, 2022, 07:11:07 am
content: See the latest post made only moments ago. I just obtained the solution to get the Windows version (in WINE) to run. It's this filename that must be used on the coupled inductor to make it simulate!DD_7345_744877004_4u7I am running the simulation now, but it seems fast thus far in Windows than in the Mac version, which implies a problem with the Mac version when running under Mojave, which does not exists under MacOS High Sierra.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 05, 2022, 07:12:55 am
content: JDW, have you seen the self contained zip prepared for you, and attached in this messagehttps://www.eevblog.com/forum/eda/ltspice-runs-slow-on-apple-silicon-m1/msg4399483/#msg4399483?Does that runs on your LTspice?

author: JDW
author_rank: Frequent Contributor
timestamp: September 05, 2022, 07:20:32 am
content: Quote from: RoGeorge on September 05, 2022, 07:12:55 amMy apologies for not having tried your file earlier. I now have it opened in the Mac version of LT Spice on my Intel Mac running MacOS Mojave, and once my current simulation in the Windows version (using WINE) is finished, I will give your file a go. But what I can say for now is that the simulation speed in the Windows version is on par with what the Mac version of LT Spice was under MacOS High Sierra. So something in the OS update to MacOS Mojave is not playing well with LT Spice. Or rather, LT Spice is not playing well with something in Mojave. In any case, I will report back in a bit. Thanks!UPDATE: WINE simulation finished! I will report the numbers later.Your ASC file does NOT work in the Mac version of LT Spice because you are using the "DD_7345_744877004_4u7" filename, which is correct only for Windows, not for the Mac. That is explained here:https://groups.io/g/LTspice/message/140180

author: RoGeorge
author_rank: Super Contributor
timestamp: September 05, 2022, 08:21:40 am
content: No need to apologize. The zip I've attached is for the Wine LTspice, interesting that it doesn't work for Mac LTspice, thanks for telling that.Good to know the temporary workaround works, so you don't have to just sit and wait until an official fix for the new OS will be released.

author: montemcguire
author_rank: Regular Contributor
timestamp: September 06, 2022, 05:04:47 am
content: A somewhat sloppy and incomplete data point, but I too have recently updated from High Sierra to Mojave on my mid 2015 MacBook Pro (MacBook Pro 11,5 with a 4 core 2.8GHz i7) and I have not noticed any significant slowdowns or problems.I am now running LTspice XVII version 17.0.42, but I did have an issue where the automatic update failed miserably merging the libraries with the newly downloaded updates, so it never got around to updating the binary. The solution was to de-install, download the current version and then re-install, just to avoid the broken update function. It became stuck at 17.0.30 for a year or so, and I finally just nuked it and reinstalled it. The update function is pretty useless, but what can you do.I do have an 8 core i7 10700K Windows 10 machine with LTspice XVII but it's not radically faster than the Mac. In general, my simulations don't spend much time grinding tiny timesteps, so it might not be a representative comparison to your workload or the slowdown. Still, I have not noticed much of a difference (or any actually) since I left High Sierra last October. I will hopefully be receiving a more modern i9 MacBook Pro tomorrow, and it'll probably come installed with Monterey. Hopefully, I can get some time soon to poke at it and see how things work.

author: JDW
author_rank: Frequent Contributor
timestamp: September 06, 2022, 05:14:40 am
content: Quote from: montemcguire on September 06, 2022, 05:04:47 amDo you simulate with Marching Waveforms ON or OFF? I have been simulating with it ON.You should check out my ("James W.") recent posts about that in theLT Spice Group here.SUMMARY: The Mojave BUG exists and remains a problem when zooming on the plotted waveform, but killing Marching Waveforms allows it to simulate at full speed without slowdowns.

author: montemcguire
author_rank: Regular Contributor
timestamp: September 08, 2022, 01:49:30 am
content: So, I did a little digging. It seems like there is no control panel button to turn Marching Waveforms on or off, and they seem to be always enabled. There is however an option that can be added to a simulation:.options nomarch=1This seems to turn off Marching Waveforms, but for the random .trans simulation I loaded, the logfile says 36.391 seconds for nomarch=1, and 37.126 seconds for marching waveforms on as default. This doesn't seem like much of a difference, but the logfile says it is slightly different. This is on Mojave 10.14.6 with all updates.I will look at the group - I am a member, but I do not follow closely...

author: JDW
author_rank: Frequent Contributor
timestamp: September 08, 2022, 02:04:18 am
content: Quote from: montemcguire on September 08, 2022, 01:49:30 amIt was recommended to me a couple days ago. I've posted detailed numbers here ("James Wages"):https://groups.io/g/LTspice/topic/lt_spice_very_slow_after/93414694?p=Created%2C%2C%2C20%2C2%2C20%2C0&jump=1Go to page 1 of that discussion to see more of my simulation times, including Windows on WINE.As you can see in that discussion, it doesn't solve all the problems. UI slowness still remains. One other Mojave user claims he has no such problems, which is great for him, but it hasn't offered me a solution.Under MacOS High Sierra, I had none of these issues.

author: montemcguire
author_rank: Regular Contributor
timestamp: September 08, 2022, 06:36:02 am
content: I read your note in the linked groups.io thread:By the way, the slowdown does start at the 12ms (simulated time) point, when the current starts to ramp up to 200mA. It becomes almost unbearably slow once it reaches 150mA, but if you leave it that way for a few hours, it keeps going and, amazingly, gets slower and slower, so by the time you reach the 22ms point, it's beachballs galore and switching from another app like Outlook to LT Spice (Mac version under Mojave) takes no less than 60 seconds for the UI to draw. It is that slowness which prompted me to start this thread.This sounds to me like the machine is thrashing - suffering from a deep lack of RAM, and using paging to disk or slower memory, or simply falling out of L2/L3 CPU cache while trying to cope with a large working set despite low RAM. It's generally not possible to add memory to a lot of Macs, so the approach unfortunately has to be to reduce the complexity of the simulation.You can quit other running programs to free up memory, but this only gets you a fixed increase in memory, and if the simulation goes "geometric" with ever increasing memory requirements, it only staves off the simulation time where the simulation crawls to a halt.Another possible taxonomy is that there's a memory leak, but this should not cause problems with a well designed paging system, since the leaked memory will not be used ever again, and can be returned to the free list, and only cause a small amount of inefficiency.So: why would a large simulation fail on the Mac and not the PC? There could be some differences in how virtual memory and paging is handled between the two OSes, but in the timings shown in the thread, it seems like both simulations get bogged down - it takes 30 minutes to get to 22ms under Wine. I never have the patience to run a simulation that long, since I mostly use a laptop, and I don't want to cook it. I did build a desktop i7 10700K with a big heatsink so I could pound it for some simulations, but I still do not have the patience to wait for that.I have run some simulations of switching regulators where using, for example, accurate 8 component models for each capacitor caused the sim to crawl and become essentially useless. I was able to get these simulations to be useful for design by replacing some of the accurate capacitors with ideal capacitors, chopping down the number of nodes, and thus greatly reducing the size of the matrices used to represent the simulation.If you can do this with any of the components in your simulation, or somehow provide some other ways to reduce the complexity of the simulation matrix, you may be able to fit the simulation into a smaller memory footprint, and avoid hitting the “thrashing” point where it all goes to pieces.I’m just spitballing here, but those execution times are deeply useless, and I think it would serve you best to try to find ways to reduce the simulation complexity somehow. I have done things like that with a few large switcher simulations and I was able to transform a useless sim into something I could design with.

author: JDW
author_rank: Frequent Contributor
timestamp: September 08, 2022, 06:41:59 am
content: Quote from: montemcguire on September 08, 2022, 06:36:02 amThank you for the analysis and suggestions.As I mention later in that discussion, it is absolutely, positively not a lack of memory. I have 32GB and I confirmed in Activity Monitor that not even a single big of SWAP it used. (When you run low on RAM, swap is used.) I also have a super fast Apple internal 1TB SSD, so writes to/from that SSD are not slow. That pretty much leaves the "memory leak" you mentioned being perhaps the cause. But that is something on an OS level that I have no control to fix. We also don't know if it is that.All I can say is that I am missing MacOS High Sierra. I only updated because some software I need to use and test requires Mojave minimum. People often mocked me for not being on Mojave, but I knew that something would go wrong when I upgraded, and sure enough, it did. :-(

author: montemcguire
author_rank: Regular Contributor
timestamp: September 08, 2022, 06:46:03 am
content: Ugh!Let me think some more and see if I can come up with anything more.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 08, 2022, 07:11:07 am
content: If the slowdown is specific to a certain schematic only, then try to change the "Default Integration Method", either from control panel or by specifying the method inside the schematic, by adding a spice directive like this:Code:.options method=gear

author: JDW
author_rank: Frequent Contributor
timestamp: September 08, 2022, 07:30:46 am
content: Quote from: RoGeorge on September 08, 2022, 07:11:07 amFascinating. Changing from "modified trap" to Gear resulted in the simulation speed going back to the great speed I had when using MacOS High Sierra! The main downside is that it doesn't fix UI slowness when dragging inside the waveform to Zoom. But simulation is significantly faster while using Marching Waveforms.I must assume that Gear is less accurate because it's so much faster? When I zoom into the ripple on the voltage output of my simulated switcher, the sawtooth is less consistent with Gear than with "modified trap."Very interesting! Thank you for the suggestion.However, the UI slowness is still there. In the early part of the simulation, with Marching Waveforms ON, clicking on a menu takes 2 seconds for it to drop down. But at about the 18ms point in the simulation, it takes 40 seconds for menus to drop down! Then after the simulation is done, clicking to drag within the plot window is very, very slow. So while using Gear helps, it's not a solution for the root problem.