
I was wondering if anyone could point me to a more in-depth explanation of why we are (currently) restricted to using a special-purpose standard Prelude when writing vectorised code with DPH. We're prototyping using several data-parallel languages for a research project here at Northwestern University, and wanted to get a better idea how we might go about adding vectorisation support for addtional types/operations. There are certain simple operations which don't appear to be supported for primitive types yet (e.g. the ^ and ** operators for an Int type). These are the kinds of things we'd like to look into as a first step. Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet? Much thanks, James Swaine

James Swaine:
I was wondering if anyone could point me to a more in-depth explanation of why we are (currently) restricted to using a special- purpose standard Prelude when writing vectorised code with DPH.
The reason is simply that the standard version of the Prelude uses Haskell features that are not yet supported by the vectoriser; in particular, type classes and unboxed values. There is no deep reason for this. It's simply that our priority was to get simple programs completely working with vectorisation from source down to runtime support before widening the path by supporting more language features - ie, we know how to implement these features, but didn't get around to doing it yet.
We're prototyping using several data-parallel languages for a research project here at Northwestern University, and wanted to get a better idea how we might go about adding vectorisation support for addtional types/operations.
There are certain simple operations which don't appear to be supported for primitive types yet (e.g. the ^ and ** operators for an Int type). These are the kinds of things we'd like to look into as a first step.
Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet?
Up to now, the implementation of operations in the special-purpose Prelude and the array library was essentially driven by the examples we coded so far: http://darcs.haskell.org/packages/dph/examples/ So if we didn't actually use a function somewhere, we probably didn't implement it. Again, the motivation was to get simple examples working before making any attempt at completing the set of supported language features or library functions. Generally, we are always keen to hear what (potential) users need most. Where possible, we take these preferences into account in our work plan. If you are able to add some functionality yourself, that would of course be even better and we would be more than happy to receive patches to include into the distribution. Adding functionality to the special-purpose Prelude should usually be fairly straight forward; eg, support for more data types mostly requires to copy and slightly adapt existing code and new functionality can often be achieved by taking code from either GHC's standard Prelude (but remember the restriction on type classes and unboxed values in the current version of the vectoriser) or the Prelude section of the Haskell 98 report. The difficulty of extending the array library depends very much on the functions that you like to add. Some things are easy as they can be implemented by reusing and adapting existing code, but some functionality requires a clear understanding of the internals of the library. In any case, please feel free to ask if you encounter any problems. We are currently working on automatically generating parts of the repetitive boilerplate of the core array library. This will hopefully simplify adding new functionality. Finally, would you mind telling us a bit more about your research project and what you might want to use DPH for? We are always curious about concrete usage scenarios. If you don't want to discuss this on the list, just send me a personal email. Cheers, Manuel

* Manuel M T Chakravarty
Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet?
Up to now, the implementation of operations in the special-purpose Prelude and the array library was essentially driven by the examples we coded so far:
http://darcs.haskell.org/packages/dph/examples/
So if we didn't actually use a function somewhere, we probably didn't implement it. Again, the motivation was to get simple examples working before making any attempt at completing the set of supported language features or library functions.
It is present here [1] -- so at least it has been implemented. 1. http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-PArr.html#v%3... -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain

Roman Cheplyaka:
* Manuel M T Chakravarty
[2009-02-12 12:16:26+1100] Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet?
Up to now, the implementation of operations in the special-purpose Prelude and the array library was essentially driven by the examples we coded so far:
http://darcs.haskell.org/packages/dph/examples/
So if we didn't actually use a function somewhere, we probably didn't implement it. Again, the motivation was to get simple examples working before making any attempt at completing the set of supported language features or library functions.
It is present here [1] -- so at least it has been implemented.
1. http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-PArr.html#v%3...
That's an old library, not the one used for vectorised code. Manuel
participants (3)
-
James Swaine
-
Manuel M T Chakravarty
-
Roman Cheplyaka