On Mon, Feb 6, 2012 at 2:21 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 6 February 2012 07:22, Stefan Behnel <stefan...@behnel.de> wrote: >> mark florisson, 06.02.2012 00:12: >>> On 5 February 2012 22:39, Dimitri Tcaciuc wrote: >>>> 3. Does it make sense to make OpenCL more explicit? Heuristics and >>>> automatic switching between, say, CPU and GPU is great for eg. Sage >>>> users, but maybe not so much if you know exactly what you're doing >>>> with your machine resources. E.g just having a library with thin >>>> cython-adapted wrappers would be awesome. I imagine this can be >>>> augmented by arrays having a knowledge of device-side/client-side >>>> (which would go towards addressing the issue 1. above) >>> >>> Hm, there are several advantages to supporting this in the language. >> >> ... and there's always the obvious disadvantage of making the language too >> complex and magic to learn and understand. Worth balancing. > > Definitely. This would however introduce very minor changes to the > language (no new syntax at least, just a few memoryview methods), but > more major changes to the compiler. The support would mostly be > transparent. > Clyther (http://srossross.github.com/Clyther/) is a related project, > which does a similar thing by compiling python (bytecode) to opencl. > What I want for Cython is something even more transparent, the user > wouldn't perhaps even know opencl was involved, and the compiler has > more control over how data is handled.
What I'm absolutely certain of is that sort of complete transparency will eventually start getting edge cases and from there on additional development and design will have to be made, so I it's better to plan not-as-transparent elements and user-side control right form the start. I think another reason I would go for a less automatic solution is because I imagine the alternative would inevitably complicate Cython internals. I think keeping that as simple as possible is huge advantage in the long run, which is arguably as important as reducing amount of code a language user has to write (hence me initially suggesting a more library-like Cython integration, although pyopencl did work quite well already :). Dimitri. > >> Stefan >> _______________________________________________ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
