I'm collecting samples and from the looks of this chart, need to collect more samples to try and spot any difference between KWSN_2.4_SSE2_IPP_Ben-Joe 64b optimized app and the stock 32b 5.27 that berkeley issues. The OS is Winxp pro64, 5.10.20 x86-64 is the boinc version. Machine is AMD64 X2 6000, 3% OC, 2G (2x1G) Corsair XMSII ram ddr2 800.

From initial looks there's little to NO difference. If this continues, It looks like Stock would be better, just because it auto upgrades.

This chart shows the "granted credit/hour" across the AR (angle ranges) distribution that exists. More samples of 64b are being collected this weekend.




And yes, I've checked taskmanger to make sure Simon's app was running. LOL

Another look with "mo" samples.

I see at 0.44319 I have two that are darn close, only 0.000021 off from eachother and they seem the same to me. Note: I switched to CC/hour instead of GC/hour as the previous chart shows.



Yesterdays work was one of many in the LOW AR range, so credit/hour was better.

Updated X2 6000, added chart for X2 5200:

Pasting copy of Joes chart so I can find it before it gets lost and I have to ask him again:

Here's the latest. I've set both to NNT/NNW and will switch back to stock when they run out (sometime tonite/tomorrow).

Here's the latest. I've set both to NNT/NNW and will switch back to stock when they run out (sometime tonite/tomorrow).

I'm switching my machines back to stock too. I simply deleted the app_info.xml file and will let them switch over automatically.

But I do want to throw out a big "thank you" to Team Chicken. Without their hard work, we probably wouldn't have these optimizations in the stock app right now. The entire SETI@Home community owes a lot to those guys in the Coop!

---

@ Astro

You took the opt. app for AMD?
EDIT: 64Bit AMD not available

BUT, what's if you let run the 32Bit AMD app?


You compared only app -> Credits..
What's with app -> time?


@ Astro & OzzFan

Why you let run SETI@home, because of the Credits or the science?



BTW.
How it's with Intel CPUs?

---

64-bit SSE2 opt app slower than SSE2 32-bit one on AMD 64 systems.
But 32-bit SSE2 v. 2.4 opt app runs faster than stock app (it's just fastest available version for AMD64) and runs even faster under 64-bit OS than under 32-bit OS (OS=windows ;) ).
So why you compare 64-bit opt app with stock one ???

@ Astro & OzzFan

Why you let run SETI@home, because of the Credits or the science?

If you read my post history or browse the boards, you'll find the answer to that question.

---

OK, I'm done with the 64b KWSN 2.4 SSE2 IPP Ben-Joe data collection. Enough of the last stragglers waiting validation have done so.

I feel safe to say that for the AMD64 X2 5200 and 6000, the opimized app does better at low angle range up to about .38, then from .38 to 1.1 it performs on par with the stock app, but after that (higher than an ar of 1.2) it performs miserably compared to the stock app.

All of this seems to agree with the running of "quick" test wus.

Edit, I know you can't read datapoints, but if you just look at dot positions, you'll see it. It's too wide to fit on any screen in common use today. If you can't make it out, the top is the 5200 the bottom the 6000. The blue dots are 32b 5.27, the pink are 64b opt app.

OK, I'm done with the 64b KWSN 2.4 SSE2 IPP Ben-Joe data collection. Enough of the last stragglers waiting validation have done so.

I feel safe to say that for the AMD64 X2 5200 and 6000, the opimized app does better at low angle range up to about .38, then from .38 to 1.1 it performs on par with the stock app, but after that (higher than an ar of 1.2) it performs miserably compared to the stock app.

Very interesting and some good work there.

Two questions:

1: Why?

2: And with the AR distributions, which is the better to use?


Happy crunchin',
Martin

---

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

OK, I'm done with the 64b KWSN 2.4 SSE2 IPP Ben-Joe data collection. Enough of the last stragglers waiting validation have done so.

I feel safe to say that for the AMD64 X2 5200 and 6000, the opimized app does better at low angle range up to about .38, then from .38 to 1.1 it performs on par with the stock app, but after that (higher than an ar of 1.2) it performs miserably compared to the stock app.

Very interesting and some good work there.

Two questions:

1: Why?

2: And with the AR distributions, which is the better to use?


Happy crunchin',
Martin

If we were still doing Line feed work there's sufficient angle range distribution data to know that optimized would be better overall even on those systems. For Multibeam, it is very difficult to tell; there should be a lot of drift scan survey work with angle range from about 0.34 to 0.45 and basketweave scan survey work with VHAR (Very High Angle Range) above 1.13. But the ALFA receiver is used for other work, too, giving a variety of angle ranges. The recorder has a feature which can shift frequencies when the receiver is "staring" at a single point. The splitters and apps don't yet have code to handle the frequency shift, so I suppose that feature was disabled when the very low angle range work we've seen so far was recorded.

One aspect which needs to be considered is the total crunch time at various angle ranges. The VHAR work still crunches in about 1/4 the time of mid-range work, so each VHAR WU has only 1/4 the effect on RAC. The primary drift scan of the full Arecibo sky being conducted by the ALFALFA project is about half done, and the full coverage GALFACTS basketweave scan has not started yet. It seems possible that there will come a time when there are 4 times as many VHAR WUs as those below angle range 1.1274 for significant periods of time, but overall I think the number of VHAR WUs will remain significantly less than half.

                                                               Joe

Two questions:

1: Why?

because it was there..... Really it was because I'd started with one app (probably stock), then shortly there after figured. Heck, optimized AND (&& in C) 64b....couldn't get any faster for my machine. ...... Theeeeeen... I started looking at "average granted/wu" based upon similar AR (remember I had a small dataset), and saw that 64b was WORSE than stock. At that point I had to find out, and dig a weeeeee bit deeper. I found that both granted and claimed vary to a greater extent based upon AR than did LineFeed. With that, I found that comparing wus of the SAME AR even more important than it was with LF.

2: And with the AR distributions, which is the better to use?

See joes answer. personally after I get a good distribution of stock wus, I'm then going to try the opt app which the quick tests picked for my machine.

I switched the 6000 and 5200 to 32b KWSN_2.4_SSE2_AMD_MB yesterday, and dare I say, "I think there might be some improvement using this app", Well,,,,so far anyway.

Chart x axis is WU AR's sorted by increasing order.

The AR distribution on my PentM for MB units is, see Joe's AR/Flops graphs for points selected.

AR . . . . . . . . . . Qty . . % . . . time/unit(approx)
0.00 to 0.04 . . . 062 . . 15% . . . 2:45
0.04 to 0.23 . . . 007 . . 2% . . .. 2:40
0.23 to 0.34 . . . 004 . . 1% . . .. up to 3:30
0.34 to 0.45 . . . 109 . . 25% . . . 3:00
0.45 to 1.12 . . . 076 . . 18% . . . 2:45
1.12 to 15.4 . . . 167 . . 39% . . . 0.45

435 units.

Data collected using BoincLogX

Andy

Who can do the testing for Intel computers?
Intel p4
Intel PD
Intel Core 2..

Peter Söderlund

---

Here's the current charts for most machines. We can see that the KWSN_SSE2_AMD_MB is working well on all my AMD machines compared to the stock and 64b optimized apps.

can you run chicken 2.4 sse3 64b ipp patched???

---

Strange that you asked. My AMD64 X2 5200 and 6000 have been set to NNW for a day now. Once they're done collecting KWSN 2.4 SSE2 AMD MB data I suspect I'll try "P'ing" a version, starting with the KWSN 2.4 SSE2 AMD MB app, then moving on to others. I picked that version because it can be done to all processors, SSE3 won't work on my 2800 or Mobile 3700. Time will tell what is seen.

The following chart is so early that nothing can be drawn from it, but I find it so curious in trying to understand what's happening. I make every effort to maintain the integrity of my figures. The data around 1.4 is very erratic, and I kept checking to make sure it (and other points) were actually what I'm presenting them as. I'd prefer to find I've made an error and it wasn't erratic. I see some points where the yellow (KWSN 2.4 AMD MB-P, note: the P means "special version") score roughly the same as the KWSN 2.4 AMD MB wus (especially midrange), and where it is regularly faster on the high and low AR's. I find this chart so interesting, because I can't explain it. On the other machines which I've installed my "special version" (denoted by the P on the end) I've been consistently getting .40 and 1.47 wus so no pattern is even starting to emerge yet. I'll posting them all after I get more varied data points plotted (could be many days).