On Sat, Oct 6, 2012 at 8:31 AM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The important point here, however, is the independence from the implementation libraries, otherwise we would have to maintain a separate memory management implementation for each GPU library we possibly interface with.</blockquote>
</div><br><div>Surely you'll have to implement it differently regardless. Is the issue just that you want one publicly visible interface for syncing memory? Or would you like a separate interface for synchronizing to different kinds of accelerators, but for the logic behind that interface to be reused?</div>
<div><br></div><div>I don't know if anyone wants to simultaneously use different accelerators (GPU and MIC?), but I could imagine a Vec type that supports memory residing in more than two spaces, choosing to perform the operation wherever the data is most current.</div>
<div><br></div><div><br></div><div>For code navigation, I don't if you looked at the "gtags" part of the user's manual. If you use Emacs or Vim, it's an excellent way to tab complete forward and reverse lookup. Note that PETSc's naming convention is good for tab completion of implementations.</div>