ANN: Paraffin 3.1

ANN: Paraffin 3.1

[Brad Moore]

I am pleased to announce the availability of Paraffin 3.1

Paraffin is a set of Ada 2005 generics that may be used to add
parallelism to iterative loops and recursive code.

Paraffin also includes a suit of useful parallel utilities that
utilize the Paraffin generics. These include generics for;
    1) generic to integrating a function in parallel
    2) generic to apply quicksort algorithm in parallel to an array
    3) generic to apply fast fourier transform to an array of data.
    4) generic Red-Black tree container that performs some operations
       in parallel.
    5) function to solve matrices using Gauss-Jordan Elimination

The latest stable release and older releases may be downloaded from;

  https://sourceforge.net/projects/paraffin/files/

For those who want the current development versions of the source they
can download using git (http://git-scm.com/) by issuing the following
commands;

  mkdir sandbox
  cd sandbox
  git clone git://paraffin.git.sourceforge.net/gitroot/paraffin/paraffin

The current development version typically will correspond to the latest
stable release, but may at times be unstable when new features are being
worked on.

Major Changes since the last announced release: (was version 2.4)

Paraffin-3.1  - Current Version

- Major improvements to Iterative Work Stealing.
   a) Work Stealing can now use for loops, (like work sharing and work
      seeking)
   b) Client supplied subprogram profile simpler where Start and Finish
      are "in" parameters in terms of a client supplied
      Iteration_Index_Type
   c) Work Stealing performance is much improved. The number of
      iterations does not affect performance, and now all tests are
      comparable (often better) than work sharing and work-seeking.
   d) Minimum_Steal input is used to control how fine-grained the
      work stealing, as before. The default value automatically chooses
      a value that should give good performance, if the client does not
      wish to provide that input.

Paraffin-3.0
-  This is considered to be a major revision, because many of the units
    were renamed, and the interface to the recursive generics has been
    changed.
    a) Units that previously were work sharing were implicitly work
       sharing. Now work_sharing appears in the file name to make this
       more obvious.
    b) Units that previously had "composite" in the name, now have
       "procedural" in the name, which better describes that the generics
       use procedures, rather than functions.
    c) Units that previously had "elementary" in the name, now have
       "functional" in the name, which better describes that the generics
       use functions, rather than procedures.
    d) The recursive generics are now packages instead of procedures.

- A non-portable feature of the code which used the GNAT attribute,
   'Unrestricted_Access, now uses the portable attribute
   'Unchecked_Access in the recursive generics. Paraffin should now
   be fully portable to all Ada 2005 compilers.

Thanks to Adam Beneschan from Irvine Compiler Corporation for pointing
out the portability issue, and several suggestions for workarounds, and
thanks also to Steve Baird, from Adacore whose suggestion led to a
portable solution that did not noticeably impact performance.

- For the recursive generics, you no longer need to supply an access
   to subprogram type when instantiating the generic. Instead, you use
   an access to class-wide type that is provided by the package, and
   instead of calling a Recurse subprogram that calls into the generic,
   you make a dispatching call through the tagged type.

- All the units have the Preelaborate pragma.
- Units were modified to allow them to be preelaborated.
- The FFT test program has the Preelaborate pragma, and all
   trigonometric function calculations are performed at compile time,
   and an array of these constants is provided at compile time.
- All the recursive generics now do the final reduction using the
   reducing linked list facility. This means that the final reductions
   occur in parallel, rather than sequentially. Likely this wont be
   noticeable in terms of performance, unless the amount of processing
   for a reduction is significant.


Brad Moore