home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / sci / math / numanal / 3705 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  2.0 KB
  1. Path: sparky!uunet!usc!howland.reston.ans.net!paladin.american.edu!gatech!usenet.ins.cwru.edu!agate!agate!hcobb
  2. From: hcobb@fly2.berkeley.edu (Henry J. Cobb)
  3. Newsgroups: sci.math.num-analysis
  4. Subject: Re: LU decomposition on very large matrix.
  5. Date: 2 Jan 93 19:48:59
  6. Organization: /rubin/hcobb/.organization
  7. Lines: 37
  8. Distribution: inet
  9. Message-ID: <HCOBB.93Jan2194859@fly2.berkeley.edu>
  10. References: <HCOBB.92Dec23143856@fly2.berkeley.edu>
  11. NNTP-Posting-Host: fly2.berkeley.edu
  12. In-reply-to: hcobb@fly2.berkeley.edu's message of 23 Dec 92 14:38:56
  13.  
  14.  
  15.     I'd first like to thank everybody for their input on this, there
  16. didn't seem to be much of a consensus on this, so we're goning to handle it
  17. like this:
  18.  
  19.     First a quick note: we're using a RS/6000 and we expect the matrix
  20. to be around 500+ MB.
  21.  
  22.     Our game plan is to mmap a file, map the matrix to that address
  23. space and fork off processes to handle chunks of it using MP style code.
  24.  
  25.     Our hope is that while some of the processes are blocked, waiting
  26. for the parts of the matrix that they've touched to be paged in, other
  27. processes will be able to continue crunching on pages that are curently in
  28. core.
  29.  
  30.     We can (and will) take over the machine to run this, but are
  31. wondering what the ratio should be between:
  32.  
  33.     Demand: The combined working set of the running processes. ( = Size
  34. of each block * number of blocks active at a time for a process * total
  35. number of processes)
  36.  
  37.     and Supply: Total system physical memory. (64 MB minus some amount
  38. for the OS and per process overhead).
  39.  
  40.     It seems as though Demand should be about equal to Supply, but we'd
  41. like to hear of any studies on this.
  42.  
  43.     It might prove to be useful to overcommit a little (for some sort of
  44. read-ahead?) or undercommit by some factor (to provide "extra caching").
  45. At the moment we're tempted to just provide args for block-size and number
  46. of processes and test it out that way.
  47. --
  48.     Henry J. Cobb    hcobb@fly2.berkeley.edu    SFB Tyrant
  49.     "A const pointer is a steady reference,
  50.     while a pointer to const is a pledge not to tinker."
  51.