[this message is going out to the Mersenne mailing list and the current volunteers; ignore paragraphs which don't seem relevant to you] I'd like to beg pardon for particularly gross stupidity in the matter of optimisation. After prodding from Joe Decker, I realised my code was being very inefficient in using bsearch every time; now, it uses a table to look up the top 17 bits of a^5+b^5+c^5, which throws out a lot of values immediately and usually means a linear search is more efficient than bsearch over the remaining values. Laurent Desnogues pointed out that I could just return (u-v) from the qsort compare routine rather than doing comparisons, which provided a further 15% improvement because the MS C compiler produces rather inefficient code for 64-bit comparisons; I'm not sure how this will affect glibc systems. I've updated the Web page, though I don't have a Linux box with egcs-1.1.1 available and it would be good if someone with one of those compiled the source with i586 and i686 optimisations (statically linked), and mailed me the result. Just download the source or executable, and it will chew through the rest of your range in (hopefully) under 24 hours. If you've not been issued a range yet, please run 's253 TEST' and I'll issue you a range. The project will be completed by about Saturday at this rate; I'm currently working on a version looking over a much larger range, which would keep distributed.net occupied for a few days. I've received a few partial results from people - don't be too amazed if the .results file contains non-trivial results [ones not of the form 0 0 x], the code will pick up every multiple of every rearrangement of the [27 84 110 133 144] solution, and this is deliberate so I can check easily that it hasn't missed anything. Tom
