Newly built 5.4.10 optimized windows boinc client
29 Jul 2006 23:42:17 UTC
Topic 191633
(moderation:
I got bored today and built a new 5.4.10 boinc client that increased the wetstone score about %50 higher and the drystone about %300 higher than the stock 5.4.9 boinc client on my laptop. To use these binaries you must have windows xp/2000 and a SSE2 capable processor. The binaries can be downloaded at https://boese.kicks-ass.net:7000. Enjoy!!!
Newly built 5.4.10 optimized windows boinc client
)
Which is useless on Einstein and SETI. Besides cheating for credit on projects that are still dependent on benchmarks what else does it accomplish?
me-[at]-rescam.org
Well the main advantage for
)
Well the main advantage for me is because I also optimized the wxWidgets build the boincmgr GUI seems to lag less and be more responsive to input. Granted it is not a big deal and credits are lame anyway and it is all about the science but like I said I was bored and was just throwing it out there.
One other advantage I forgot
)
One other advantage I forgot to mention is that I built it off the CVS head so the code will be more recent that the 5.4.9 code which may be good or bad depending but it is very recent snapshot.
And? Its still just cheating
)
And? Its still just cheating if this client is used for other projects.
Sadly, this will be happen for sure by certain subjects. Maybe they will ask you to inflate the benchmark much more for creditfraud.
Compile it without the benchmark alternation and it will be valuable for use.
RE: And? Its still just
)
Actually I didnt change the source code at all. I just compiled faster binaries (whole program optimization, etc). I dont feel this is cheating really (not that I give a rats butt about credit anyway, too much like $ in a video game) because I am just more accurately reflecting the optimization found in all these science binaries anyway. FYI I realized my alias for cvs command was for stable branch instead of for the head in CVS so that is why the client is 5.4. Probably better anyway because the 5.5 branch sounds fooked right now anyway.
RE: RE: And? Its still
)
You may have optimed the benchmark code so it no longer has a real meaning, using only a compiler switch. End result however, is bogus data times to projects that still use the benchmark. And now you're making these bogus clients available to others?
You should really understand what your actions generate, and maybe ask the folks that really control the code, before releasing a new boinc to the world, IMHO.
RE: You may have optimed
)
So basically what you're saying is that brewing-your-own-BOINC is considered harmful? What about BOINCs known to be bad? E.g. i'm seriously thinking of Boinc 5.4.9 for Linux which is kinda sluggish.
Public offence if i brew my own?
Sorry, i strongly disagree with you although you have a point. OTOH the same benchmark-code is running on different platforms differently, 'cause there's ony one BOINC-binary for a platform, let's say Wintendo-universe but no Windows-XP-Intel-Pentium-IV universe. Does the static benchmark-code of BOINC take that into account? If yes, how? If not, why should optimizing be any different of running BOINC on a platform which performs differently?
My two cents,
Alex.
"I am tired of all this sort of thing called science here... We have spent
millions in that sort of thing for the last few years, and it is time it
should be stopped."
-- Simon Cameron, U.S. Senator, on the Smithsonian Institute, 1901.
Compiler optimisations,
)
Compiler optimisations, especially inlining functions, loop optimisations and sometimes loop enrolling, often do not perform the same calculation steps anymore, if the compiler finds out that there is an easier way to find the same result.
It's about the same faked benchmark then that some video card producers had. They recognized certain benchmarks, knew what those benchmarks expected and instead of calculating it they had a hardcoded program that performed the same display operations (clipping and so) - but without calculating them.
If the compiler is asked to calculate and display the square root of 2 a hundred times and it finds that it is enough to calculate the square root of 2 only once and then display it a hundred times, it isn't the same benchmark anymore.
This is not a bug in those compilers, they are expected to do that as normal programs are supposed to run as fast as possible.
It is possible to make use of the "volatile" keyword in benchmark functions in order to disable certain optimisations, another option is to apply specific, less optimizing compiler options to the benchmark modules.
The only volatile variables seem to be the CSV ID strings (something like the sccs "what"-string) though, so maximum optimisations will have their full impact on the benchmark functions.
I think it would be a good idea to add "volatile" attributes to some benchmark variables, but that will only affect future versions of course.
RE: So basically what
)
Boinc had a problem with windows "over optimizing" the benchmark code on Windows, leading to problems between windows and non-windows, and in the std client, it's better, but not perfect.
And now you post a client which has a 300% improvement over the standard, and making it available to all. This to me, indicates that your client doesn't work correctly!
I'm sure, if you looked hard enough, you could find plans on the net for a weapon of mass distruction. Does that give you the knowledge to change things and it will work? A 300% improvement in the stuff is a sure sign that it's bogus!
Code, as released by BOINC, isn't the best thing for people who don't really understand it, to post to the general public in a "look what I did" thread. The "improvements" you note in the benchmark are a sure sign that it's not working corrctly. Plus, your hack is using code that's not even the "released" client.
In order to be fair, only
)
In order to be fair, only non-Windows (currently) still need optimization (approx. 50% gain needed) to be on par with Win32 BOINC results.
The only reason for this is that the BOINC devs (after 1.5 years) still leaving the Users with normal Benchmark results on the Win32 side, but way too low on the non-Win32 side (which sparked the whole BOINC optimization movement, in order to have fair Scores among Win32 and Linux mainly).
Common other synthetic Benchmarks confirm this.
Aggressive Optimization for Win32-BOINC Clients therefor has no practical use and makes no sense at all, at the default Win32 Benchmarks represent "how it should be", at best for other platforms to live up to after optimizing.
Also, an optimization should never gain more than a few % on the Win32 side, as anything more belongs to speculative, aggressive Optimization (which actually alters the compiled code, e.g. physically disables/corrupts benchmark loop portions).
In short :
300% gain means : "That was one compiler flag too much"
Therefor - apart from cheating or spark old discussion - there is no practical use out of this.