[petsc-dev] Adding support memkind allocators in PETSc

[Barry Smith]

> On Jun 3, 2015, at 10:08 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
>>  Even if it "helps" in only 30 percent of applications that is still
>>  a good thing (and a great thing politically). Then it becomes an
>>  issue of education and proper profiling tools to tell people for
>>  their apps that it won't work; so the other 70% is not "confused".
> 
> How much does it have to help those 30% if the complexity contributes to
> driving 30% of potential new users away from HPC?

  It is OUR job as PETSc developers to hide that complexity from the "most people" who would be driven away from HPC because of it. Thus if Richard proposed changing VecCreate() to VecCreate(MPI_Comm, Crazy Intel specific Memkind options, Vec *x); we would reject it. He is not even coming close to proposing that, in fact he is not proposing anything, he is just asking for advise on how to run some experiments to see if the Phi crazy memory shit can be beneficial to some PETSc apps.


> 
> I'm in favor of doing the simplest thing until presented with
> overwhelming evidence that the complicated thing is necessary.

   Says the man who suggest the PetscThreadComm stuff in PETSc that was recently removed because it was too complicated and had too (no) benefits :-)

>  I
> understand that this doesn't win grants; you have to say that the simple
> thing that has been working will never work at exascale.
> 
>>  Note that Marc Snir today told me that it is perfectly fine if the
>>  "largest computing systems", i.e. the LCFs can only provide useful
>>  performance for a small subset of all possible applications.
> 
> Even when that small subset does not contain the primary apps used to
> sell the machines to Congress.  It's just too difficult to have a
> consistent story.

   The story to Congress is: "China might beat us if you don't give us money", any other effect is third order at best.