[petsc-dev] Adding support memkind allocators in PETSc

[Barry Smith]

> On Jun 3, 2015, at 10:35 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>  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. 
> 
> Absolutely.  So now the question becomes "what benefit can this have,
> predicated on not letting the complexity bleed onto the user.
> 
>>  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.
> 
> And my advice is to start with the simplest thing possible.
> 
> I'm also expressing skepticism that a more sophisticated solution that
> _does not bleed complexity on the user_ is capable of substantially
> beating the simple thing across a meaningful range of applications.

  There you go again with "meaningful range of applications". Why can't you get it through your head that if cosmology science advances at all from exascale (which I doubt it will, speaking of unethical bastards) then all of exascale is like totally worthwhile :-)

> 
>>   Says the man who suggest the PetscThreadComm stuff in PETSc that
>>   was recently removed because it was too complicated and had too
>>   (no) benefits :-)
> 
> Yes, I was trying to solve a problem that didn't need to be solved.  My
> mistake.
> 
>>   The story to Congress is: "China might beat us if you don't give us
>>   money", any other effect is third order at best.
> 
> A smart Congress would say "redefine 'beat us' to something that matters
> and stop wasting your time on vanity".

  Two words that will can be next to each other: smart congress