to stanc3? that’d be pretty easy; inside we can just emit “#define STAN_THREADS true” or whatever.
1 Like
Yeah, that is a separate thread for sure :) Do you mean like make model_name --threads --opencl ?
That could work.
Or through stanc3 yeah, may even prefer that.
I kind of feel like the real future for Cmdstan is through the cmdstanpy, cmdstanR, cmdstanX interfaces. I started working on adding the threading/OpenCL compiler flag support for cmdstanr and I feel like I will just switch over to using that.
Now if we just add binary format then… :champagne: haha :)
1 Like
I think for OpenCL we could probably move the Math library away from a global OPENCL switch and just compile in support always, because we can move the flag and logic for switching to the OpenCL versions of functions in the compiler. To make the compiled model program be able to switch performantly at runtime, the compiler would need to generate two versions of the code and be able to switch between the two. This is even more complicated for something like threads, where the autodiff internals change between threading and non-threading versions.
1 Like
@seantalts @serban-nicusor I wasnt at the meeting yesterday but I think the agreement was that Math version should be 3.0 and the interfaces stay 2.21? The release says 2.21 for Math. I could be missing details from the meeting so feel free to ignore this message :)
1 Like
That won’t work, because we have pre compiled headers which only work for threads or not…you cannot switch on the fly.
1 Like
I misunderstood sorry, it’s 3.0.0 now.
1 Like
No problem :)
This was my bad - forgot to mention it in time. Sorry Nic :)