> Could you please outline to procedure you followed to "install" the new
> seti_boinc client once compiled.
> Secondly, can you please explain where you find the test unit and how you run
> it. I've not read anything on this at all and it would be very useful for
> checking the validity of the compiled client with different compile time
> optimisations.

I haven't installed it.
In your newly compiled client directory (for me: /usr/src/seti_boinc/client/) you will find a directory called "test_workunits". This directory contains a file called "reference_work_unit.sah" which as I understand it is the SSL-approved test WU.
I have created a new empty directory, and copied "reference_work_unit.sah" to this directory, renamed to "work_unit.sah".
Into the same directory copy your newly compiled client and execute it.
If all is well it will run.
When the run completes you will have a new set of files - "state.sah", "stderr.txt", etc.etc. but if it ran clean the most important one will be "result.sah".
I've run mine and saved the directory contents elsewhere.
The next stage is to copy a vanilla seti client into the test directory, again with the supplied test WU, and execute it. I'm doing this now. Currently 57% complete but I need to go out now so will not be able to review until this evening (GMT). At this point, SSL will like as not be down ;) so I'll post up my results on http://forums.teamphoenixrising.net - in the thread you've already seen. Might even knock myself out, go to your forums and drop you a line there - but don't tell anyone I've been consorting with the "enemy" :)

Anyhoo, if all is well IMHO the client will (a) execute cleanly (b) leave an empty "stderr.txt", and (c) produce an identical "result.sah" (in science terms).
Once I'm happy the scientific data is the same I can compare runtimes as the execution time is stored in "result.sah" (well I hope it's stored somewhere in one of the files).
If you were going to do this for optimisation validation, then as long as you save the output on the test workunit from a vanilla download client you will always have a "correct" answer to work on.
To actually install when I'm happy with it, I plan to follow the supplied "anonymous" instructions.
>
> Finally, what optimisations did you use to compile the seti_boinc client and
> could you please give us some before and after WU processing times please.
>
I used the same optimisations you suggested when compiling the common client but will try others once the basic validation is complete. I don't know which are likely candidates so it's going to be a bit trial & error as I don't read C source very well - any ideas for a good start point Ned?
>
> A lot to ask, I know :)
>
No worries, one good turn & all that....

> > I hope you don't mind, but I've dropped a link and acknowledgement in
> our
> > team's forums at
> > http://forums.teamphoenixrising.net/showthread.php?p=232907#post232907
>
> Just dropped by and read your post - thanks :)
>
> You might like to mention to your folks that the compiled client is now
> available linked for download from my guide as a 2.6MB gzipped file. In the
> GNU spirit I like to share.
>
> Also, if folks want me to compile versions for other processors (i686 for
> example), I'd be happy to in exchange for some feedback on benchmark scores
> :)
>
> Ned
>
Done - don't blame me if you get 1000 mails asking for clients :)
>
>

:(

No joy, a small number of significant differences in the results.
I have asked follow up questions here:

http://setiweb.ssl.berkeley.edu/forum_thread.php?id=5176

> I used the same optimisations you suggested when compiling the common client
> but will try others once the basic validation is complete. I don't know which
> are likely candidates so it's going to be a bit trial & error as I don't
> read C source very well - any ideas for a good start point Ned?
> >

OK, first try dropping the -ffast-math optimisation. This is known to produce results that don't always conform to all standards. I only included it in the boinc_client because the boinc_client doesn't actually do any maths (science) for the project but it significantly speeds up the benchmark. I expect it will also significantly speed up the seti client but if it's not giving usable results there is no point it being there. Sorry, I should have said not to include this in the first place! All of the rest of the optimisations I used _should be_ valid though.

Some times would be interesting though nevertheless.

I'll call by your place later tonight and see if your're home ;)

thanks

Ned (The Enemy) LOL

New version testing now.....

Results from the recompile are correct to a minimum of 4 decimal places or 1/100% - which I believe is within the bounds allowable.

XP2200+ Fedora Core 2 Latest updates Kernel 2.6
Source compiled from 04/10/2004

Setiathome 4.02 test unit runtime - 4 hrs 59 minutes
Self-compiled version test unit runtime - 4 hrs 44 minutes

= 5% quicker :)

I'm sure we can do better by playing about with optimisations in the compiler

I compiled linux client as described in the howto and it all worked well, client has times more relistic to how long it takes to complete a work-unit. The problem is the new compiled client now access the disk far more than the client downloaded from seti site. This is a major problem for me as I run 4 pc's on a diskless network. The ammount of network traffic the new compiled clients create almost brings the network to a stand still. If i use the client from the seti site there is almost no network traffic, just the write to disk every 120 seconds.

Hope you understand what I mean, not sure how to fix this problem

Hi!

Has anybody tried with Intel compiler? It might produce slightly
faster code.

BR, 73

Iztok

> Hi!
>
> Has anybody tried with Intel compiler? It might produce slightly
> faster code.
>
> BR, 73
>
> Iztok
>
>

Yes, taken from this thread:

http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1212

Ned

Quote:

> It would
> be interesting to compile the client from source using the Intel C++ Compiler
> for Linux to see what kind of benchmarks it gets.

An initial result: the CVS snapshot boinc-cvs-2004-07-10.tar.gz compiles with ICC after one correction, but the resulting program crashes with SIGSEGV. That makes the version compiled with GCC infinetly faster :-)

Bump.

An optimised client for boinc version 4.12 is now available linked from my guide for download. Benchmark times are similar to that for the optimised boinc 4.11 client. I'm currently testing it on one box and looks OK so far. I'll report any problems.

The guide can be found here:

http://forums.pcper.com/showthread.php?t=349185

Regards,

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

> An optimised client for boinc version 4.12 is now available linked from my
> guide for download. Benchmark times are similar to that for the optimised
> boinc 4.11 client. I'm currently testing it on one box and looks OK so far.
> I'll report any problems.

I'm afraid to tell you that optimizing the BOINC core client alone doesn't make any difference at all (except from the dhry- and whetstone numbers changing). To get any actual speed-increase you have to optimize the application (seti or whatever) as well - as someone rightfully mentioned earlier in this thread.
So using the right optimization flags is important, yes, but it will only give you at most 10-20 percent increase in actual speed. Using profiling and brancing analysis as well you can almost double the troughput compared to the original application without changing the result at all (I'm basing my numbers on tests made back during betatesting of the application).

Whenever you optimize you should optimize both the CC and the application to about the same level so that it can still calculate your credit correctly. If you fail to do so you will get less credit than you should (if that is of a concern to you).

Does anybody have a self-comiled windows version. If it is realy faster, then it's more producktive.

---

WARR - Wissenschaftliche Arbeitsgemeinschaft für Raketentechnik und Raumfahrt
(WARR - scientific working group for rocket technology and space travel)

> > An optimised client for boinc version 4.12 is now available linked from
> my
> > guide for download. Benchmark times are similar to that for the
> optimised
> > boinc 4.11 client. I'm currently testing it on one box and looks OK so
> far.
> > I'll report any problems.
>
> I'm afraid to tell you that optimizing the BOINC core client alone doesn't
> make any difference at all (except from the dhry- and whetstone numbers
> changing). To get any actual speed-increase you have to optimize the
> application (seti or whatever) as well - as someone rightfully mentioned
> earlier in this thread.
> So using the right optimization flags is important, yes, but it will only give
> you at most 10-20 percent increase in actual speed. Using profiling and
> brancing analysis as well you can almost double the troughput compared to the
> original application without changing the result at all (I'm basing my numbers
> on tests made back during betatesting of the application).
>
> Whenever you optimize you should optimize both the CC and the application to
> about the same level so that it can still calculate your credit correctly. If
> you fail to do so you will get less credit than you should (if that is of a
> concern to you).
>

Credit is calculated as a product of CPU time (Seti client) x benchmark score (Boinc client). By optimising the boinc client you significantly improve your benchmark score which has two implications. Firstly, it allows boinc to more accurately predict the amount of work to download, and secondly, it significantly increases the requested credit for a completed unit, more in keeping with that requested by the Windows client. For example, in my case the requested credit went from 27.5 to 40 for a typical unit. This is far more in keeping with what is requested by the windows client running on the same hardware and can dramatically affect the awarded credit given to yourself, as well as the other two users who also processed that unit.

If we do not optimise the linux boinc client, we are dragging down other (windows) users awarded credit by requesting far lower credit than they might be for a given unit. I'm sure this is important to some so my optimised linux boinc client is provided on this basis.

See my post on observations on requested and awarded credit.

With regards to otimising the SETI client - this has absolutely no impact on requested or awarded credit because requested credit is directly proportional to CPU time spent on a unit. So optimising the seti client to process faster simply means you will request less credit per unit, although you will process more of them. Of course, presumably this will help the seti effort by processing more units (by processing them faster), but it does not affect credit.

Edit: I'll expand on that last bit a little as it's a little ambiguous. If you optimised the SETI client to process faster, you would acutally request (and likely be awarded) LESS credit because credit requested is directly proportional to the processing time for the unit. Overall, your AVERAGE credit would be balanced out bacause you'd be processing more units, but requesting less credit for each unit.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

> Does anybody have a self-comiled windows version. If it is realy faster, then
> it's more producktive.
>
>


We are taking about the BOINC client here, NOT the SETI client that does the science. Please don't confuse the two.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

>I'll expand on that last bit a little as it's a little
>ambiguous. If you optimised the SETI client to process
>faster, you would acutally request (and likely be awarded)
>LESS credit because credit requested is directly
>proportional to the processing time for the unit.
>Overall, your AVERAGE credit would be balanced out
>bacause you'd be processing more units, but requesting
>less credit for each unit.

You would request a little less but be granted the same as the windows people if they are the majority (as they are...).
Producing more results will give you more credit in the end.

Remember the validator? It throws away bottom- and topmost requests and grants the average of the rest.

If I was you I would work on optimizing the seti application (the worker) instead of the coreclient (the manager) and ask the devs to balance the linux benchmarks compared to the windows ones.

> >I'll expand on that last bit a little as it's a little
> >ambiguous. If you optimised the SETI client to process
> >faster, you would acutally request (and likely be awarded)
> >LESS credit because credit requested is directly
> >proportional to the processing time for the unit.
> >Overall, your AVERAGE credit would be balanced out
> >bacause you'd be processing more units, but requesting
> >less credit for each unit.
>
> You would request a little less but be granted the same as the windows people
> if they are the majority (as they are...).
> Producing more results will give you more credit in the end.
>
> Remember the validator? It throws away bottom- and topmost requests and grants
> the average of the rest.
>
> If I was you I would work on optimizing the seti application (the worker)
> instead of the coreclient (the manager) and ask the devs to balance the linux
> benchmarks compared to the windows ones.
>

Yes, you are correct in what you say. But do remember that you are discarding the bottom and top results of normally only 3, so the average of the rest is simply the middle result returned. If a unit goes to 2 windows boxes this will be high, if it goes to 2 linux boxes it will be low. By optimising the boinc client we can easily lessen this differential significantly.

We are currently working on optimising the seti client and are in the process of testing atm. We have been waiting for the current upload problems to be resolved before we thoroughly test so we may properly validate our results. However, initial results indicate that only relatively small gains are to be had by optimising the seti client relative to the gains in the boinc benchmark scores. This is probably to be expected though, as I believe (I don't have the data to hand) the linux seti client is only 10-20% slower than the windows client anyway (whereas the boinc benchmark scores are more like 50-80% lower). A large part of that is due to the fact that various maths compiler optimisations that could be used when compiling the boinc client can't be used when compiling the seti client as they produce invalid results. This issue is currently further complicated by the fact that two different versions of the seti client are currently in use on the windows and linux platforms. The newer windows client (4.05) is now significantly slower than the older linux client (4.02) as well as the older windows client (4.03). This effectively makes it impossible to use the (current) windows client as a baseline for comparison.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

Here's a nice little example of what I'm talking about:

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=2655107

We have a work unit sent to 3 users, a linux user using the non-optimised boinc client, a Windows user, and myself using the optimised boinc client.

Credit was requested as follows:

Linux user: 11.25
Windows user: 63.29
Optimised Linux user (me): 34.70

The top and bottom results are discarded so the granted credit will be my result being the middle of the three, 34.70. This is almost half what the windows user requested and 3 times more than the native linux user requested. If I had been using a non-optimised boinc client on my linux box, then the awarded credit would have actually been far less (about 20). The disparity is huge.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

It's nice to see that we agree - optimizing the core client does not make any significant changes except in the one case you mention, and does not contribute any more or less to the science done.

Also a further note: at some point the benchmarking system will be changed to be more balanced (perhaps it will even move into the application instead of the core client). The current linux vs. windows situation is not going to last.

One of the reason why the code was made open was exactly that people can now freely optimize the applications to run faster. The validator will check the results so that the integrity of the science is not put at risk. So I can only wish you good luck with optimizing the application =)

(I still use the terms "core client" and "application" - what I reffer to is "the manager (BOINC)" and "the worker (seti@home)".)

Do any of y'all know what the trick is to get boinc to compile statically linked instead of dynamically? I've been searching for an hour for this on various forums and how-tos. I know where to download precompiled statically linked boinc clients but nowhere can I find how to compile them statically.

See, I can download and run the statically linked binaries that Ned Slider compiled with gcc 3.4 on various machines that only have gcc 3.3 installed and they work fine. But I have some machines that he doesn't have optimized binaries compiled for and was gonna compile 'em my self - old pentium and pentium-mmx boxes, basically.

I compiled a client with shared libraries on a Linux box with gcc 3.4 that works but it only works on machines that I upgrade to gcc-3.4 and I don't want to upgrade gcc on the other machines that I want to run an optimized pentium or pentium-mmx boinc client on.

I also read somewhere that there may be some DNS resolver issues linking glibc statically? What's that about?

Thanks -

Chuck Bell

---

 We Listen and Compute!
            |/
         ( q p )
------oOOo-(_)-oOOo-------
http://www.dianetics.org

> Do any of y'all know what the trick is to get boinc to compile statically
> linked instead of dynamically?

Way to dig up an old topic :)

Can't sleep so I did a little searching on how to statically compile things, as personally all i've statically compiled is busybox and that will do it for you.

http://www.google.com/search?hl=en&q=gcc+statically+compiled&spell=1
"This is the equivalent to make LDFLAGS=-static as we
use with other packages to compile them statically."

This also mentions stuff
http://vergil.chemistry.gatech.edu/resources/programming/c-tutorial/libraries.html

---