A quick question please!

The announcement of the new release of Chicken's optimised Seti clients can be found here.

What is the consensus on how much faster these new optimised client releases are when compared to the previous Chicken optimised clients?

Would any user make a guess as to likely percentage increase that might be found on older Intel kit, with MMX and SSE as well as MMX, SSE and SSE2?

---

It's good to be back amongst friends and colleagues

Don't know yet about the MMX app, but I'm going to try it out on one of my K6-2's as soon as it finishes it's current result.

May be awhile to get really meaningful data though. ;-)

Alinator

I have converted two Pentium D 820's in the last 2 days. They ran a 62 credit unit in about 13,000 sec before the conversion. Now they are usually about 10,400. About a 20% improvement. I just converted two old SSE this AM and will be days before any meaningful data is available (very slow machines)

---

I've been using it for a couple days now. Improvement varies on the angle range but a rough estimate on the SSE2 version on AMD X2's is that it appears to be 20-25% quicker than the previous version. Well done to Chicken and his flock...!!!

Just added the Chicken's new SSE App on an old machine. I was getting killing performance with his old SSE App. Looking forward to seeing what this new one can do :)

---

D.

Just added the Chicken's new SSE App on an old machine. I was getting killing performance with his old SSE App. Looking forward to seeing what this new one can do :)

I just compared a WU that was processed by the previous optimization with one processed by the newest optimization:

Angle Range: 0.426465 0.426463
CPU Time: 12505.5625 9645.640625
FLOPS: 16,092,734,980,121.404000 16,092,476,379,877

This looks like a 23% reduction in CPU Time.

[edit]This is for my D830 system.[/edit]

---

Regarding machines with SSE only...It seems to be slower on Pentium III machines but faster on Athlon XP machines.

Most curious.

Regarding machines with SSE only...It seems to be slower on Pentium III machines but faster on Athlon XP machines.

Most curious.

This is due to a limitation in the Pentium III design.

The first CPU to support SSE, the Pentium III, shared execution resources between SSE and the FPU. While a compiled application can interleave FPU and SSE instructions side-by-side, the Pentium III will not issue a FPU and a SSE instruction in the same clock-cycle. This limitation reduces the effectiveness of pipelining, but the separate XMM registers do allow SIMD and scalar floating point operations to be mixed without the performance hit from explicit MMX/floating point mode switching.

The Athlon XPs had separate SSE and FPU resources, allowing them to be issued side-by-side through pipelining. Thus, Athlon XPs are much faster at SSE code than Intel's own (and first processor to support SSE) Pentium III. I guess Intel simply assumed programmers would use one or the other, not both.

Note that this design limitation was resolved in the Pentium 4, as the P4 had separate resources for SSE/SSE2 and the FPU, which allowed it to be as fast as an Athlon XP when executing instructions. Future processors after the P4 also have separate resources as well.

---

There is another thread on this. Simon mentions with which processors the supersedure will outdo the superseded. In my case, PD950s, he said the overall improvement will be just slight, and that's what it looks like to me. But with some other processors the improvement will be significant. It's best to read that other thread. In my case it does the 0.4-AR-type (60-65-credit) a little better and the VLARS much better than the previous issue but falls a little (~10%) short on the 25-30-credit (0.6 to 1.12 degree angle range). I also think it's a little slower with the 12-to-20-credit (half-hour) units.

---

Regarding machines with SSE only...It seems to be slower on Pentium III machines but faster on Athlon XP machines.

Most curious.

This is due to a limitation in the Pentium III design...

Thanks OzzFan for that explanation. Sounds like you hit it. I was wondering why that wu-times were going up on my P III's with the Rev.2.0 app. My first thoughts were around different chipsets or different handling of that slowish SD-RAM on that hosts (i815=>+15%, via=>+20-25% wu-time). But that would have been contrary to the behaviour this two had shown with Rev.1.3 app before.
I will change back to the Rev.1.3 till the new app is revised for the Pentium III.

---

_\|/_
U r s

For my small P4 Dell, I'm running the new Chicken soup, SSE3 version, and it dropped my crunch times on fairly close AR's about 2500-3000 seconds. I say thats pretty darn good so far.

---

Thanks for sharing!

From Chicken's comments in the next thread, it looks like I should invest in these new clients on all my rigs (old, and not so old)

It did hit-me-between-the-eyes as the thread immediately under tis one ... titled "Simon's new cruncher and Boinc 5.4.9". No need to point me to it now! Thanks

---

It's good to be back amongst friends and colleagues

Using Simons 2.0 generic SSE2 for my AMD64 3700 and AMD64 X2 4800 I've seen decent results. So far I've done 12 with the X2 and only 3 with the 3700. I've input them into my cross project comparison and this new app places Seti once again in the lead for "granted credit/hour" of runtime. So, Einstein is no longer the credit leader when it comes to users who use the standard BOINC client. I'll report back after more are done/validated.

As you can see the reg set app gets about 85% of calculated claimed credit, but the 2.0 gets nearly double what the original app gets.

I've been running these ver. 2 clients for few days and improvement is noticeable.
PentiumM 1.73 ~ 20min acceleration,
Celeron 3.06 ~ 30min,
Pentium4 3.5 ~ 60min.
All above results are for 62claimed credits. The smaller claimed credit, the smaller acceleration in my case.
Looking forward to seeing ver. 2 for Linux.

As you can see the reg set app gets about 85% of calculated claimed credit, but the 2.0 gets nearly double what the original app gets.

Astro, Nice comparison.

I am using iccpatched applications for my A64 3500 and 4400+, they are 10 and 25% faster than their corresponding Einstein@athome applications.

In your post, for the 3700, the Seti speed is the same as E@H and for the 4800, the Seti speed is 10% faster than E@H.

Does it mean the patched application is faster than generic applicaiton?

Chicken and other optimisers, very nice job. I am moving my AMD computers from E@H to Seti to take advantage of the faster clients because they are more efficient now.

---

Hi HDL, As I mentioned in the first post. The "Sample" rate was LOW (only 3 wus were used for the 3700), so it's not really definitive at the moment. I could have gotten all Hi AR or Low AR wus and this would throw off the numbers. I'll report back more when I build a decent sample size.

thanks

tony

[Correction:] The 85% in the previous post should have been 78%, and instead of saying "nearly doubled", I might have used "just over double"[/correction]

[edit]Also, as you know the benchmarks are re-run every 5 days, so small differences in the benchmark can explain upwards of a 5% deviation in the column "granted credit as % of benchmark", so anything from 95%-105% can be seen as equal to the calculated benchmark claimed credit.[/edit]

---

A stup*d question perhaps but wont we need a new v5.17 app for the new 5.17 WUs ?

There's no such thing as a stupid question.

The WUs currently being released are all "Enhanced" WUs and any program that will process "Enhanced" WUs will process these.

Where some folks get into trouble is not realizing that when the WUs are downloaded they are "tagged" on your system with the CURRENT version of the program you are reporting at the time.

For example, I had been reporting that I was running version 5.15 when the latest optimized application (2.0) was released. When I downloaded the newest optimzed application, I also got a new version of the app_info.xml file.

This version contained run information for versions 5.12, 5.13, 5.14, 5.15 and 5.17. Since I just dropped the app_info.xml file in place, any WUs that had been "tagged" by my system as 5.15 would be run by the new appllication and all new WUs would be "tagged" as 5.17. (BOINC always assumes that the last "version" in app_info.xml file is the "current version".)

If I'd "cleaned up" the app_info.xml file to only work with WUs that were "tagged" as 5.17, then all of my 5.15 WUs would have failed. BOINC wouldn't have been able to locate a program to run the WUs.

I hope this is clear. It's a point where some people get hung up on. The main thing is that there are not 5.x WUs, there are only Enhanced WUs.

---

A stup*d question perhaps but wont we need a new v5.17 app for the new 5.17 WUs ?

So far, it looks like only very minor changes will be needed. Changing the multiplier used when reporting fpops, and some database stuff to be able to show the right names for the ALFA receiver channels pretty well covers what is in the 5.17 cvs changes. But there's certainly a possibility that Eric Korpela will need to add more changes.

                                                           Joe

Damn, this new app is fast on my AMD 64. I'm impressed!! I've read that chicken wrote about large gains on AMD 64, but it is a lot more than I expected. Nicely done!
According to credits granted per hour, I'm 30% up compared to Crunch3r's 5.12. How many seconds I've saved can only be guessed. I didn't make a comparison. One thing is for sure, the new app is helluva fast. ;-)

---