Puget Systems print logo
Read this article at https://www.pugetsystems.com/guides/1555
Article Thumbnail

SOLIDWORKS 2019 SP3: AMD Ryzen 3 vs Intel 9th Gen Core

Written on August 28, 2019 by William George


AMD recently launched an updated generation of their mainstream Ryzen processors, with increases to both core count and clock speed / per-core performance. We've already tested these chips on a wide range of applications, and now it is time to look at how they handle a professional engineering program: SOLIDWORKS.

Dassault Systèmes latest fully-released version is SW 2019 SP3, so we've run three of the new AMD chips and a pair of their Intel competitors through a round of benchmarks using this software. Let's see how they fared!

Looking for an Engineering Workstation?

Puget Systems offers a range of powerful and reliable systems that are tailor-made for your unique workflow.

Configure a System!

Labs Consultation Service

Our Labs team is available to provide in-depth hardware recommendations based on your workflow.

Find Out More!

Test Hardware & Methodology

Here are the detailed specs of the test platforms we used:

AMD Test Platform
CPU AMD Ryzen 9 3900X
AMD Ryzen 7 3800X
AMD Ryzen 7 3700X
CPU Cooler AMD Wraith PRISM
Motherboard Gigabyte X570 AORUS ULTRA
RAM 4x DDR4-2666 16GB (64GB total)
4x DDR4-3200 16GB (64GB total)
Video Card NVIDIA Quadro P6000 24GB
Hard Drive Samsung 960 Pro 1TB
Software Windows 10 Pro 64-bit (version 1903)
Intel Test Platform
CPU Intel Core i9 9900K
Intel Core i7 9700K
CPU Cooler Noctua NH-U12S
Motherboard Gigabyte Z390 Designare
RAM 4x DDR4-2666 16GB (64GB total)
Video Card NVIDIA Quadro P6000 24GB
Hard Drive Samsung 960 Pro 1TB
Software Windows 10 Pro 64-bit (version 1903)

The tests conducted on these systems were originally developed by my colleague here at Puget Systems: Matt Bach. He put together a series of AutoIt scripts that run through testing a variety of the capabilities in SOLIDWORKS, so rather than reinvent the wheel I used his. Minor updates were needed to bring the scripts up to speed for SW 2019, but we did take this opportunity to add a more demanding flow simulation test provided by a contact at Dassault. He described it as a "Conjugate Heat Transfer Airflow" model, but I'm just calling it our "benchmark simulation". It is run at three different mesh sizes, to see if that has any impact on performance scaling.

Between our last round of testing on SW 2019 SP1 and this testing of SP3, something does seem to have broken the macro we use for rebuild testing. I didn't have time to dig in and fix that, so it was excluded - but based on prior tests, the the relative speed of rebuilding a model tracks almost exactly with the performance we see when opening files. So if you want to know how different CPUs would compare during a file rebuild, just look at the file open chart - which will be the first one in the gallery.

The tests were run multiple times on each CPU, with the fastest result (lowest time) used for this article. We didn't have any significant outlier results and saw very little variance between runs, so we opted for this method over an average of scores. The results are broken up into individual graphs below and followed by our analysis.


Here is a gallery showing the results from each part of our SOLIDWORKS testing. AMD Ryzen chips are shown in red and Intel in blue:


These new Ryzen processors do fairly well in SOLIDWORKS, which has historically been a stronghold for Intel due to their higher performance per clock in past generations. Intel still wins in a few tests: file open (and thus also probably rebuilding), motion study, and stress & thermal simulations. AMD wins clearly in rendering, and the Ryzen 9 3900X edges out the i9 9900K slightly in our high mesh count simulations.

Overall, if you going to be rendering a lot, AMD is the better choice of these two platforms - but there are other CPUs (both from AMD and Intel) that have even more cores and will be faster yet with pure rendering. For basic usage, focusing mostly on modeling, Intel still has a small edge... but you probably wouldn't be disappointed with a Ryzen chip either. And for heavy simulation workloads, it depends on which types of simulations you run - but all of these processors did very well, with comparable performance at each price point.

Ryzen 3rd Gen Memory Comparison

In addition to comparing CPU performance, we also wanted to take a quick look at the impact of memory speed on Ryzen processors. Most CPUs are rated by manufacturers to support specific speeds of memory, and AMD's new Ryzen 3rd Gen chips are no exception. In this case, the official memory support varies depending on how many modules you have installed and whether they are single- or dual-rank. Tom's Hardware conveniently published these details, which likely came from AMD's reviewer guide (which we do not have):

AMD Ryzen 3rd Gen Processor Memory Support Chart (courtesy of Tom's Hardware)

AMD Ryzen 3rd Gen Processor Memory Support Chart (courtesy of Tom's Hardware)

Since we were comparing to Intel systems with four dual-rank, 16GB memory modules we used 2666MHz memory for that comparison - as that is what AMD's official supported speed is for that configuration. However, we also wanted to test the other end of the spectrum. Ryzen 3rd Gen's fastest officially supported speed is 3200MHz, and while technically that should only be with two memory modules we went ahead and ran a full 4 x 16GB configuration at that speed (to avoid any chance that different amounts of RAM could affect results).

Here is what we found, with the 2666MHz performance shown in the same red as in the charts above while 3200MHz is in orange:

There is a definite divide in terms of how memory speed impacts Ryzen performance in SOLIDWORKS. File opening (and likely rebuilding), rendering, and motion studies don't see much difference at all - maybe a percent or two, but close enough that it would be hard to notice in daily usage. However, most of the simulation tests saw a much bigger benefit to having faster memory. That ranged from 5 to 10% depending on the CPU and specific test, but it was fairly consistent across all of the processors and simulation types.

However, I feel that it is also important to mention that the only stability issues we had with this round of benchmarking was when we were testing 3200MHz memory. Three of our test runs - across two different AMD processor models - crashed during different parts of the simulation testing when using that higher speed memory. Getting faster results on several simulations can be easily offset by having a single calculation run fail and need to be restarted.


It is tricky to make a single recommendation when different aspects of an application behave differently, so this conclusion is broken down based on usage:

  • For general modeling work, AMD's Ryzen 3rd Gen is good but Intel's Core i9 9900K and i7 9700K are slightly better
  • For rendering, AMD's Ryzen chips - especially the R9 3900X - are clear winners
  • For simulations, both sets of processors do well... but definitely go for the higher end (either R9 3900X or i9 9900K) over the less expensive models

If you go with AMD, and will be doing much in the way of simulations, faster memory speeds may also help - but keep in mind that some combinations of memory module count and higher RAM speeds may put you outside AMD's official support specs, and could lead to instability as well. We will likely stick to their specs in what we offer, to ensure the best reliability for our customers.

Looking for a SOLIDWORKS Workstation?

Puget Systems offers a range of poweful and reliable systems that are tailor-made for your unique workflow.

Configure a System!

Labs Consultation Service

Our Labs team is available to provide in-depth hardware recommendations based on your workflow.

Find Out More!
Tags: Dassault, Systemes, 2019, CPU, Processor, Performance, Intel, Core, i7, i9, Solidworks, AMD, AMD Ryzen 3rd Gen

What a battle royalle between 3900X and 9900K. I have been waiting for this particular benchmark for a while now, so as always thank you.

Posted on 2019-08-30 02:00:19

Um. Why no "Model Rebuild Time" or "Viewport FPS" charts..? Literally the only thing I'm interested in, as it's 90% of the SolidWorks workload around here.

Posted on 2019-09-06 18:45:04

Quoting from the article:

"Between our last round of testing on SW 2019 SP1 and this testing of SP3, something does seem to have broken the macro we use for rebuild testing. I didn't have time to dig in and fix that, so it was excluded - but based on prior tests, the the relative speed of rebuilding a model tracks almost exactly with the performance we see when opening files. So if you want to know how different CPUs would compare during a file rebuild, just look at the file open chart - which will be the first one in the gallery."

As mentioned there, in past tests we saw almost identical performance variance between processors in rebuild time as we did in file open time, which is why I didn't choose to hold back this article until we could fix the rebuild macro. Just take a look at the file open times and that will show you how the CPUs should stack up for rebuilds :)

Regarding viewport FPS, we normally do that sort of testing for GPU comparisons instead of CPUs. I suppose I could do some FPS testing for different CPUs, to see how much impact that has, but at the moment there is a lot of concern over a new setting in Solidworks that vastly improves performance (frame rate) but may come at the cost of image quality. I'm not sure we should go through all of that testing if the results end up not being useful because of that, or worse end up steering folks in the wrong direction. Perhaps it could be done both with and without that setting enabled... but that would double the length of the testing. Hmm - I will consider it when I get back from a trip later in the month.

Posted on 2019-09-06 18:51:31
WeRIdo Lee

I am still struggling on 3900x and 9900k, if you can do the test, it will definitely save me.

Posted on 2019-10-12 17:05:21

We've got a lot of stuff going on at the moment, I'm afraid, and on top of that SW 2020 is out now... so I don't think we'll end up doing any more SW testing until that has matured a bit (SP1 probably). However, I can say with pretty good confidence that both of those CPUs you mentioned will do quite nicely in SW and similar applications. If you do much rendering, I would lean toward the 3900X - otherwise, I would probably stick with the 9900K... but both are fine choices :)

Posted on 2019-10-14 17:02:36

I'm back around to working on SW testing now, Nathan, and specifically updating our benchmark tool to behave properly in SW 2020. Lots of stuff broke with the latest version, and I've fixed most of it... except rebuilding, which didn't work in SW 2019 either (which is why it was missing from this article).

However, I am running into a (good?) problem: it seems like rebuilding is lightning-fast now! In 2018 and earlier, I recall it taking at least several seconds for larger assemblies... but now, even with the biggest one we have, it is just a fraction of a second. Is this your experience as well? If so, I think maybe we can permanently omit rebuild testing from our benchmark.

If it *is* still something that your workflow centers around, though, please let me know a little more about how it impacts you and what situations you are in. Maybe we just need to get a file that is more demanding in that specific way.

Posted on 2020-01-13 20:12:26
Issac Roberts

I'm sure your test matrix includes some of the top of the line SKUs from both Intel and AMD. If the test matrix is not producing a measurable difference in rebuild times at this level, perhaps a supplemental method might be a comparison in rebuild time, file open times, and drawing performance when looking at the lower core SKU too. Obviously, a user with an i3-9350KF would be ill equipped to perform thermal analysis or flow simulation, but how much performance would be gained in the historically clock bound tasks (rebuild, open, drawing) going from a 4C/4T vs an >=8C/16T; multi-tasking aside. Alternatively you could test rebuild time with an artificially poor model.

Posted on 2020-01-15 08:24:54

We often don't have samples of the lower core count processors on hand, which is part of why they are usually absent from our articles. I would be much more interesting in getting our hands on your latter suggestion: artificially / intentionally difficult models, something that may not be real-world for most users but could actually show a performance difference so that the few people who do have extremely complex assemblies could have some data to look at. If anyone reading this has such a project they wish to share, or knows of a relatively easy way to put something like that together, please reach out to me via email! (william at pugetsystems dot com)

Posted on 2020-01-15 17:42:41

Reported rebuild times show its actually slower for me. 400 part assembly I'm working with shows a rebuild time of .22 seconds in 2018SP5, and .26 seconds in 2020SP1. BUT, when I hit "Cntrl+Q" in 2018, it hangs the system for 4-5 seconds and you can't do anything. In 2020, it barely hiccups.

It really doesn't make much sense to me, as there's a part IN THAT ASSEMBLY, that takes ~4.0 seconds to do a full rebuild in both versions. I don't understand how the full assembly can be rebuilt in less than a second. Verification on Rebuild is turned on in both. I take it assembly rebuild times are only counting mates and features in the assembly.

In the end though, you're right, 2020 is way snappier.

I'm still torn on to go with an Intel 9900K flavor or Ryzen 3800X/3900X. The extra 4 cores from AMD really aren't going to help me, but it feels dumb to buy a 9900K instead at the same price. So now I'm heavily leaning towards the 3800X...at least on the AM4 socket there's an upgrade path. Intel insists on new mainboard/socket every little refresh. Take my extra $150-$200 saved on the 3800X vs the 9900K and drop in a 4000 series Ryzen in a year. All that said, it's really hard to leave behind the single-thread performance advantage in SolidWorks that Intel seems to have. Looking forward to an updated roundup from Puget. You guys are the only ones that can get your hands on all this hardware to test it properly (hopefully).

Posted on 2020-01-15 21:25:30

Okay, I'm glad it isn't just me. What we were trying to measure previously (in 2018 and earlier; the rebuild script we had broke in 2019 and I didn't have enough time at that point to look into it) was that 'lag' or delay from executing the rebuild command to having the system responsive again... and that is what seems to be so fast now that I can't practically measure it. I guess I will just continue to skip that, unfortunately, until I find a solution - because whether something finishes in 0.2 or 0.3 seconds is immaterial and likely not to get measured properly by my current methods anyhow. If I could get an assembly that took 20 vs 30 seconds to rebuild that would be worth testing, but I don't have anything on that level :(

I am very much open to input on how and what we test, though, so if you have any ideas I am all ears (though I can't promise we'll actually implement everything folks suggest). Right now I am planning on the following:

- Assembly rotation performance testing for CPUs (latest gen Intel and AMD) and GPUs (Quadro RTX series)
- SW startup time
- File open / save testing
- Render time
- Motion Study
- Stress sim
- Flow sim (multiple tests)

Posted on 2020-01-15 21:35:58
Jon Gray

Would like to see faster memory tested with the Ryzen system. DRAM frequency and infinitry fabric (FCLK) are 1:1 up until about 3600-3733 MT/s (1800-1866MHz FCLK) and performance scales well up until FCLK is decoupled.

Posted on 2019-10-07 14:04:39

I know a lot of individual builders go that way, but 3600 / 3733 is *way* beyond AMD's supported spec for these CPUs. Depending on how many sticks you are using, and whether they are single- or dual-rank, AMD's official memory speeds for Ryzen 3rd gen are in the 2666 - 3200 range. That is why I tested at the two ends of that spectrum in the article above, and it was mostly in simulations that there was a substantial performance difference.

Posted on 2019-10-07 16:13:26
Frodo Boggins

"I know a lot of individual builders go that way, but 3600 / 3733 is *way* beyond AMD's supported spec for these CPUs"

This is simply false. AMD recommends DDR4-3600 CL16 memory for best performance in their own presentation slides. These kits are readily available and require no overclocking.


Posted on 2019-10-27 20:51:41
Frodo Boggins

Its good to note that 3200Mhz is the specified memory recommendation, but many people tweak their systems anyway, regardless of AMD's caveats. The caveat is there because not all of AMD's Ryzen 3000 processors are able--due to variable silicon quality--to clock the Infinity Fabric higher than spec. That's literally the only reason. In the meantime, customers that are able to take advantage of a significant free performance boost would like to see those benchmarks posted.

Posted on 2019-10-27 21:14:37

Yeah, it has been a huge source of frustration to us that AMD showed off performance numbers with really fast RAM - but then officially only supports 2666 to 3200 depending on the number of memory modules and whether they are single- or dual-rank. If they really feel that stuff above 3200 isn't reliable, they shouldn't have used it in marketing... and if they feel that it *is* viable, then they should officially support it so that builders don't have to make a choice between proper support (warranty, RMA, etc) and getting good performance. But then this sort of 'can of worms' has been open for years on the overclocking side of things, and even on memory (Intel doesn't officially support high speed RAM either!) - but the use of it in their own presentations was salt on the wound.

Thankfully, there are a lot of reviewers out there who focus more on the build-it-yourself community, and who thus do testing with higher / out of spec memory speeds (as well as overclocking). For our articles, though, we have to focus on what we either offer in our systems or are considering offering in our systems - it wouldn't be nice to our customers (in the same vein as what AMD did with their slides) if we showed off performance that we then didn't offer or even consider offering to our readers.

Posted on 2019-10-28 16:17:16
WeRIdo Lee

I have a question, why don't both system use same cpu cooler?

Posted on 2019-10-14 04:11:52

Because at the time we were doing this early testing on 3rd gen Ryzen processors we had not yet qualified another cooler for use with them, so we were using the coolers that AMD provided with the processors. Now what we have added Ryzen chips to our lineup, we do have a Noctua cooler that we use with them - so you can expect to see that reflected in future articles with these processors :)

Also, we did some checking to make sure that the Wraith cooler wasn't causing thermal problems and found that Ryzen processors using it were running no more than 100MHz (0.1GHz) slower than they did with a better (Noctua) cooler - which is a small enough difference that it shouldn't have a major impact on the results or our conclusions in these articles.

Posted on 2019-10-14 16:35:13
Phillip LaPlante

Hello William,

We have built similar computers to the ones found here, except we found very different results for the Flow Simulation solve time. Across all of our testing the 9900k was exceptionally faster than the 3900x. We have a report on it here: https://drive.google.com/fi... Why would this be the case? Is something in your flow simulation easier for the AMD to run over the Intel?

Posted on 2019-10-21 16:34:40

I am honestly not sure what aspects of a given simulation favor Intel or AMD processors, but we do test several simulations in our benchmark and some of our results were closer to what you saw: Intel's 9900K leading AMD's 3900X by about 10%. Look at the charts for our Stress and Thermal simulations to see what I mean. On other tests, though, the higher core count 3900X performed much better - allowing it to take the lead over the 9900K by a similar margin.

If I had to guess, I suspect that something about different simulations may be better or worse at using multiple CPU cores. In situations where more cores can be utilized effectively - where core scaling is better, in other words - AMD's chip pulls ahead simply because it has more cores available to it. In simulations where core scaling is not as good, however, Intel's better per-core performance gives it the lead. I didn't delve into testing scaling with different numbers of CPU cores in this article, which I saw that you went into much greater depth about, so I can't say that is the answer for sure... but it seems to fit the data and makes logical sense.

Do you have additional simulations you could test on your end, to see if those you used in this paper happen to all favor Intel? If not, I could ask the gentleman who provided the files which I call our "benchmark simulation" to see if he would be okay with me sharing those with you, so you could try them and see if you get results along the lines of what I did (which favored AMD).

Posted on 2019-10-21 17:26:50

Hi Phillip, Please contact me: flowjoe at solidworks dot com
I can provide more details of my assessment of your report that I had received previously from a colleague of mine at SOLIDWORKS. I have experience with scientific computing hardware systems specifically for Flow Simulation. I can also provide you the benchmark model that I had provided to William in early 2019. Thanks. -joe

Posted on 2019-10-21 20:11:48
Bill McEachern

Hi Joe,
Could you find out if Flow Sim has support for the AVX 512 extensions or even the 256 extensions. That would explain a lot about why Flow sim on Intel would be faster.

Posted on 2019-10-22 14:18:56
Phillip LaPlante

Hello Joe,
I tried contacting you, but I have yet to see a reply. Did you get my email?
Thank you.

Posted on 2019-10-28 16:43:22

Here are some general recommendations from the development team:

- Flow Simulation multithreading scalability is optimal on up to 20 cores
- If there are different CPU options with the same number of cores, the higher clock speed is preferable
- Intel processors are preferred simply because most SWFS testing is done on Intel
- All memory banks should be filled – this reduces upgradability, but improves performance
- The memory speed should match that of CPU

The solver is compiled to include the support of AVX, however, the developers are not sure how big the performance benefit from it actually is.
In particular, the developers recommend the processors of the Intel Xeon Gold series provide good performance, if the system is properly configured (according to the recommendations above).

From myself:

Here is a common email response that I send to customers asking about hardware to help them with selecting a system:

Hardware Recommendations and Comments:

I can give you information regarding hardware so that you know what’s important when considering to buy. One thing to note is that it’s not just a single component of your computer system that’s crucial, but you should think of it more holistically in that it’s the whole system working together, including the cooling or thermal management inside the box. Desktops are always going to be faster than laptops.

Clock speed wins over number of cores

Doubling the number of cores will not cut your solution in half. For SOLIDWORKS Flow Simulation, be sure to prioritize CPU clock speed over number of CPU cores when selecting a processor. For most users, the best choice is some balance of the two. Remember that with any software, some operations are inherently linear (sequential) and cannot be reliably and effectively multi-threaded. This limits them to a single CPU core. In such cases, you might see better performance on a single CPU quad core (8 threads) system with a 4.5 GHz clock speed than you would on a system with 12 total cores (24 threads) and a 3.0 GHz clock speed. Be careful not to focus on Turbo or Boost speeds from CPU manufacturers as they cannot sustain those speeds for long periods of time without throttling back to keep it from overheating, and consider that most Flow Simulations will take many minutes to several hours to run.

Many portions of the SOLIDWORKS Flow Simulation solver are indeed multi-threaded, so you may see significant performance improvement during certain phases of meshing or solving if you have additional cores. Do not expect to see 100% CPU usage all the time, though. Based on my experience, I recommend using Hyperthreading. Note that the larger the problem (more computation cells), the better usage of those cores is going to be utilized.

Intel XEON processor architecture tends to offer better stability and be more consistent for scientific computation, such as requiring error-correcting code (ECC) RAM, so I tend to recommend this over their i7 and i9 lines. It’s preferable to use Intel CPU’s since that’s what the developers use for testing.

Invest in a fast NVMe drive as primary

Ensure you have an NVMe drive with a fast read and write speed as your primary OS drive. Furthermore, when working with any Simulation study, make sure both the model and results folder in study properties is set to a location on an NVMe. Purchasing a fast (generally 3500 MB/s sequential read and write speed or better) and good quality an NVMe is the single most important (and often least expensive) investment you can make for an across-the-board performance improvement for pretty much everything (not only SOLIDWORKS)! For SOLIDWORKS Simulation in particular, there is a huge amount of data throughput when you activate studies, mesh, solve (in the form of temporary files, some of which are written and read to disk during solving), load result plots, and save study data changes. Even a modest 20% improvement in disk read and write speed will be noticeable. NVMe’s are 5x the bandwidth of SSD’s, and real world scenario transfer speeds of over 3GB/s vs 555 MB/s for SSD. This is going to be one of your most perceivable performance enhancement.


A system with 16-32 GB of RAM is adequate for most users since it is generally preferable to have slightly more RAM available than a typical Simulation user may actually need. Although as little as 8 GB is actually sufficient for many typical studies, certain Flow Simulation functions such as meshing, solving, and viewing results can require larger amounts of RAM if the study has a large number of cells. My recommendation is that RAM is relatively cheap, so don’t skimp on this. Fill up all of the memory slots; this will improve performance but reduce upgradability. So plan on getting enough RAM for current and future models that you might have to solve. I would say to get 32GB as a minimum for Flow Sim, but 64GB or more is recommended.

For scientific calculations, use ECC (error-correcting code) RAM which is usually required for motherboards that support sockets for Intel XEON processors.

Since there is a heavy amount of communication between the RAM and CPU during the calculation, especially for studies that take more time, you will see realizable performance improvements with a motherboard that has a fast BUS and you should get the fastest clock-speed RAM that the mobo supports. Match the RAM speed to the mobo BUS speed.

Graphics Card

SOLIDWORKS certified graphics card is required for some special visualizations in Flow Sim, such as Dynamic Trajectories and Streamlines on cutplots. Make sure you use a certified SOLIDWORKS graphics driver (link) and not necessarily the latest one from the card manufacturer, as it has not been tested and certified by SOLIDWORKS to work with all of the features.

Don’t go hog-wild on a super graphics card with a lot of graphics RAM unless you need it for renderings or other purposes. Why? Graphics RAM has to be addressed in physical RAM so it essentially removes that amount of RAM available to the system.

Posted on 2019-11-07 03:22:04

I believe that I've come to a conclusion, after putting much thought into this, that the Ryzen 9 3900X edges out the Intel i9-9900K in the Flow Simulation benchmarks simply because it has more cores (and threads).

You can see in the below images on Scalability, for the larger number of mesh cells, 2 and 7 million, the speed-up ratio continues going up from 10 to 12 cores.

Posted on 2019-11-07 15:34:50
Phillip LaPlante

Hello Flow Joe,
I believe I figured out why our 9900k was faster in our benchmarking. First off, the relative performance of the Intel at lower meshes is better than at higher meshes (I did not test this, but it was tested here by Puget). This is why at a lower mesh the 3900x and 9900k are basically the same, however once the mesh goes up the 3900x edges out a win. Now why did our 9900k not follow this trend? Well the z390 Gigabyte Aorus Ultra automatically had multicore enhancement turned on, thus instead of running at 3.6GHz it was running at 4.7GHz. A future test should hard lock both processors at the same clock speed, because Zen 2 does have higher IPC than Coffee Lake.

Now I have a few questions on the charts you have here:
First off are those “cores” talking about threads or physical cores (because the Solidworks drop down menu does not know the difference, so I need to ask).
Second, what is the version number listed in the second set of charts? Is that a Solidworks version (Version 17.1 meaning 2017 service pack 1?), because wow that is some good uplift from updates.
Third, what processors where used in those tests? I presume it is like you said a Xeon Gold of some sort, but if it is a Xeon Gold, then how do you know it stops scaling at 20 if a Xeon Gold has a maximum of 22 cores? I just want to push the envelope of what is possible now that AMD Epycs are simply way too many cores (I completely think those chips are awful at Flow Sim due to their low clocks).

BUT there is another thing at play here that often goes under the radar. When you go into that high core count area you can start to use multiple parallel simulations. Personally, I only use Parametric studies which by nature do a lot of small simulations, and I can run many in parallel. With only 12 cores on the 3900x I was able to get 8x Scalability when running 4 simulations at once, which could only receive 4 threads each (only 3x scalability). I could go up to 6 parallel simulations, but at that point the scalability only increased to 9x. Meaning that if I were to go with your 20 cores maximum scaling, then run 6 simulations at once, I could load a 128-core processor (which oh wait doesn’t exist, we only have 64, so substitute the 6 parallel for 4 parallel). Therefore, I might be limited to 16 cores a simulation which might get 6x per solver (which is 2 times better than the scalability for per simulation than the 3900x), and it might be as much as 20 times the performance of one core. Now that Epyc Processor (7702P) has 2GHz, so if we compare that back to the 3900x which goes at 3.8GHz, it might be as little as half that, so the scalability as compared to the 3900x might be 10x. So, going from 8x to 10x for a price jump of 8 times more is probably not worth it, but considering a second system might costs another whole license, it does have some merits.

On another note and ignoring all of the odd incompatibilities that might happen with bleeding edge tech, the new Threadripper 3970x/wx is said to have 3.7GHz base clock, yet it has 32 cores, which is unbelievable. That might get 4 sims at once with a 8 cores each, giving it a 5x for each sim (which is 1.66x better than the 2x of the 3900x), and therefore 13x a single core performance, which since it clocks at 3.7 vs the 3900x’s 3.8 we only need to penalize that score by a tiny bit to get to 12.5x, which is huge. Again, I want to stress that the single simulation might only scale to 20 cores, but parallel simulations scale farther than that to about 6 (but with an HEDT or Server platform where the IO is might larger, it might scale much farther than that). With that in mind Solidworks can easily scale way past 128 cores which you could already get with a dual socket EPYC.

I will note that all of the math here was done on a napkin, so take it with a grain of salt. Like Bill McEachern said, Intel does support AVX 256 and 512, so AMD might be penalized heavily for that, but all this math was done by comparison to other AMD parts that I tested, or Puget tested.

I know Solidworks does not want to promote AMD, but you have to admit that what they have done in the last two years is leaps and bounds more improvement than Intel. As Puget has benchmarked a Threadripper 1920x solved an airflow simulation in 125.5s yet the same core count desktop (not HEDT) 3900x which is only clocked 300MHz faster solved it in 73 seconds. That is nearly a 42% decrease in solve time for 300$ less on the release price. In that same time period Intel has gone from a 7980XE (92s solve time) to a 9990XE (65s solve time), which is only a 29% decrease in solve time for an increase in price, and nearly no availability. Rumors put the cascade lake 10980XE at only just a bit faster than their Skylake counterpart. But we were only taking about a desktop part for AMD, What about HEDT and server? Those beat Intel across the board.

Thank you, Phillip LaPlante

Posted on 2019-11-07 17:38:13
Phillip LaPlante


Will there be a new article on 3rd gen Threadripper or 3950x for Solidworks performance maybe against Intel's HEDT stack? As mentioned by Flow Joe, flow simulaton stopped scaling at 20 cores. However we have seen great improvements with multiple simultaneous solvers. As such we are looking into getting either a huge Threadripper single computer or a series of smaller processors. Our greatest concern with Threadripper is how fast its single test performance is. We would like to be able to solve a single test in as short of time as possible, which with the information I can gleam from Puget articles is the 9980xe (or probably now the 10980xe), However a 3rd gen Threadripper (or even the 2nd gen 32 core) might be able to brute force its way past. Going along with the multiple solvers, Threadripper should easily outperform just with its higher core count but we would want the best of single solver and multiple. Also we are concerned that at 32 cores and many (+8) solvers at once the memory would bottleneck the system immensely (since Threadrippers only have quad channel), and that's not even talking about the not yet release 3990x, which if it stays with quad channel memory, it would be a in a worse spot. Does Flow Sim have enough memory throughput where that could be an issue? It would be a shame to get a Threadripper and be simply outperformed by a handful of 3900x's, or even two 10980xe's.

On a sidenote we figured out why our 9900K out performed the 3900x: our motherboard had multicore enhancement turned on by default which is shameful on the motherboard manufacturer: Gigabyte. As such we actually had stability issues that were solved when that setting was turned off. However, at that point the 9900k got smashed by the 3900x.

Thank you,
Phillip LaPlante

Posted on 2019-12-17 21:30:16

Ah, yeah, motherboard makers sometimes default to things being on that shouldn't be :/ Glad you figured that out, though!

And yes: I am going to be updating our SW benchmark to support the 2020 version soon, with the intent to do a round of testing and articles on CPUs (both AMD and Intel) and GPUs (Quadros) when SP1 comes out. We might not end up waiting for SP1, depending on when it is released, because we are also aiming to do a webinar about the best hardware for Solidworks in early February. The articles would likely come out shortly before or after that webinar, again depending on the timing of SP1's release and how long the updating and testing itself actually takes.

Posted on 2019-12-17 22:03:27

In regards to the scaling up to 20 threads, I've since learned (through my own research and testing) that this is likely only what the developers have tested up to because of what machine(s) they had access to at the time that information was produced. since then some things have changed... most notably, as you know, recently both Intel & AMD have increased the number of cores (and threads) in a sort of CPU race. There are CPU's now on the consumer market with 64 cores and 128 threads, eg. AMD EPYC Rome 7742.
I currently have direct evidence of scaling up to 56 threads for the same benchmark problem that I had provided to Puget Systems. But note that the scaling became more evident when I upped the mesh from a max of roughly 2 million cells to one with over 6 million cells.
For the 2 million cell problem, a machine with 56 threads (base clock 2.0 GHz; max turbo 3.0 GHz) took just about the same time as a 20 thread machine (base clock 2.4 GHz; max turbo 3.0 GHz).
But for the 6.27 million cell mesh, the 56 thread machine took 35:08 (2108s) which was much faster than the 20 thread machine at 55:34 (3334s).
What I'm trying to demonstrate is that for lower mesh cell counts, such as the mesh at 2 million cells, the scalability is going to level out at some point where there is no discernible advantage of having more computing threads; whereas the larger the problem, more threads are going to be more effective and scale up further to grow with the problem.
I will keep you updated when I get some results of a VERY LARGE, ridiculous problem run on a 128 thread machine with 2TB of RAM that I'm working on with some outside assistance.

Posted on 2019-12-18 20:28:15
Michael Grimm

I really appreciate your hardware evaluations for Solidworks. How do you think the processors would compare using Solidworks Plastics? And, do you find that, during tests that utilize multiple threads, that all threads are used equally?

Posted on 2020-01-31 15:24:30

I have never used or tested Solidworks Plastics, so I can't say for certain... but I would hope that it behaves similarly to SW Flow, since at least part of the work being done is simulating the flow of plastics in a mold. Maybe that is an overly simplistic view, though :/

Perhaps someone else who reads these comments can chime in with more direct experience?

Posted on 2020-01-31 19:25:35
Damon Tordini

Hey Michael- SOLIDWORKS Plastics is definitely multi-threaded during the solving process, although the meshing process (whether shell or solid) is not, according to article S-074174 in the SOLIDWORKS knowledge base.

I don't have any formal benchmarking data, but from experience with different computers over the years I'd say you get diminishing returns beyond 4 cores, similar to SOLIDWORKS Flow Simulation. Keep in mind that for FILL analysis, SOLIDWORKS Plastics has three different solvers to choose from (CICSAM, Direct, and Indirect). The Direct solver, while the most accurate, must solve each element sequentially which means it probably gets less of a boost from multi-threading. CICSAM is the default and typically the best combination of speed and accuracy.

Posted on 2020-02-06 22:04:52

>> I'd say you get diminishing returns beyond 4 cores, similar to SOLIDWORKS Flow Simulation <<
I can say that for SW Flow Simulation that the problem is just simply not large enough to take advantage of more cores, so it may only appear that there are diminishing returns with more cores. The larger the problem size, specifically in regards to cell count, more of the multiple cores will be utilized resulting in a shorter overall run time. This is what I was saying when I compared a 2 million cell problem with the same problem at 6.27 million cells for machines with 20 and 56 threads. For 2mill cells, they performed about the same, but for the larger 6.27 mill problem, the 56 thread machine was much faster by over 20 minutes or 37% less time.

Posted on 2020-07-01 20:59:10

I can confirm from our own testing that opening large assemblies can take over 10% longer on a Ryzen 9 3900X compared to an i9 9900K. Rebuilds as well.
Opening of an assembly in 4 minutes (Ryzen) against 3,5 minutes (i9).
I'd say that for large assembly work the i9 is a far better option.It's more than a slight difference.

Posted on 2020-02-28 14:38:29

I'll be publishing some new benchmark data soon (today or early next week) from SW 2020, but interestingly I did find that Intel was faster than AMD for opening files - as you described above - but for rebuilds I had the opposite result. However, the assemblies used to test each of those behaviors were different files... so maybe it also has some relation to the file itself? Anyhow, thank you for contributing your experience :)

Posted on 2020-02-28 19:17:51