Latest boinc version thread

[rcofell]

About the optimized clients, the only reason to use an optimized [boinc] client is to match up with an optimized science application, so that your reported score(benchmark * time) is somewhat accurate when compared to someone doing the workunit with the standard science app. A workunit should be worth the same no matter how it's crunched, no? The optimized client evens things back up by boosting the benchmark, usually by compiling with SSE(1/2/3/4) optimizations through the compiler.

Granted there's the fact that the existing benchmark system isn't so great to begin with, but how else could you do an accurate comparison when it's a unique workunit being crunched by only you? The best would be a benchmark built into the specific workunit that's based on of the algorithms actually being used, but that would probably be too complex to implement, plus you'd have all the complaints about inter-project scoring... Truth be told, running a large quorum is actually the most fair of all under the existing system, since you're being paired up with a good mixture of the other computers running the project and you're all deciding on what the fair value for a workunit is. Despite the attitude sometimes expressed here, you're not getting cheated out of anything. Sure it may seem like other computers are dragging your score down, but the truth is if you have a faster computer you would have finished the workunit faster and will be able to get more done in the same time period as a slower computer. Total throughput is the factor here, score per workunit(should be constant across different machines to be fair as a scoring system) * workunits per day, much like processor speed is based on the balance of architectural efficiency and clock speed

This works out for seti@home, since the source code for the science app is open source and people are allowed to optimize it; this would mostly include taking advantage of newer processor instructions like SSE, or I suppose any other optimization techniques, like inline code perhaps. Now in the case of WCG, all the projects being run are closed source, so we can't tamper with the code and optimize it, even with just compiler options. This is understandable, since we're mostly dealing with medical computations, where accuracy is very important(which the quorum system should help with too).

It would be great if these projects would optimize for SSE, but the fact is they have to make it so the program runs on practically any x86 processor(i386 you could say), so it's pretty unoptimized for modern processors. Of course, boinc added the capability to read cpu instruction flags later on, so this does give the ability to select what's the most optimized science app a computer can handle, but I'm sure it won't be much use until a majority of users have a version supporting that(not sure what version it was added, maybe 5.10.x).

So this basically leaves us with this, if you run an optimized boinc client without an optimized science app, then you gain nothing. It could be considered cheating in a sense, since you're knowingly(hopefully) inflating your score, somewhat like the lazy person claiming he did the most work... It doesn't really make anything go faster computation wise, maybe the boinc client will be a little snappier, but that has almost no bearing on the workunit being crunched.

About upgrading clients, technically there should be nothing wrong staying back at 5.10.30(or probably even 5.10.23). It's just what you prefer, I like to stay up to date if I can, but sometimes I don't pay attention and run behind. New features are always nice, but there hasn't been anything major added, I think they're just maintaining the 5.10.x code base until they release 6.x.

I didn't intent on writing a book on this, but it was quite an issue a while back and thought I should voice my thoughts on it

P.S.
I tried running all the 6.1.x clients after 6.1.0 and they all seem to have that CA certificate issue with WCG only, since they're the only project to require a secure connection. Word is it'll be fixed in 5.10.9, so in the meantime stick to 6.1.0 or a 5.10.x release.