Having a long deadline is an advantage, when projects with non-steady supply suddenly has work, like the so-called DDDT2-"rain" or additional work for SIMAP appart for the normal monthly supply (but granted SIMAP has had continous work-supply lately), or when a project suddenly goes from 1+ year left to run down to 1 month and you wants another colour on your badge.

For someone running a project 24/7, it doesn't really matter if the ocassional result takes 1+ month to validate, since they'll anyway get N points/day on average. But granted, for many reasons limiting the deadline to 14 days is in most instances an advantage for both the users and the projects, except for projects like Climateprediction.net where many of the wu's takes 2+ weeks to crunch even while running 24/7.

BTW, even Folding@home where they needs fast turnaround-times due to next wu is based on previous result, has some work with a very long deadline. While much work for SMP and GPU has only 2 or 3 days deadline, going by the status-page where's some GPU-work that AFAIK can easily be done in 1 day with a 48-day deadline.

Multi-threading is great idea being toyed with. There is though a -big- but: If results are serially dependent, how then to parallelize? Then if one thread starts waiting on pieces computed on other threads, you'll discover there can be substantial inefficiency as someone moaned on over at Berkeley [not to speak of the overhead that comes with multithreading]. So, no, this is not the route with what we tend to do at WCG. The sizing to device power is what's coming and as I understand it, the server side coding is presently being integrated from Berkeley... loads of testing ahead for the work generation and distribution system. Dynamically sized is BTW an overstatement; There will be multiple sizes from which the distributor will pick the appropriate size based on the device class, which is my simplified understanding.