I've just been trying out the sse app, but I have a problem. I always run boinc as an unpriviledged user, and the seti worker terminates immediately when run this way. Seems that the UPX stuff can not handle operating in this way. I'll be working on getting things going after removing the compression. More info soon.

---

I've heard some reports of this happening. Seems UPX really has some issues, but it' to be a problem only on some distributions. Anyway, that's all Linux-related though.

In Windows matters, Intel seems to be enjoying July 4th off (my licenses have not arrived yet), so I guess it'll be another day before there's even a chance of a public release.

I'll keep you posted.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Yay! finally got a clean build... I see what you mean about manually unpacking .cabs now :) Even after I put those headers and libraries into the proper places it still took me forever to get the linker to find it...

Just to figure out what I was doing I basically stuck to the instructions and built an SSE2 app w/o graphics - Here are the results for my HP dv5130us laptop (Turion ML-37 processor, 1GB RAM). The number on the right is the time in seconds since midnight.

New run with default-515 started..
01:33:16 = 5596
02:02:16 = 7336
------------
29 Minutes

New run with setiathome_5.15_windows_intelx86.exe started..
01:18:45 = 4680
01:33:16 = 5596
------------
~15.26 Minutes

Whoa, almost 2x speed increase!!!

Will test with SSE3 later, but I'm quite happy with the results from this one, and I can use SSE2 on at least 2 if not all 3 of my computers... this laptop is the only one I own that supports SSE3

---

Glad you got it to work!
Nice speed increase. I'm still waiting for my Intel licenses..

I'd be interested if SSE3 gives you any sort of difference, because it didn't for me, no matter what platform.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Hi folks,

I think I found a little bug in the sourcecode. If you look at the procedure seti_analyze (in 'analyzeFunc.cpp'), after freeing allocated memory (e.g. ChirpFftPairs) the procedure 'checkpoint()' is called at the very end. Within checkpoint() some of the arrays just freed are referenced. In the worst case this could cost you a completely calculated and correct work unit, as you get aa "Access Violation (0xc0000005)" in stderr.txt. (This does not happen very often, but it can happen).

I just stumbled over this error, as one of my WU's got stuck at 100%, time still counting. After stopping and restarting, it started all over from 0%. (Look here).

I changed the order in seti_analyze, so that checkpoint is called before freeing stuff at the end.

Greetings,
Michael

---

Glad you got it to work!
Nice speed increase. I'm still waiting for my Intel licenses..

I'd be interested if SSE3 gives you any sort of difference, because it didn't for me, no matter what platform.

Regards,
Simon.

I and my Team and a lot of people are waiting too...

btw Good Woork @KWSN - Chicken of Angnor

Greetings from Germany NRW
Ulli

Hi folks,

I think I found a little bug in the sourcecode. If you look at the procedure seti_analyze (in 'analyzeFunc.cpp'), after freeing allocated memory (e.g. ChirpFftPairs) the procedure 'checkpoint()' is called at the very end. Within checkpoint() some of the arrays just freed are referenced. In the worst case this could cost you a completely calculated and correct work unit, as you get aa "Access Violation (0xc0000005)" in stderr.txt. (This does not happen very often, but it can happen).

I just stumbled over this error, as one of my WU's got stuck at 100%, time still counting. After stopping and restarting, it started all over from 0%. (Look here).

I changed the order in seti_analyze, so that checkpoint is called before freeing stuff at the end.

Greetings,
Michael

Good catch! Hasn't happened to me yet - that's not to say it won't or can't :o) Since I can't really code C/C++, such things escape me. I'll change it in my sources, recompile and see what's what.

Ulli, I'm checking my email every 5 minutes...so yeah, I'm waiting too :o) 4th of July is a holiday in the United States, and most businesses probably let their employees take Monday and Tuesday off.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

[quote]Hi folks,

I think I found a little bug in the sourcecode. If you look at the procedure seti_analyze (in 'analyzeFunc.cpp'), after freeing allocated memory (e.g. ChirpFftPairs) the procedure 'checkpoint()' is called at the very end. Within checkpoint() some of the arrays just freed are referenced. In the worst case this could cost you a completely calculated and correct work unit, as you get aa "Access Violation (0xc0000005)" in stderr.txt. (This does not happen very often, but it can happen).

I just stumbled over this error, as one of my WU's got stuck at 100%, time still counting. After stopping and restarting, it started all over from 0%. (Look here).

I changed the order in seti_analyze, so that checkpoint is called before freeing stuff at the end.

Greetings,
Michael

Fingers crossed that all goes well

and Greetings to my Friend Arnold

hope all is going well to my Friend Arnold

Greetings from Germany NRW
Ulli

Hi folks,

I think I found a little bug in the sourcecode. If you look at the procedure seti_analyze (in 'analyzeFunc.cpp'), after freeing allocated memory (e.g. ChirpFftPairs) the procedure 'checkpoint()' is called at the very end. Within checkpoint() some of the arrays just freed are referenced. In the worst case this could cost you a completely calculated and correct work unit, as you get aa "Access Violation (0xc0000005)" in stderr.txt. (This does not happen very often, but it can happen).

I just stumbled over this error, as one of my WU's got stuck at 100%, time still counting. After stopping and restarting, it started all over from 0%. (Look here).

I changed the order in seti_analyze, so that checkpoint is called before freeing stuff at the end.

Greetings,
Michael

You should report this to the developers also. Eric Korpela for sure.

---

Boinc....Boinc....Boinc....Boinc....

the same error I had have too.
you can implicite that ---> if the wu shows 100% stop the client, when you now start the client the WU starts from the beginning again
seti_britta

...New numbers are in... here we go!

Clickable thumb of stats in spreadsheet:

The L/D column indicates whether that WU was crunched by my laptop or desktop.

And id my numbers are to be believed, I show an *AVERAGE* performance increase of 266% !!!!

PS - The time reported back to the project is the actual amount of time spent, as opposed to the amount of credit which is multiplied... correct?

---

Nice numbers! You can't calculate average speedup that way though, that's grossly overinflating it.

Take note that some of the WUs crunched there were noisy ones that get very little credit. Those take ~40-60 seconds using the default cruncher and ~4-6 using an optimized one. So that really inflates your percentages but is not a real-world gain (sure, the percentage looks nice, but it's really just 40 seconds...).

That's not to say the speedup isn't pretty dang impressive :o) Keep up the good work.

In other news, I have finally found out how to build a working 64-Bit Windows executable. Thanks Gecko_R7 for those archives! I will try and compile a selection of helpful stuff from them.

Here's the link that explains how. No wonder my builds kept telling my they could not use AMD64, I was missing the SDK and the updated environment variables.

May even take a hint from Harold Naparst and try to see what combinations of ACML (AMD library package) and IPP yield.

So - seems to bode well for the Windows versions. There are some optimizations that only work on 64-Bit and should provide a little extra speed.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Nice numbers! You can't calculate average speedup that way though, that's grossly overinflating it.

Bah! Buzzkill! Okay, I agree... when I added some more WUs and removed the noisy ones from the stats I get about an 87% overall increase over the average user... on some WUs my app is actually slower than the other users, but never by more than 15% or so, and the whole quorum isn't in yet, so its entirely possible that I am comparing myself to other optimized users as well... (Sidenote: Just for kicks I broke out the stats figure for my laptop and desktop seperately - my Turion64 ML-37 laptop on 32bit Windows gets a 90% increase, where my Sempron64 2800+ running XPx64 gets 86.5%...)

In regards to SSE3 - for some reason I can't make it work... Everything builds okay, but when I throw the app into the benchmark/verify tool it terminates in a second or two if not immediately... no errors that I could find either...

I also see why a lot of people say that SSE3 has no real speed increase for them - Reading your link to the article on IPP/ACML integration shows that most functions in IPP don't yet have SSE3 code, and therefore revert to SSE2. Although I am very intrigued by the idea of overlapping ACML with IPP (as well as the 64bit code) - my two fastest boxes are AMD's (Turion64 and Sempron64), both of which have 64bit OSes installed (only the Sempron runs it regularly) so the added speed bonus of using the non-sabotaged library whenever possible would be very welcome - I look forward to seeing more info on these combinations in the future! (Perhaps I should pay my pal to bring you a few clams... I seem to be enjoying your work quite a bit and still pushing for more :P )

---

Lol :o) sorry to be a buzzkiller...

Yeah, it intrigued me to read about Harold Naparst's ventures and methods (which is where the mixed FFTW/ACML/IPP libs came from as an idea). Gecko_R7 was nice enough to make a PDF collection available to me with archives of a lot of old threads concerning optimization. Thanks again, Gecko! Very useful info there.

SSE3 seems to be a problem - the compiler switch /QxP on Windows or -xP on Linux is specifically only made for Intel chips. It does check whether your CPU is AMD (same as /QxN & /QxB or -xN & -xB). However, xW and xK work just fine on AMD chips - if you just want generic SSE3, you will have to remove /QxP and just define USE_SSE3 in the preprocessor flags. No idea whether SSE3 help in any regard - it does on some more recent Intel chips (P-D for example), but only makes a very small difference.

A 2x increase is what I have seen with most chips, be they AMD or Intel. (I.e. a speedup of ~100% +-15% depening on platform). YMMV.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Hi folks,

I think I found a little bug in the sourcecode. If you look at the procedure seti_analyze (in 'analyzeFunc.cpp'), after freeing allocated memory (e.g. ChirpFftPairs) the procedure 'checkpoint()' is called at the very end. Within checkpoint() some of the arrays just freed are referenced. In the worst case this could cost you a completely calculated and correct work unit, as you get aa "Access Violation (0xc0000005)" in stderr.txt. (This does not happen very often, but it can happen).

You should report this to the developers also. Eric Korpela for sure.

Consider it reported. Fix will be checked in today. Thanks,

Eric

---

@SETIEric@qoto.org (Mastodon)

Thanks Eric!

I'll update my CVS sources and incorporate those changes into my clients (that specific change should carry over to 5.15, AFAICS, right?).

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

I'm going mad trying to compile anything. I've followed the instructions and keep getting error message after error message.

Anyone know what this means?

seti_boinc Command line error D2016 : '/GL' and '/YX..\\StdAfx.h' command-line options are incompatible


Thanks in Advance :-)

---

I'm going mad trying to compile anything. I've followed the instructions and keep getting error message after error message.

Anyone know what this means?

seti_boinc Command line error D2016 : '/GL' and '/YX..\\StdAfx.h' command-line options are incompatible

Thanks in Advance :-)

Linux or Windows? Might be nessicary info for those who can help you.

It does check whether your CPU is AMD

I should have thought of that... Damn Intel and their proprietary crap... They could have at least returned a message of some kind to the command line...

Talking to a couple people about this, someone mentioned that there are add-in PCI cards that serve as hardware FFT co-processors... I havn't had a chance to research them yet, but if theyre reasonably priced and a library could be written to interface with it (think replacement to IPP calls) I imagine that could *really* kick the SETI app into overdrive... I'll research them a bit when I get home tonight and let y'all know what I find...

-Chris

P.S. - Any luck with those Intel licenses yet? I know us yanks like to take our 4th holidays, but this is starting to get a bit unreasonable...

Edit: WHOA! Take a look at this!
http://hardware.slashdot.org/article.pl?sid=06/05/29/1424213
http://gamma.cs.unc.edu/GPUFFTW/
and http://www.cs.unm.edu/~kmorel/documents/fftgpu/fftgpu.pdf (Skip to 'Implementation' unless you're really hardcore or just curious...

---

Talking to a couple people about this, someone mentioned that there are add-in PCI cards that serve as hardware FFT co-processors... I havn't had a chance to research them yet, but if theyre reasonably priced and a library could be written to interface with it (think replacement to IPP calls) I imagine that could *really* kick the SETI app into overdrive... I'll research them a bit when I get home tonight and let y'all know what I find...

-Chris

Whilst your at it you might like to lookup 'ClearSpeed'. Don't know about reasonably price though. Didn't see anywhere you could buy them when was researching.