upcoming GW run S6Bucket (was S6GC1)

robertmiles
robertmiles
Joined: 8 Oct 09
Posts: 127
Credit: 20956335
RAC: 76873

RE: Yes, thanks for the

Quote:

Yes, thanks for the update.

Quote:
...eliminating candidates before sending them back might therefore increase the sensitivity of the search, too. One unwanted side-effect of this vetoing would be that the run-time of a given task becomes data-dependent and less predicable.

Does this mean the work-unit would abort mid-task when a known artifact is encountered? I assume that this would only reduce the time taken on any given task, not increase it?

If so, would this only be an issue for calculating credit? Sorry if I am misinterpreting your explanation!

How practical would it be for the workunits to store more candidates in their internal databases, but only use the extra ones to replace any known artifacts that are vetoed?

robertmiles
robertmiles
Joined: 8 Oct 09
Posts: 127
Credit: 20956335
RAC: 76873

Is there any chance of

Is there any chance of producing a GPU version of the S6Bucket application?

So many workunits are already available that doing so should reduce the demand for BRP4 workunits, which currently don't seem to be produced fast enough to meet the demand.

I've already read of several reasons on other BOINC projects why some of their applications could not be converted to GPU versions, but many of us would like to know WHICH if any reason explains it for S6Bucket so we'll have some idea about what if anything we can do to help.

Another idea on the vetoing: Store more candidates internally in the workunits, but send back only as many of the extra ones as vetoing is expected to remove.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.