title: pattern for .NET parallelism beyond a single computer
body: <p>I suspect that I will soon exhaust the speed improving possibilities of threading on multiple cores in a single computer.  </p>
  
  <p>What does this .NET desktop programmer need to learn to move a parallel-feasible problem onto multiple computers?  My preference is to minimize the total lifecycle programming effort so it would be preferred if there were minimal changes between on-premises deployment and off-premises deployment.</p>
  
  <p>With respect to programmer man-hours, is linux, LAMP or some other stack way better than C#.NET on Windows for such an application?</p>
  
  <blockquote>
    <p><strong>Edit:</strong>  Some additional information
    from my own comments below.  The compute-intensive part of the
    problem can be made arbitrarily large
    so overheads to distribute/recombine
    are not a worry because overhead will
    be only a small percentage of the time
    you have to wait for a result.  This
    is a one man development team.  Just a
    suggestion and I don't know if it is
    any good or not: how about WCF and XML
    as means to distribute the problem in
    a completely on-premises
    Azure-ignorant way and trust that it
    will (someday) work on Azure without changes and
    without the benefits of being Azure
    aware.  This is just an unresearched
    idea and I'm hoping somebody has a
    better one even if it is not a Windows
    solution.</p>
    
    <blockquote>
      <p><strong>Another edit:</strong> Digipede has an offering for performance improvements and a paper on the distinction between a cluster and a grid.  </p>
      
      <p><a href="http://www.digipede.net/downloads/Digipede_CCS_Whitepaper.pdf" rel="nofollow noreferrer">http://www.digipede.net/downloads/Digipede_CCS_Whitepaper.pdf</a></p>
      
      <p>Since my problem is more grid-like than cluster and I want to do it cheaply, I'll just try the WCF approach.  </p>
    </blockquote>
  </blockquote>