Evaluation Accelerate

Project Health

How good is the project health? That is, we want to determine how likely is it that development on the language will continue and that it will keep getting funding and interest from developers.

Subquestions include:

• (in report) Quality of documentation

  Good, but lacks tutorials. (Ported to report. Please perfom updates there.)

• (in report) Code review

  The Accelerate codebase is large for a Haskell library, and a bit overwhelming at first. They have a good division between frontend (the accelerate package) and backends (e.g. the accelerate-cuda package), which limits the amount of code you have to get into. You don't really have to understand the complete frontend to modify in the backend and vice versa). A good overview document of the different modules, and their tasks would be a great benefit for getting other hackers involved.

  (Ported to report. Please perfom updates there.)

• (in report) Portability

  Accelerate in itself is pretty portable (across platforms, not Haskell compilers), as they have limited the number of dependencies to only a handful. For the CUDA-backend that is not the case, there is a large suite of dependencies

  (Ported to report. Please perfom updates there.)

• (in report) Installation process

  We got it to run on GHC 7.4.2, but it still doesn't support GHC 7.6.1, possibly because of external dependencies

  We had some trouble installing the version on hackage, because of a minor bug in the cuda-bindings. The bug was caused by code generated by c2hs, so it might be something that depends on the version of CUDA installed.

  We had major troubles installing the development-version from their repository, mainly caused by a lot of dependency issues and conflicts. We still have to compile the CUDA-backend.

• (in report) Number of dependencies (incl. GHC extensions)

  • 19 GHC extensions in Accelerate:

    BangPatterns CPP GADTs PatternGuards ScopedTypeVariables TypeOperators OverloadedStrings FlexibleInstances RankNTypes DeriveDataTypeable FlexibleContexts MultiParamTypeClasses StandaloneDeriving TypeFamilies TypeSynonymInstances KindSignatures TupleSections MagicHash UnboxedTuples

  • 8 package dependencies for Accelerate:

    array base containers ghc-prim pretty bytestring blaze-html text

    These are commonly occuring packages. (Depending on obscure packages are quite possibly detrimental to project health)

  • 5 extensions in accelerate-cuda:

    QuasiQuotes TemplateHaskell UndecidableInstances OverlappingInstances IncoherentInstances

  • 23 package dependencies for Accelerate-cuda:

    accelerate array base binary bytestring containers cryptohash cuda directory fclabels filepath hashable hashtables language-c-quote mainland-pretty mtl pretty process srcloc text transformers unordered-containers Win32 unix

    (Some packages are of unconfirmed stability/reputation)

  • 4 extensions in accelerate-io:

    ForeignFunctionInterface ExplicitForAll EmptyDataDecls FunctionalDependencies

  • 6 package dependencies for Accelerate-cuda:

    accelerate array base bytestring repa vector

• (in report) Number of users (reverse dependencies)

  Total list of packages on hackage that depend on "accelerate", excluding the various accelerate backends (recursively):

  abstract-par-accelerate (only via flags, not found by automatic script) meta-par-accelerate scan-vector-machine

  i.e, two reverse dependencies.

• (in report) Number of contributors

  For darcs this can be done by

  darcs log | grep -e "^[^ ]" | cut -c 31- | sed "s/^[ ]//" | sort | uniq | wc -l

  The last 12 months have seen a total of 6 contributors. Across all time, 14 people have contributed to accelerate.

• (in report) How easy is it to start contributing?

  Accelerate is hosted as a git repository on github.com, so getting a copy of the latest source code and submitting patches is structurally straightforward.

  TODO: What about extensibility of the codebase?

• (in report) Latest project activity (e.g. which version of GHC does it compile on?)

  Accelerate has been actively maintained the last 12 months.

• (in report) Licensing

  BSD-like.

• (in report) Funding

  The two main contributors, Trevor L. McDonell and Manuel M T Chakravarty, are both employed by University of New South Wales, Sydney, Australia, and assumably maintain Accelerate as part of their research there.

Ease of use and expressiveness

How easy is the language to use? And how expressive is it? Our aim is to find a language that might be suitable for a financial engineer and we thus want a suitably high-level language. It should be near the complexity level of R. We still want the language to expressive enough to cover the domain of financial algorithms.

Subquestions include

• Which programs can we write, and which can't we write?

  • Can we write nested loops?
  • Does it include all of: scans, folds, zip/map, stencils,

  It seems that we can, provided they may be unfolded at compile-time.

• How good are the error messages?

• How high-level is it on the scale from R to CUDA?

NOTES: Nice pretty-printing facilities: Graphwiz, Html and Text.

Performance

How does the languages compare in a performance benchmark?

• Benchmark of binomial pricer on expiry = 1,2,4,8,16,32,64,128 years.

  We have yet to be able to produce a version of the binomial pricer in Accelerate that terminates within 24 hours.

  It seems that the array fusion optimization produces an exponential overhead, while removing it yields a distinct kernel for each iteration of the algorithm - equally ineffective.

• Benchmark of Longstaff and Schwartz

  TODO

• How many in-code optimiser hints (inlining-statements, forcing of delayed arrays etc.) are necessary to get decent performance?

  Since Accelerate is a deeply embedded dsl, haskell-level inlining has no effect on performance. We (I, plc) are not aware of any performance hints for accelerate.

• How does the performance of a naive implementation (no optimiser hints) compare to an optimised version?