Skip to content

accelerate-cuda: Data.hs/Prim.hs code browsability problem #70

Closed
rrnewton opened this Issue Nov 8, 2012 · 9 comments

4 participants

@rrnewton
Data.Array.Accelerate member
rrnewton commented Nov 8, 2012

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:

https://github.com/AccelerateHS/accelerate-cuda/blob/25ae284bdc6c65fda459d03590dd844e38cb67c8/Data/Array/Accelerate/CUDA/Array/Data.hs
https://github.com/AccelerateHS/accelerate-cuda/blob/25ae284bdc6c65fda459d03590dd844e38cb67c8/Data/Array/Accelerate/CUDA/Array/Prim.hs

Here are some of the things that are giving me trouble:

  • import lists that aren't qualified so it's hard to work backwards from a name to where it's defined
  • can't load the code in GHCI (too many preprocessor macros that don't work) to use :info and find out where things come from
  • identical sets of names (e.g. "useArray") in different files (e.g. Prim.hs/Data.hs), with no module-level documentation explaining the situation
@rrnewton
Data.Array.Accelerate member
rrnewton commented Nov 8, 2012

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

@rrnewton
Data.Array.Accelerate member
rrnewton commented Nov 8, 2012

Update: I made one refactoring to tighten up importing conventions. In this case to Accelerate.hs:

9617279

This is one step to make it easier to trace through the code to where things are defined.

@tmcdonell
Data.Array.Accelerate member

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.

#!/bin/bash

GHC=/usr/local/bin/ghci
VER=`$GHC --numeric-version`

#  -package-db cabal-dev/packages-$VER.conf \

$GHC -i../accelerate \
     -optP -include -optP dist/build/autogen/cabal_macros.h \
     -iutils \
     -Iinclude \
     -DACCELERATE_DEBUG \
     -DACCELERATE_BOUNDS_CHECKS \
     -DACCELERATE_INTERNAL_CHECKS \
     $@

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.

@tmcdonell
Data.Array.Accelerate member

hmm... actually, I'll put these scripts of mine into the various util directories. I'm sure others will find it useful as well.

@rrnewton
Data.Array.Accelerate member

Great, that's very helpful!

@mchakravarty
Data.Array.Accelerate member

@rrnewton Regarding

9617279

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

@rrnewton
Data.Array.Accelerate member

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:

useArray
    :: 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.

@kantp
kantp commented Nov 14, 2012

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.

@rrnewton
Data.Array.Accelerate member
rrnewton commented Dec 1, 2012

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.

@tmcdonell tmcdonell closed this Aug 16, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.