Im using the optimized and I get A LOT more credit pero WU, but didn't see better performance, maybe I selected the wrong processor, but I'm not sure which one I have (The PC that I built) It's and AuthenticAMD AMD Athlon (not XP or anything) so.. which one should I choose to download ?? (http://www.pperry.f2s.com/downloads.htm)

Thanks!

---

> >
> > ... and if I'm not mistaken, BOINC 4.2x does a better job on Windows
> hosts
> > because the benchmark doesn't get "optimized" by Visual C++.
> >
>
> Hmmm. I guess throwing away useless bits of code is a vital feature for a
> compiler that is used by Microsoft itself :o)

There are lots of different "bits" to optimizing -- it isn't always throwing out useless bits, it's moving variables to registers, or making minor changes to the instruction sequence to avoid pipeline stalls, or a whole bunch of other things that escape me at the moment.

... and it can be removing bits of code that don't add to the final result.

Benchmarks tend to have code that never participates in the result.

---

Hi.

I have recently installed P4, P3, and AMD versions of optimized clients. All showed much higher benchmark scores. I take it there will be optimized versions of the upcoming clients that will work with "boingmgr?"

Keep up the good work.

JavaPersona

---

>
> There are lots of different "bits" to optimizing -- it isn't always throwing
> out useless bits, it's moving variables to registers, or making minor changes
> to the instruction sequence to avoid pipeline stalls, or a whole bunch of
> other things that escape me at the moment.
>
> ... and it can be removing bits of code that don't add to the final result.
>
> Benchmarks tend to have code that never participates in the result.
>

Right.

The smileys in my posts indicate when I'm not completely serious while posting....

Regards Hans


P.S:

Yep, I'm not very serious most of the time :o)

---

[...]
> Our current work is aimed at optimizing the seti client - something that's
> intended to assist in the science as it will allow users to process work units
> faster, thus allowing more "science" to be performed in a given timeframe.
[...]

Ned,

I downloaded your
AthlonXP 4.19 client and got only the one boinc client file in the tar.bz2 file.

Should there not also be an optimised s@h client to run under boinc?

Also, I'm getting:
"No work sent (there was work but your computer doesn't have enough memory)" even though there's over 512MB free RAM on this linux system... Any ideas?

Meanwhile, CPDN is running fine under your 4.19 boinc client (:-O)


Help?
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Sorry, not seen that error message before. What distro are you running?

ATM, I only have the boinc clients available. We have been having problems getting the seti app to compile statically. According to Eric, it's a problem in the way g++ applies the -static flag and he's working on a solution. This confirms what we see - the seti app compiles dynamically, despite being sent -static flags.

I have a working optimized seti app for Fedora Core 3 (32 bit) and Chris Bosshard has a working app for FC3 x86_64.

So, for the moment, if you're running FC3, you can contact us here for a copy of the optimized seti app for FC3:

[url=http://forums.pcper.com/showthread.php?p=3426565
]http://forums.pcper.com/showthread.php?p=3426565
[/url]

Ned

---

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

> "No work sent (there was work but your computer doesn't have enough memory)"
> even though there's over 512MB free RAM on this linux system... Any ideas?

This problem cropped up on the Einstein forum a little while ago. I know what the problem is but, unfortunately, not the solution. :( What it boils down to is that your computer is not reporting the installed memory with the method used by the BOINC client. Bruce Allen created the following little test program (essentially extracted from the BOINC source):

------------------------------
Copyright Bruce Allen 2005
Released under GPL2
Program to print out physical memory on a system.

[1] Put all of this into a file called memory.c

[2] Compile it like this:
gcc -o memory memory.c

[3] Run it like this:
./memory
*/

#include [unistd.h]
#include [stdio.h]

int main(int argc, char **argv) {

long pagesize=sysconf(_SC_PAGESIZE);
long pages =sysconf(_SC_PHYS_PAGES);

printf("size = %d number = %d bytes=%.0fn", pagesize, pages,
((double)pagesize)*((double)pages));

return 0;
}
---------------------

Due to limitations of the forum software, I had to replace the angle brackets in the #include statements with square brackets. If you wish to use the code, change them back to angle brackets.

---

Be lucky

Neil

> Should there not also be an optimised s@h client to run under boinc?

Ned has explained the static/dynamic linking problem. I will just add that the seti-boinc client is simple enough to compile using the basic instructions on Ned's site. The only gotcha is that many of the CVS snapshots fail to compile due to errors. I have found that the source in seti_boinc-client-cvs-2005-03-16.tar.gz compiles without issue.

Compiling the above-mentioned source code with the following flag settings:

CFLAGS="-march=athlon-xp -O3 -fomit-frame-pointer -ffast-math -fforce-addr -ftracer"
CXXFLAGS=$CFLAGS

resulted in the average time to complete a SETI WU dropping from c11,700 secs to c9,700 secs on this machine. This is on a system running Gentoo GNU/Linux with GCC 3.4.3.

Contrary to original expectations, -ffast-math appears to produce perfectly valid results - as, I believe, Ned and Chris can confirm.

---

Be lucky

Neil

> > Should there not also be an optimised s@h client to run under boinc?
>
> Ned has explained the static/dynamic linking problem. I will just add that the
> seti-boinc client is simple enough to compile using the basic instructions on
> Ned's site. The only gotcha is that many of the CVS snapshots fail to compile
> due to errors. I have found that the source in
> seti_boinc-client-cvs-2005-03-16.tar.gz compiles without issue.
>

^^ Thanks Neil - good to know. I've been using the seti source from 1st Dec 2004.


> Compiling the above-mentioned source code with the following flag settings:
>
> CFLAGS="-march=athlon-xp -O3 -fomit-frame-pointer -ffast-math -fforce-addr
> -ftracer"
> CXXFLAGS=$CFLAGS
>
> resulted in the average time to complete a SETI WU dropping from c11,700 secs
> to c9,700 secs on this machine. This is on a system running Gentoo GNU/Linux
> with GCC 3.4.3.
>
> Contrary to original expectations, -ffast-math appears to produce perfectly
> valid results - as, I believe, Ned and Chris can confirm.
>

Yes, it appears to be that way atm (although I'd like to do more testing). I now have about 5,000 credits validated using -ffast-math on my test machine. I'm continuing to watch for results that fail to validate. I do currently have 4 results pending that have yet to reach concensus, but obviously have no way of knowing if that's due to my result or one (or more) of the others.

Ned

---

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

Here's the copy-n-paste version (Just in case)

#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv) {

   long pagesize = sysconf(_SC_PAGESIZE);
   long pages    = sysconf(_SC_PHYS_PAGES); 

   printf(&quot;size = %d number = %d bytes=%.0fn&quot;,
      pagesize,pages,((double)pagesize)*((double)pages));

   return 0;
}

Please accredit Bruce Allen accordingly.

---

> ^^ Thanks Neil - good to know. I've been using the seti source from 1st Dec
> 2004.

I just tried the latest - 1st April. I can confirm that that one also compiles cleanly and is now running here. :)

Oh, and perhaps I should mention that I re-named the generated files to setiathome_4.07_i686-pc-linux-gnu and setiathome_4.07_i686-pclinux-gnu.so and, after editing the client_state.xml file accordingly, it picked up without a hiccough. :))

---

Be lucky

Neil

Ned : Yeah, I have also noticed some of the 'concensus not reached yet' results in my queue and I think its pretty normal. I have even noticed one result with that status, and that WU was finished by other 3 people, but not by me, so it can't be caused by me :)

---

Also, I have found some nice parameters for ./configure script. The --disable-server is well known, it build only the client. But also try the --disable-gui and --disable-dynamic-graphics . It cuts compile time a little, and when these flags are in use, then no setiathome_4.07_i686-pclinux-gnu.so is created. Also I dont know if there is a gui for setiathome in Linux, and even if it was, I wouldn't use it :)

Cheers, WerK

I was interested in the claims for GCC 4.0.0 - in particular, the claims for better optimisation. ;) So, I tried compiling seti_boinc with GCC 4.0.0. I'm afraid the code is going to need a lot of cleaning up to compile with that. :(

---

Be lucky

Neil

Who's - SETI or GCC?

---

> Who's - SETI or GCC?

SETI - but, maybe, a little of GCC too. ;)

---

Be lucky

Neil

> Who's - SETI or GCC?
>

I guess that gcc. Because gcc-4.0 is very very beta version now, only a few things dont break with it

> I was interested in the claims for GCC 4.0.0 - in particular, the claims for
> better optimisation. ;) So, I tried compiling seti_boinc with GCC 4.0.0. I'm
> afraid the code is going to need a lot of cleaning up to compile with that.
> :(
>
>

Hi, I compiled an older seti version with gcc4.0, and the generated client was
slower than the gcc3.4 version.

Regards Hans

---

> > "No work sent (there was work but your computer doesn't have enough
> memory)"
> > even though there's over 512MB free RAM on this linux system... Any
> ideas?
>
> This problem cropped up on the Einstein forum a little while ago. I know what
> the problem is but, unfortunately, not the solution. :( What it boils down to
> is that your computer is not reporting the installed memory with the method
> used by the BOINC client. [...]

Thanks for the note.

This is on Mandrake 10.1 on a machine with 1280MB of RAM. It could be just a silly integer overflow in the page count (:-((

As an experiment, I've set my Boinc preferences for 100% virtual memory usage to see if that might be a workaround...

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

> > Compiling the above-mentioned source code with the following flag
> settings:
> >
> > CFLAGS="-march=athlon-xp -O3 -fomit-frame-pointer -ffast-math
> -fforce-addr
> > -ftracer"
> > CXXFLAGS=$CFLAGS
> >
> > resulted in the average time to complete a SETI WU dropping from c11,700
> secs
> > to c9,700 secs on this machine. This is on a system running Gentoo
> GNU/Linux
> > with GCC 3.4.3.
> >
> > Contrary to original expectations, -ffast-math appears to produce
> perfectly
> > valid results - as, I believe, Ned and Chris can confirm.
>
> Yes, it appears to be that way atm (although I'd like to do more testing). I
> now have about 5,000 credits validated using -ffast-math on my test machine.


The "fast-math" is fast because underflow and overflow errors are not checked. This is fine for well behaved maths (:-))

The fastest general 'scientific' useage flag settings I've found for gcc3 so far are:

(AthlonXP Palomino core)

export MACHTYPE="i686-mandrake-linux-gnu"
export HOSTTYPE="i686"
export CHOST="i686-pc-linux-gnu"

export CFLAGS="-march=athlon-4 -O3 -funroll-loops -mfpmath=sse -minline-all-stringops -falign-functions=4 -frerun-cse-after-loop -frerun-loop-opt -m3dnow -malign-double -mfancy-math-387 -mfp-ret-in-387 -pipe -fschedule-insns2 -fexpensive-optimizations"
export CXXFLAGS="$CFLAGS"

- As tested on 'testbench'.

A further speedup will be gained with adding "-ffast-math" if appropriate.

Another worthwhile optimisation to try instead of that lot is to just simply optimise for smallest code size.

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)