| |
Symmetric Multi-Processing In Parasolid |
| <<< Calling Parasolid From Multiple Threads | Chapters | Session Support >>> |
Symmetric Multi-Processing (or SMP) allows algorithms beneath the Parasolid API to make use of multiple processors if they are present on a host machine. A number of functional areas within Parasolid have been adapted for SMP, making it possible to reduce the execution time of certain operations, thereby improving the performance of Parasolid when running on multi-processor systems.
Parasolid SMP is enabled on the most widely used Parasolid platforms. For a complete list, see Section 5.6, “Symmetric Multi-Processing (SMP)”, in the Parasolid Installation Notes. Parasolid makes use of Win32 threads on Microsoft Windows platforms, and POSIX threads on UNIX and Linux platforms.
For information on how to call multiple PK functions simultaneously from different application threads, and the restrictions that apply when doing so, see Chapter 113, “Calling Parasolid From Multiple Threads”.
This section explains how to switch SMP on in a Parasolid session, how to configure it best for your own use, and discusses issues related to your application source code that you need to consider when making use of Parasolid’s SMP.
For more information on many of the issues described in this section, See Section 5.6, “Symmetric Multi-Processing (SMP)”, of the Parasolid Installation Notes.
SMP operation within Parasolid is controlled via the following functions:
You use PK_SESSION_set_smp to enable SMP in Parasolid. By default, Parasolid SMP is configured to:
These are the recommended settings for Parasolid SMP and will be sufficient for most cases. Section 5.6.1, “Guidelines for setting the number of threads” in the Parasolid Installation Notes, contains further information on how you can choose the optimum number of threads for your platform and application.
|
Note: Currently, Parasolid can create a maximum of 8 threads for SMP work. |
Parasolid SMP can be enabled or disabled at any time during a session. Once SMP has been enabled in a Parasolid session, most functional areas that can benefit from SMP will do so automatically. However, some specific PK functions may also require certain options to be set within the function in addition to SMP being enabled at the session level: for example, PK_TOPOL_facet_2 requires you to set
options.choice.smp
to PK_facet_smp_body_c (see Section 109.3, “Tabular faceting and threads”). For specific details on a per function basis, see the
PK Interface Programming Reference Manual.
You can use PK_SESSION_ask_max_threads to determine the maximum number of SMP threads that Parasolid can use in a current session. Knowing the number of threads that Parasolid can use in a session allows you to determine how many threads are available for your application to use.
The number of threads returned depends on the maximum number of SMP threads that Parasolid can work with (currently 8) and the values returned in the
thread_format
,
n_threads
, and
n_processors
options of PK_SESSION_ask_smp. For more information on how this number is calculated, see the reference documentation for PK_SESSION_ask_max_threads.
|
Note: If SMP is disabled then the maximum number of threads is 1. |
Depending on the platform that your application runs on, you may need to specify the stack size of threads used by Parasolid SMP. Although the default stack size for the system is usually sufficient, this is not always the case.
The following functions allow you to set and enquire the stack size of Parasolid SMP threads:
|
Sets the size of the stack allocated to Parasolid SMP threads. |
|
|
Returns the size of the stack allocated to Parasolid SMP threads. |
For both functions, a zero value means that the platform default stack size is used.
Guidelines for setting appropriate stack sizes on different supported platforms can be found in Section 5.5, “Stack sizes”, of the Installation Notes.
When using SMP in Parasolid, expect to need more memory than you would for a single-processor machine. With SMP enabled, Parasolid generally requires more temporary workspace in main memory during SMP-accelerated operations. For example, with two threads, it can require twice as much workspace.
If this extra space causes Parasolid’s requirements to exceed the physical memory of the machine - thus causing the operating system to start swapping data between disk and main memory - the resulting performance is normally worse than if Parasolid was running with a single thread.
|
Note: This only applies to temporary workspace used during calls to Parasolid; the memory needed to hold a given model is essentially the same for single- or multi-threaded operation. |
Whether Parasolid SMP is enabled or not, the vast majority of PK functions do not guarantee the order of returned entities. Enabling SMP in a session is likely to result in the order of returned entities being different compared to the order if SMP is not enabled. The table below describes some examples:
|
If a boolean operation results in several distinct bodies being created, the order of the bodies returned may vary when SMP is enabled. This also applies to the tag persistence rules with respect to the value of the target body tag being applied to any one of the returned bodies. For example, if Parasolid SMP is enabled and a boolean subtract operation returns more than one resultant body, Parasolid does not guarantee: |
|
|
If PK_BODY_check returns several errors, the order of the errors in the return structure may vary if SMP is enabled in a Parasolid session. |
|
|
When generating wire-frame data via the Graphical Output (GO) with SMP enabled, Parasolid does not guarantee the order of information output via the GO. More specifically:
For example, when sketching a body:
|
Regardless of whether or not you use Parasolid SMP, you should ensure that your application code is sufficiently robust to deal with changes to the order of returned entities. You can use the debug functions PK_DEBUG_shuffle_start and PK_DEBUG_shuffle_stop to help test the robustness of your code in this area.
Whenever reporting faults to Parasolid Support, always specify whether or not Parasolid SMP is enabled.
In general, it is not possible to quote a figure for the general performance improvement achieved by using SMP, since this improvement depends on the nature of the operations you are performing.
SMP is implemented beneath the API level, typically in low-level internal algorithms. These algorithms typically only form part of the code path called by a given PK function and may be invoked to different degrees depending on the nature of the received arguments passed by the application to the PK function. The reduction in execution time is affected accordingly. For these reasons, you should not expect an automatic 50% speed up at the PK function level when enabling SMP on a two processor machine.
Similarly, due to the nature of SMP, the scaling of performance with an increased number of processors is not expected to be linear. For example, if you see a 20% performance improvement for a particular function call on a 2 processor machine, this does not automatically mean that you would see a 40% performance improvement on a 4 processor machine.
Finally, the entity level at which SMP has an effect varies from one functional area to another. For example:
The overhead of thread locking can mean that some functions on some platforms will actually run slightly slower with SMP enabled than with SMP disabled. We strive to minimise this in our implementation and work in collaboration with hardware vendors to do the same. If you do find functions that run excessively slowly, the Parasolid team is happy to investigate these on a case by case basis.
The following table shows the main functional areas and/or PK functions that can benefit from Parasolid SMP being enabled.
|
PK_BODY_check and where checking is called internally as part of a PK function call. |
||
|
Implemented at the body level during initial processing and at an intersection level during line/line intersection. |
||
|
Implemented at the body level. You must set the |
||
|
Must fit at least one position to a tolerance, or set |
||
If at any time the operating system cannot create worker threads for Parasolid SMP, this is reported using a PK_REPORT_1_osthread_fail_c record in the Parasolid report.
If the operating system subsequently resumes creating worker threads, this is reported using a PK_REPORT_1_osthread_ok_c record.
If worker threads cannot be created, Parasolid performs the work they would have done in the thread used to call Parasolid. This is slower than using worker threads, but permits the operation to complete successfully.
See Chapter 11, “Using Reports”, for information about using the Parasolid report mechanism.
| <<< Calling Parasolid From Multiple Threads | Chapters | Session Support >>> |