I was just now trying to figure out where a "Use" actually results in memory being copied to the GPU. (In particular, I was wondering if it's a double-copy because UArray lives on the Haskell heap and doesn't let you get a Ptr, right?)
Anyway, I ended up looking at these two files:
Here are some of the things that are giving me trouble:
Ah, as to the original question: I see that it's uArrayPtr in Array/Data.hs from the main accelerate package that does the trick. So rather than copy it uses pinning and accesses the array inplace. And I see that they remain pinned for their lifetime Ok.
But why fundamentally are Accelerate array left opaque? It seems to require copying to work with other libraries. (Data.Array.Accelerate.IO currently doesn't provide O(1) operations from UArrays.)
Update: I made one refactoring to tighten up importing conventions. In this case to Accelerate.hs:
This is one step to make it easier to trace through the code to where things are defined.
Here is my ghci script, that lives in the root of my accelerate-cuda directory. I have a similar thing for all of the repositories. Note that there is a bug in ghc-7.6.1 that affects us (#7299) so you won't be able to run anything. A quick and dirty fix is to replace keepAlive in CUDA/State.hs with return.
# -package-db cabal-dev/packages-$VER.conf \
$GHC -i../accelerate \
-optP -include -optP dist/build/autogen/cabal_macros.h \
Array/Data.hs deals with accelerate representation arrays: arrays of tuples represented as tuples of arrays, etc. Array/Prim.hs handles the actual underlying data.
hmm... actually, I'll put these scripts of mine into the various util directories. I'm sure others will find it useful as well.
Great, that's very helpful!
I think that just increases the noise.
I don't know which editor you are using, but basically any mature editor provides a project-wide search facility (otherwise, you are stuck with using grep). To find the definition of a function, just do a project-wide search for " ::".
I use emacs and do use moccur some.
The original cause for problems was the fact that names aren't globally unique. So a text search will get multiple hits. Also, whitespace can cause problems. For example grepping for "useArray ::" won't catch the following multi-line one (in Prim.hs) so one needs to be careful with the regexps:
:: forall e a. (ArrayElt e, ArrayPtrs e ~ Ptr a, DevicePtrs e ~ CUDA.DevicePtr a, Typeable e, Typeable a, Storable a)
It's true that the patch for this file was noisy. I hope that doesn't matter much since it's just a reexporting module. However, in general I find that following tight importing conventions (qualified or explicitly enumerated) isn't too much of a burden in most cases and is worth it, but it's certainly subjective.
Sorry if this gets off topic, but if you use emacs, you might want to use etags for code navigation. The hasktags program will create etags for haskell functions.
Thanks, I used to use tags for OCaml but have never got around to setting it up for Haskell. I've been VERY happy with ghc-mod for in-editor colored error messages and warnings, and tags would be another good step towards approximating an IDE.
Still, I think in general it's good to be aware of the person who stumbles into the code off Hackage trying to find or fix something without having everything set up perfectly.