Multiple Core Use in EnSight Programs

The following discussion highlights multiple core use in various CEI programs, i.e. CEIShell, CollabHub, SOS, and EnSight (Client and Server).

CEIShell does not really use multiple threads in any substantial way so you will not see it actively using multiple threads.  CEIShell itself is just responsible for launching the EnSIght components: the Client (master or DR rendering Clients), the SOS, the CollabHub, and the Servers. 

The EnSight Client only uses multiple threads for very few operations such as depth sorting. These days you may not even notice its use of threads since most of the computationally intensive work is handled directly by the graphics card.

Similarly, the SOS and CollabHub both act primarily as routers and compositing engines. Threading is not heavily used in either of these other than to manage different communication channels; however, typically only one channel at a time is being processed.

Lastly, the EnSight Server does use multiple threads for several areas: pre-caching of data to be read from disk, many predefined calculator functions (as of EnSight 10.1), some core algorithms (sorts, clip & isosurface setup, extrema calculation, etc.), and a reduction engine if using SOS. By default if you are running EnSight Gold or DR, the Server will determine the number of cores available and set the number of threads equal to the cores. You can also force the number of threads via the ENSIGHT10_MAX_THREADS environment variable. Again, you need to be running EnSight Gold or DR to set it above 8.

Monitoring thread use. Typically, "top" or "ps" require special command line options to see threads. See the "man" pages for those commands for those options. Note that the sampling time for those commands may be too coarse to see the threads as they spin up and down and if the data size per Server is too small. For example, if a Server only has 10K elements, you may never see the threads since they spin up/down so quickly, or the algorithm may determine that the work load is too small to even bother with threading. You should notice threading once you get into the tens of millions nodes/elements per Server range.

Scaling.  EnSight has better scaling characteristics by adding more Servers than it does by adding more threads. EnSight 10.1's Server does better with some calculations and threading, but adding more Servers is still the better approach. However, you must still have enough work per Server to see gains. Again, with today's processors, you really want 20 Million zoo nodes and/or elements per Server or more - assuming you are using a machine with 4 GB of Ram. If your machine has actually 8 GB, then the limit becomes ~ 40 Millions of zoo nodes/elements. More is always better. If the data per Server is less, then the inefficiencies due to threading and/or using multiple Servers tend to dominate. Please note that if your model contains polyhedral instead of zoo elements, the limit will be drastically decreased, more in the 4 Million elements/node range for a 4 GB machine. 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request