When loading assemblies NX seems to be using only one core for most of the loading process. Now and then during the loading process the other cores are kicking in. But for most of the loading process only the first core is on 100% and the rest are on 0%. Is there a way to make NX use more cores when loading so that loading time is improved?
Using Win7Pro and NX11 / TC11.2
Solved! Go to Solution.
SMP is now enabled by default (check the environment variable UGII_SMP_ENABLE).
While some features of NX are multithreaded most aren't. Most of it is at the kernel level (Parasolid).
Some features in Parasolid that are multithreaded:
Check your NX10 Release notes for more info.
Here's a helpful article that explains the breakdown of the Physical Memory categories in the Windows Task Manager. It was written by a former senior developer on the Windows team (so there's a good chance he knows what he's talking about ).
So regarding the cores, there has not been made any changes in NX11 to increase this performance?
I just find it weird that newer versions of NX running on Windows 10 isn't able to use multicore more effectively when loading.
E.g. when I load a large assembly then 7 of 8 cores are parked most of the time while this one core is working 100% for several minutes, causing long loading time.
NX11 Documentation - System Requrements Guidelines
"Multi-core technology is complex and, depending on the configuration, can actually have a negative impact on performance. This is due to the potential conflict of multiple cores sharing system resources, such as cache, memory, and bus bandwidth, as well the need for the system to manage and control an increasing number of cores. Increasing the number of cores does not always translate into better performance. Although additional cores can improve NX performance, processor speed is still a vital measurement of NX performance."
Sorry, I was typing fast and didn't quite state that correctly. You do have plenty of RAM available, but it's mostly cached, which means its not currently in use but has been recently... it needs to be flushed to use for new purposes. Free can be allocated more readily. Of course this happens all in the blink of an eye, but when you take into account how many operations per second are happening it will help... I still think you would benefit to going to 32G.
That being said, your current bottleneck is likely processor bound.
@BenBroad I was under the impression that this blanket statement (that's been in the release notes for some time now) has always been addressing the impact of hyperthreading and similar virtual core technologies.
I think a more direct answer for why NX isn't more multi-threaded is that it's a non-trivial exercise from a software architecture standpoint - most people like to think it's just a magic switch you can flip and immediately generate scaled performance... but multi-threading a process usually requires some fundamental re-architecting at the kernel level - and even then much of the functionality may not benefit from such architecture because of its fundamental asymmetries. The short answer: it's complicated.