attachment:notes_cohn.txt of msri07/notes

   1 1:45 p.m.
   2 Parallel Computation Tools for Research: A Wish List
   3 Henry Cohn
   4 
   5 No technical content.  Just a springboard for discussions.
   6 Cohn is a user, not an expert in parallel computation.
   7 
   8 Large computations are increasingly important in mathematics.  Computer-assistend proofs.  GIMPS
   9 
  10 Often embarassing parallelizable.  Usually carried out by ad hoc means.  Lots of things that non-experts would like to do b/c barriers are just slightly too high.
  11 We shouldn't build more powerful and sophisticated tools (all the time), but also focus on easy-to-use-for-everyone tools.
  12 
  13 Three Scenarios:
  14 	1) GIMPS model of recruiting many volunteers
  15 	2) Use among collaborators simply for organizing a large-scale computation. (more concerned about)
  16 	3) Use on multicore computers.
  17 
  18 It's a real pain to get parallel computing up and running.
  19 
  20 BOINC is a nice system set up to manage many computers, but not good for the casual user.
  21 
  22 If you limit yourself to simple programming in a common file system amongst computers to pass information back and forth, you can't just scale past that file system.
  23 
  24 What we really need is a flexible system for automating distribution over many computers (only when trivially parallelizable)
  25 	The particular problems in mind are not low-latency, fine-grain problems.
  26 	Many assumptions are being made behind the curtain here.  Assuming that these problems will be similar to most of the
  27 	problems that other general users will encounter.
  28 
  29 Server must be trivial to set up.  No communication between clients.  Clients can download and return answer or fail.
  30 Problem times out if client times out.  Authentication can be required for clients.
  31 
  32 	There are some open Darwin-based things that are already doing this, it seems.
  33 	What this wishlist is concerned with is generalizing this to run on a heterogeneous system and a few other things.
  34 	Changing this to an easy-to-use system is one of the biggest goals.
  35 
  36 	Authentication problem with TCP/IP.
  37 
  38 Usage:  Random volutneer arrays can cause a lot more problems than they're worth for the common user--mostly arising from
  39 issues of safety and authentication.  We don't have to create a massive framework to achieve most of our goals.
  40 
  41 Issues for clients:  Malicious code, stability, resource hogging, suspendability.
  42 Critical for any volunteer or corporate users.
  43 
  44 Sees only one realistic option:  Sacrifice some overhead to run these calculations on a virtual machine.
  45 Users don't have to worry (as long as there is a reasonable implementation of a virtual machine) about security issues.
  46 Can be suspended at will.
  47 This is "virtual machine" in the sense that we have a self-contained running environment that never escapes to the computer.
  48 This is no sinecure, but can reduce worries.
  49 	The idea is that people are always going to want to exceed the resources they have available.
  50 	Virtual machines are not always slower.  SAGE runs more quickly in OS X or Windows with a Linux VM.
  51 	Spammers may want to use this for malicious spam-oriented purposes.  Feels like there's not too big of a risk.
  52 	One vision for the future:  Log into a server, get a list of jobs running on the server, select which job(s) to join.
  53 
  54 Server: DDoS attacks seem to be primary risk.  Do what we always do.
  55 
  56 Tampering with results:  Mischief (user shows up with bogus answers)
  57 Sabotage (users flood bogus answers to corrupt research calculations)
  58 Fraud (exaggeration)
  59 --It is unclear exactly how much we can deal with these problems.
  60 	-Consistency checks.  Farm out problem to several clients to check answers.  Ask about CPU time, resource use, etc.
  61 
  62 Risks of tampering depend on anonymity.
  63 Use of anonymous volunteers almost always invites certain risks due to the anonymity.
  64 	Should we trust code blindly?  It -should- be okay, but errors can crop up even in "good" code.
  65 
  66 Volunteers and the program(s) should always be credited.  If anyone made a critical contribution, they should be individually
  67 acknowledged as well.  The finer details of this should be left to community consensus.
  68 
  69 	Should there be a cutoff for acknowledgement?  If you provide 10% of the computing power, should you be credited
  70 	individually?  It could turn off individual users, since those 10%'s will be provided by clients with supercomputers.
  71 	How do we measure the "computing power?"
  72 	Maybe the clients can make demands from the server; make the server enter into an agreement where if the client
  73 	provides enough, the client will be credited.
  74 	A community consensus would be nice, but these other options are flexible.
  75 
  76 Within 10 years, the principal application will be massively multicore machines.  We don't even know how to build a good
  77 computer algebra system for one of these machines.
  78 
  79 Speculative execution?  If the user starts typing in a function, will some of the cores start plotting the function?  Start
  80 calculating other things about the function?  Then, if the user wants any of that, it will already be computed.