attachment:notes_martin.txt of msri07/notes

   1 Jan 31, 9:00 a.m.
   2 MPMPLAPACK: A Massively Parallel Multi-Precision Linear Algebra Package.
   3 Jason Martin
   4 
   5 Vaporware.  Slapped together to try multiple approaches
   6 
   7 The number theory computations he was doing would often reduce to linear algebra over Dedekind domains.
   8 This also occurs in algebraic geometry.
   9 There are not many pure math parallel linear algebra tools.
  10 
  11 Wants an open source software library that can
  12 	Handle linear algebra for modules over "nice" rings
  13 	Reasonably use all the cores on a desktop (single machine)
  14 	Reasonably use clusters or supercomputers
  15 	Droppable into favorite program
  16 	Portable
  17 	Very, very, very maintainable
  18 
  19 What is meant by Linear Algebra:
  20 	Operations on/with elements, blocks, rows/columns, etc.
  21 	BLAS-ish routines
  22 	Higher-level (HNF, SNF, JCF, etc.)
  23 	Lattice reductions, discriminants, etc. when possible
  24 	Sane (computationally) representations for products (wedge, tensor, direect, etc.)
  25 	Anything currently available on systems such as Magma
  26 "Nice" rings are integers, rationals, intergers modulo n, finite fields, polynomial rings over integers or integers modulo n or finite fields, Dedekind domains and their fraction fields, local rings, local fields, ...
  27 	Dedekind domains = rings of algebraic integers
  28 Cohn's algorithms all seem to reduce -eventually- to linear algebra over Dedekind domains
  29 
  30 At the pc level, parallel operations should make reasonable use of multicore systems, and should do this even when tasks aren't ridiculously time-intensive (most general applications should make use of the power).
  31 What is being developed should, at any level, easily replace current linear algebra in packages such as Pari and Macaulay 2, and be easily integrated into emerging packages.
  32 
  33 Portability:
  34 	Should be Pure ISO C  (with wrappers for usability)
  35 	Dependence only on established, well supported libraries.
  36 	64 bit clean (data structures that live in memory are masked to you until they're moved and you read in the middle of the data structure), byte-order neutral
  37 	Thread safe (all functions re-entrant)
  38 	Simple config and build operations.
  39 A lot of these portability issues will lead to a sub-optimal performance, but this is acceptable for portability.
  40 
  41 Maintainability:
  42 	Painfully rigorous coding standards.  For example, full test code for every function developed.  LAPACK is a good example of such rigorous standards.
  43 	(small-ish) pool of dedicated programmers.  Thinking GPL or LGPL license.
  44 There's a large disparity over which license to choose.  There's fine points of any number of licenses, mostly when it comes to funding, or use by companies.  Strong feelings in the different camps.
  45 
  46 Ideas for the future:
  47 	Runtime profiling and tuning.
  48 	Sparse / black box support
  49 	Fault tolerance
  50 
  51 Design decisions so far:
  52 	Modular (programming) design with recursive data types
  53 	Use pthreads/MPI hybrid approach?
  54 		-Allows single machine users to use library even if they don't have MPI.  The idea is to have a server with the library that the users can use without needing heavy MPI implementation.
  55 	Scalability in the future?  MPI and pthreads both have their advantages.  MPI scales more easily to large (cluster, heterogeneous, etc.) environments.
  56 
  57 	The scientific computing persons seem to be pushing for GASNet.
  58 	MPI has difficulty passing complicated data structures.
  59 
  60 Realistic approach to development:
  61 	Start with the domain of the integers.
  62 	Get an API specification by/around May 2007
  63 	Initial release of "working" code for August 2007
  64 
  65 There is are a -lot- of details to consider when designing a large package for multi-platform general use.  Architectures are so different across the machines that install-time tuning and the ability to fine-tune is almost paramount.