Multithreaded Programming Performance Limitations
Communicating with the Interface
In parallel programming, any single-threaded bottleneck will reduce performance. The Maple kernel has been optimized to remove as many of these bottlenecks as possible. However, there are still a few issues that can cause reduced performance. We hope to be able to fix these in future releases.
The Maple garbage collector requires stopping all running threads and falling back to a single thread to perform the collection. For code that consumes a lot of memory, this can be a significant limit to parallel performance.
The mutable data structures (rtable, table, global names, etc) are locked when accessed in parallel.
When Maple calls an externally defined routine, it assumes that routine is not thread-safe. Thus Maple will block other threads from calling external routines while one thread is in external code. This will limit performance if code is trying to call external routines in parallel. If you are defining your own external routines, you can specify the THREAD_SAFE argument to define_external to tell Maple that the external routine is thread-safe. In this case, Maple will not block other threads from entering external code if a thread calls a thread-safe external routine.
When a Maple thread communicates with the interface, it gets an exclusive lock to the communication channel. This can block other threads from communicating with the interface. These blocked threads must wait for the first thread to finish its communication before they can resume.
This communication happens for a variety of reasons.
Printing (print, printf, etc)
Calling system or ssystem
Accessing interface values
Task Programming Model
Download Help Document
What kind of issue would you like to report? (Optional)