<div class="gmail_quote">On Sat, Nov 26, 2011 at 12:34, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>I do not see DG a fundamentally different.</div></div></blockquote><div><br></div><div>It's not, but there are two traversals in play: an element-based traversal and a face-based traversal. That means that memory layout for efficient traversal is a multi-objective problem. Of course you can do a few things redundantly, but evaluating all the face fluxes redundantly would be hard. Also, if you do a single traversal where cells evaluate fluxes on some of their faces when they come to them, you lose lock-step between threads. These are the reasons why I think it's a better test case to understand.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div></div></div><div>My first rule would be, never assume library intelligence. So we make it possible to give a schedule for kernels, but initially there is</div>
<div>no scheduling code. It is user input, with a dumb default. The flat memory is the thread shared memory, and everything else is messages.</div></div></blockquote><div><br></div><div>Fine, but now it looks like we have a two-level interface because we have to know what distributed memory operations are needed before launching kernels. The kernels don't see a global address space in any implementation I'm aware of.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Can we have a way to specify the required memory access before launching the kernels?</div>
</blockquote></div></div><br>This is exactly what Victor's thing is about</blockquote></div><br><div>Well sure, except that it doesn't say anything about how that would be done. It's a model of distributed computation that currently lacks a statement about what the interface would look like or even which things the user specifies.</div>