I already had a suspicion that there's a problem with the deadline here. Thanks for pointing out that _1 means that it's a retry, I hadn't known that. On my 32-core machine, I have 11 _1 WUs running right now, so 1/3rd of the work I'm doing is retry work. That seems high to me.

What's the deadline, is it the deadline for starting the task? Finishing the task? The task being sent out to another user? If the deadline passes and I'm almost done (I have seen this countless times on this sf4-16x271), will I continue to compute it unless the retry beats me to it or does it get cancelled either some fixed time later or on the next sync with the server?

The deadline is 1 week and then there is a 3 day grace period before it is reissued (or maybe the grace period only applies to receiving credit?). The client is usually pretty good at aborting tasks that haven't started before the deadline. If you're contacting the server regularly (once per day or more) I don't think you have anything to worry about.

The "reduced delay bound" is set to .5 which means reissued tasks have 3.5 days to complete. I would assume the 3 day grace period still applies on accelerated retries, so in effect you would have 6.5 days on retries.

Hope that explains things.

It might be worth reporting back your findings to the PARI people, and suggesting that they compare notes with FFTW to see if similar techniques could be employed.

Somebody else suggested this too. I do plan on contacting them. The issue might be that they picked an algorithm that worked well in general for any degree; mine is specialized to degree 10.