I added this to cmdstan awhile ago. I do realize my mistake for not at least tagging you if you are cool with the change. Sorry for that.
I added the same thing for OpenCL to display which device is being used. There were some support questions related to users wanting to be sure that either threads or OpenCL (and which device) are being used. So that was the reasoning behind this change.
I do agree that maybe mentioning the flag itself was not my best idea. “Number of threads used …” would be better. I was specifically mentioning the flag because this message will not appear if the flag is not set. Once we have threads on by default, this will be easier to handle of course.
I dont really agree with this one, For now, threading is used for map_rect. Once we extend the functionality of threading we can change the message to not specifically mention map_rect. That is a simple change.
If the users will see messages like “using 4 threads” they will expect speedups that will not be there if no map_rect is used. I know that will all change, hopefully sooner rather than later.
I see your motivation here, but I still think that we should not easily change the printout from our programs so easily - and we know that we will have more utilities that will use threading. So in hindsight of what we know is coming, I think the message should avoid mentioning map_rect specifically. The better behaviour would be to give a warning at the moment if threading us turned on, multiple threads are requested, but no map_rect is found in the program (but that’s hard to code up I suppose). Maybe the parser can detect if parallelism is used and then we can create a message based on that info?
A few more thoughts:
I actually think that this statement should be part of the stan services which do printout of the chain run parameters. I mean, the exact numerical results will depend on the choice of the number of threads.
In case the user turns on threading and MPI, then MPI will be used for parallelism (and only a nested map_rect would use threads). Turning on both is not recommended, but it should work.
At the moment we always report the “elapsed time”… which is not quite true when threading is used as the displayed time is the CPU time used, but not the wall time used. That needs to change in the stan services. We should report what we say and what users care about - and that is wall clock time.
If everyone is fine with changing the cmdstan printouts easily and do not make these subject to our usually very rigorous deprecation policies, then we can sort this out with some time.