Re: RFC: Multiple backends + speedy looping
Hi Tony On Wed, Mar 14, 2012 at 5:28 PM, Tony Yu <tsyu80@gmail.com> wrote:
From the looks of the implementation, it seems none of the current modules would need to be changed unless a backend was added. And even then, it looks simple to modify an existing function to add a backend. Does this sum it up:
* Add `@add_backends` to function with new (optional) backend * register backend function using `backend.register` in the `__init__` file for the function * Subclass tests from `BackendTester` (an additional decorator for test functions might be good, if possible)
That's right--the design is aimed to be minimally invasive.
Stefan: Do you have an idea of what needs to be done to get this merged? After a quick look: 1) It needs to be moved from the scikits.image namespace to skimage, 2) there are questionable changes to "filter/edges.py" and "filter/tests/test_edges.py" in the PR, 3) implementation should be moved from "backend/__init__.py" to something like "backend/core.py" (or I guess we've been using the convention "backend/_backend.py").
Also, I'm not crazy about dumping backend functions into a "backend" subdirectory for each module. Maybe they should go in a backend-specific subdirectory. So, for example, "filter/backend/edges_opencl.py" would move to "filter/opencl/edges.py".
You've identified the three core issues. (1) is easy to do. (2) -- I believe we should rework or remove those examples. (3) I share your sentiment--skimage.filter.opencl seems like a better place. Thanks for the valuable comments! The more I think about this, the more I think that this can be a great way of experimentally incorporating new and maturing technologies, such as numba. Even if we can just start by having the fastest convolution of all the available packages--without giving up the advantages of high-level description--I'd be very happy. Stéfan
participants (1)
-
Stéfan van der Walt