[Swift-devel] Coaster capabilities for release 0.9

[Ian Foster]

With respect to the questions below, 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?
>
>
>