[Swift-devel] Coaster capabilities for release 0.9

[Mihael Hategan]

On Wed, 2009-04-22 at 07:26 -0500, Ian Foster wrote:
> With respect to the questions below,

There are 3 very specific questions below, not one. You answered none of
them.

>  I think it is important that  
> people be able to say "do X" and have the system do X.  Of course if  
> it is also possible to say "do X, but if you think that can do better  
> than X, give it a try", that will be good too. But that would be  
> something to ask for explicitly.
> 
> 
> On Apr 21, 2009, at 4:44 PM, Mihael Hategan wrote:
> 
> > On Tue, 2009-04-21 at 16:16 -0500, Ian Foster wrote:
> >> Is it possible to argue for simplicity in these algorithms?
> >>
> >
> > Yes.
> >
> >> E.g., if I want to submit against an allocation, I should be able to
> >> do that, and not have the algorithm second-guess me and do something
> >> different.
> >
> > Yes. That would be one particular case.
> >
> >>
> >> Having more complex things is ok, too, as long as they can easily be
> >> turned off--or (my recommendation) require that they be turned on
> >> explicitly.
> >
> > What you say does beg for a couple of questions:
> > - if all work is done in a run but the allocation has more time left,
> > should the workers be shut down or not?
> > - if more work remains to be done in a run after an explicit  
> > allocation
> > was used, should the system attempt to allocate more nodes? If not,
> > should it hang? Fail?
> > - if the allocation is far in the distance from now, and a run is
> > started now, is allocating nodes now a matter of second-guessing or a
> > matter of trying to finish the work faster? What, besides alleged
> > complexity of the algorithm, would be the downside of doing so?
> >
> >
> >
>