[petsc-dev] Adding support memkind allocators in PETSc
Jed Brown
jed at jedbrown.org
Wed Jun 3 22:35:26 CDT 2015
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.
> 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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150603/176c94e7/attachment.sig>
More information about the petsc-dev
mailing list