VERICUT Users' Forum

Due to relentless spammers, we are no longer automatically accepting new forum registrations. If you wish to register for this forum, please send an e-mail to: info@cgtech.com

You are not logged in.

#1 2004-10-20 23:27:13

BillH
VERICUT Specialist
From: Irvine, CA
Registered: 2004-10-08
Posts: 146
Website

Multiple Processors and VERICUT

What VERICUT Does with Multiple Processors
VERICUT is a Java application, which automatically gives it access to use multiple process threads. What does "multi-thread" mean? Simply put, it allows VERICUT to do certain tasks as separate processes, parallel to VERICUT's main process. These separate processes (threads) start and end on their own, somewhat independent of VERICUT's main process. If more than one CPU is available, the operating system can choose to run the thread on the least-busy CPU. This is designed into VERICUT. Only certain actions make sense to run in a separate process thread. The following are a few of the threaded items in VERICUT:
    Main VERICUT display
    Toolpath Review
    Status
    Info Toolpath
    Edit Toolpath
    Material removal (1 or more threads)

So, for example, running VERICUT with Info Toolpath and Status open is somewhat faster on a dual processor than on a single processor. Testing showed that running VERICUT with these windows open has something like a 10% speed reduction on a single processor, but only a 1% reduction when using a dual processor (I don't remember the exact numbers). Info Toolpath and Status have less of a speed impact on the dual processor computer because the operating system places their process threads on the least-busy CPU (the one not running the main VERICUT process).

There is also some minimal gain in the material removal time (a few % overall) when running a dual vs. single processor. It is important to note that "overall" performance is all that matters. It means little if we improve material removal speed by 20%, but the overall impact on the process is only a few %.

There is additional overhead when using multiple threads (see below). Thus VERICUT detects the number of processors when initially starting, and decides whether or not to use multiple process threads. If only one CPU, then multiple threads are not used.

Symmetric Multi-Processing
SMP (Symmetric Multi-Processing) has become the dominant commercial multi-processor design over the past few years. When us lowly commercial software developers (as opposed to ivory tower university researchers) talk about multi-processing, we mean SMP. SMP uses shared memory and is much more flexible than previous designs. Multi-threading is the programming feature that accesses SMP hardware. Most modern compilers support multi-threading and SMP.

There is also (an earlier design) Asymmetric Multi-Processing, but that requires specialty hardware, operating systems, and compilers, and is not applicable to us. This design was typical of the massively parallel processor computers of the late 80's and early 90's.

Limitation of Multi-Threading and SMPSo, why don't multi-threading and SMP have a bigger positive affect on speed? Why aren't two CPU's twice as fast? Two reasons: synchronization and context switching.

Synchronization
When VERICUT starts a new thread for a specific task, the actions of that thread must eventually synchronize with other process threads. For example, the Info Toolpath display has to sync with the main VERICUT process so it matches the cuts being displayed. Sync'ing takes time and resources, but is usually offset by the gain from using the other CPU.

Context Switching
This is a major weakness in the multi-threading SMP scheme. In an SMP system memory is shared. Part of this shared memory includes the heap, which contains pointers to memory used by the process. In most operating systems there is only one heap, but each process thread in an SMP system has its own heap with different contents. The contents (or context) of the one heap must be "switched" when a new process thread becomes active. In cases where the speed gained by using more than one CPU is small, and the context switching is frequent, the overall processing speed gain is negated by the overhead of context switching, and may even result in slower overall speed.

3rd party memory management products are available that replace the operating system's standard memory management with their own, and some specifically try to improve context switching. They are expensive, difficult to implement, and make us dependent on their software libraries. We have so far chosen not to use them.

Benefit of Multiple Processors
There is some small benefit from dual processors with VERICUT (conservatively a 5 - 20% overall gain, depending on what you're doing).

But in my opinion, the real benefit from multiple processors is not so much for multi-threaded applications, but with how most of us work on our computer desktops day-to-day. I usually have at least 2 applications open, frequently 2 big applications both contending for CPU resources. Dual processors perform much better than a single processor in this situation.

Windows and More Than 2 Processors
The standard Windows operating system, as delivered by Microsoft, supports 2 processors. A computer that uses both Windows and more than 2 processors must also contain Windows operating system extensions specifically developed by the hardware manufacturer to support the additional processors. If I were choosing a computer, I'd stay away from this unless I had a real good reason to do it.

Offline

#2 2022-11-28 13:27:49

MWeers
Member
From: Almelo, The Netherlands
Registered: 2022-03-23
Posts: 14

Re: Multiple Processors and VERICUT

This thread is created 18 years ago. Can we have an update from Cgtech about this subject. Where are we now with Vericut?
I have a windows 10 workstation with 28 CPU's, 128Gb RAM and 1Tb SSD.

In the batch file I set:
...
set CGTECH_JRE_OPTIONS=-Djogamp.gluegen.UseTempJarCache=false -Dprism.allowhidpi=false -XX:+UseG1GC -XX:+UseStringDeduplication -Dsun.java2d.noddraw=true -Xms60g -Xmx80g -Xss20m
...

And I followed the advice as given at VUE_2022 day 3, hardware settings. But no differences are noted in the simulation time.

Can you tell me what to tweak in the launch batch file to run Vericut as fast as possible? Or are there other ways to use the hardware better?

Best regards,

Last edited by MWeers (2022-11-28 13:39:24)


Maarten Weers

VDL ETG Almelo
The Netherlands

Offline

Board footer