Closed AndrewHarris709 closed 1 year ago
Warning: here's a long winded answer to a small change.
This opens a bigger conversation for me about handling global variables with Sarracen. I think you're right that the sdf.backend is kind of clunky, that is, having a backend set per data frame. We were talking earlier today about dealing with time series and loading multiple data frames inside one analysis. That got me thinking that setting the backend once per session, rather than per data frame, would be more sensible.
I was poking around how pandas handles this. They have a _config directory, and then _config/init.py and _config/config.py, in which global variables are set and stored. This seems like it might be a good framework. Would be extensible to future global variables.
We could define a private dictionary inside config.py that would currently just have one key. 'backend'. Could set the value for this key on import using the numba check for Cuda, just like how you've done in the PR here. Maybe putting initialization in the .config/init.py is ok for now?
For the render calls, could still accept backend= 'gpu' or 'cpu'. I was wondering if we should introduce 'auto' as the default option, which for now would just reference the global variable. backend=None seems like a weird phrasing (does it mean no backend?).
Thoughts?
Change the behavior of computation backend selection, to automatically use
gpu
when CUDA is available. Resolves #45Now, backend selection behavior is as follows:
gpu
if CUDA is available, otherwise usecpu
sdf.backend
parameter is changed for the target SarracenDataFrame, use the specified backend there, overriding the default. (We can likely remove this step, this seems unnecessary now)backend=
argument is passed in the interpolation/rendering operation, use this backend, overriding both steps above.