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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
