...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?
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.
RE: Yes, thanks for the
)
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?
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.