RFC: Multiple backends + speedy looping

[Tony Yu]

2012/3/1 Stéfan van der Walt <stefan at sun.ac.za>

> Hi Nadav
>
> On Wed, Feb 29, 2012 at 9:36 PM, Nadav Horesh <nadavh.horesh at gmail.com>
> wrote:
> > I am working on a simple frame work as a replacement for
> > ndimage.genereic_filter and numeric's neighbourhood iterator (I hope it
> > would be faster and easier to use).
>
> The goal of this PR is to support any backend (including, possibly,
> the one you are writing).  I'd like to provide multiple
> implementations of some commonly used functions (convolution, e.g.),
> so that we can have a performance based series of fallbacks, such as
> GPU -> Cython -> Python.  That way, algorithms can be run on any
> system, but will execute most rapidly on those supporting, say,
> OpenCL.  Another advantage is that if, in the future, we write an even
> faster implementation, the benefit is immediately available to the
> user, without rewriting any code.
>
> Stéfan
>

>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)

The rest of the changes would happen in separate files for each function
implementation. If this is an accurate description, then I think the
backend system would be a good addition and wouldn't really add any
annoying boilerplate code.

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".

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120314/4ee307f6/attachment.html>