Hi Marko

I have replied to you directly by email last week since our forum was being transferred to the new platform but I thought it could be useful to keep the discussion here for other users.

We have noticed that there is a sort of a linear relationship between the number of cores and the number of analysis rays used when optimizing. Too many cores gives a penalty when the number of analysis rays is not high enough.

Below is a result from a user using a AMD Ryzen Threadripper 3970X 32 Core Processor, 3693 Mhz (32 Core(s), 64 Logical Processor(s)).

As you can see, a high number of cores is helpful for a high number of analysis rays but leads to a penalty time for a low number of rays.

We ran similar tests internally here on an Intel-Xeon-Platinum-8180 28 cores (56 threads) and got similar results (I need to re-run the last line):

So far we have run tests and collected results. So we are aware of the problem but it is just started to be investigated.

For the ray tracing, we didn’t observe a penalty except for a low number of rays.

But one of my IT colleague wrote a little description about parallel computing and I think this provides an insight on the situation.

There is a famous theory in parallel computing called Amdahl’s law. By understanding this, it will help you understand how cores affect the speed. Here is the wiki for reference https://en.wikipedia.org/wiki/Amdahl%27s_law.

The following screenshot comes from the wiki page.

• x-axis represents the number of cores and y-axis represents the speedup.
• Each line with different colors represents the amount of parallel portion in the program

For example, ray-tracing can easily use parallel computer since each ray is independent. In this case, the amount of parallel portion can be high.

But when computing a merit function (and therefore optimizing), the software needs to wait the result from previous calculations. In this case, the amount of parallel portion can be low.

With that being said, if 95% of the calculation could be parallelized, we can see on the graph that above 256 cores, the speedup slows down. And this is an ideal case.

So back to OpticStudio, we can expect to have parallel portions between 50% and 75%. In that case (and according to our own testing), 8 or 12 cores seems like a good choice.

I hope that provides a bit of context, but as I said, we are still in the early stage of this investigation, so let us know if you have any other feedback. Have a nice day!

Sandrine

Thank you for posting it. I’ll update this post when I have information.

I am the user who’s results were quoted by Sandrine.
I investigated this problem quite deeply. What I learned…

1. Playing with processor control programs has absolutely no effect.
2. Large number of cores are in general detrimental to a fast solution - 8 seems to be nice compromise.
3. In order to find out how many cores to use in NS, a simple test is look at a simple ray trace and see how many cores this is the fastest at. A simple macro can test this. Then use that number of cores in the optimization routines.
4. The frustration is that if more rays are used more cores becomes more efficient, however the time per optimization cycle still goes up.
5. The best computer is therefore the one with the highest single core speed and a reasonable number of cores say 8-12.
6. More cores do help for global optimization.

I do understand that this is a deep problem for Zemax to solve because it is at the core of their algorithms, however it is an increasingly competitive environment and I am glad that other people find the same problem so it can raise its importance for Zemax.

If anyone is interested I can share my report I made on the topic as well as the macros I used to test the speed with a varying number of cores.

Ross

Hi Donna,

In sequential mode, the actual number of cores is probably the right value. Sequential files use much less memory, especially if they are all spherical. 

Local Optimization with the damped-least squares optimizer is a special case. If you have n variables, you need (n+1) evaluations of the merit function to populate the Jacobian matrix, and OS will not use more than (n+1) threads as a result. So, when using local optimization, you may see fewer threads than the actual number of cores available, and this is the optimum for that calculation.

Tolerancing is also a special case. In sensitivity mode, if you have n processors OS will evaluate n tolerance operands simultaneously. In Monte Carlo mode it will evaluate n MC files at once, each on a single core. This is also the optimum value, unless you have something unusual about your system.

There’s no single benchmark for when to use however-many cores, as the optimum strategy is system dependent. 

One of the developers did a research on these results to understand the reason of the time penalty when using too many cores.

The reason is given in @Mark.Nicholson’s answer. The ray trace code makes a copy of the system for every ray tracing thread. As the number of cores is increased, this leads to an increase in CPU time spent in memory access functions rather than in ray trace calculation functions. The severity of this effect varies between OpticStudio files and number of source analysis rays.

This effect is more pronounced the more complicated the system is, and the fewer analysis rays in the source. With few analysis rays, or complicated systems, the time spent tracing becomes less significant compared to the memory access associated with the multiple system copies.

Dear All,
I am coming back to this because the latest version of Zemax (22.0)  no longer has this problem.
I did not see this important improvement in the product announcement.
Well done the Zemax team!

Ross

Hi Ross

I checked with the developers and they confirmed not doing any changes (intentionally at least) that would optimize the number of threads/cores in NSC ray tracing.

It could be that your observation is a side-effect of some other change we made? Or have you done any change to the hardware or operating system that could have an effect?