You can leave r103 active with the existing app_info.xml file if you want, and you will get an occasional resend from the unfinished v5.00 work: or you can switch to the stock v5.03 application.

Please forgive a simple question, from a simple person.

Can I leave my existing app_info.xml file, to continue using optimized MB, and somehow switch on stock V5.03 AP? Or do I need a new app_info? I need real easy step by step answers here ;).

---

Strangely enough i've just doctored my app_info to see if i can get stock astropulse v5 work, as well as optimised AP 5.00 work and MB 6.03 work,
and i've just PM'd it to Richard, but i haven't managed to get any work yet,
further changes might be needed.

Claggy

You can leave r103 active with the existing app_info.xml file if you want, and you will get an occasional resend from the unfinished v5.00 work: or you can switch to the stock v5.03 application.

Please forgive a simple question, from a simple person.

Can I leave my existing app_info.xml file, to continue using optimized MB, and somehow switch on stock V5.03 AP? Or do I need a new app_info? I need real easy step by step answers here ;).

The simple answer is 'No'.

You can crunch optimised MB and stock AP, but to do so you have to modify app_info.xml and download the application files yourself. It's what we did back in August 2008, when Astropulse was first released and there were no optimised versions available.

Thanks Richard. I think I'll leave things as they are, until the new optimized AP is available, along with a new app_info.

---

Strangely enough i've just doctored my app_info to see if i can get stock astropulse v5 work, as well as optimised AP 5.00 work and MB 6.03 work,
and i've just PM'd it to Richard, but i haven't managed to get any work yet,
further changes might be needed.

Claggy

You have a PM. A couple of changes needed, one asap, please.

Incorrect, It is a Microsoft Visual Studio build, and No, Intel compiler doesn't do that unless you use certain dynamic dispatch features, which we don't.

Then the executable contains a lot of redundant data. I opened it as a plain text file and did a search on "Intel", and got a large number of strings such as:

GenuineIntel (ie the CPUID string that specifically identifies Intel CPUs)
Intel(R) Core(TM) Duo processors and compatible Intel processors with supplemental Streaming SIMD Extensions 3 (SSSE3) instruction support
Intel(R) Pentium(R) 4 and compatible Intel processors with Streaming SIMD Extensions 3 (SSE3) instruction support

and many more. There are no strings which mention AMD or any other CPU manufacturer. It seems strange that it would have strings which identify specific Intel CPUs if it is not specifically looking for them in preference to other CPU manufacturers.

Also, the SSE3 app on a C2D is finishing work in approx 8 hours or less, but the SSE app is taking in the region of 45-50 hours on an early Athlon 64. I'm going to run the SSE app on the C2D when there is enough work so I can compare it one two systems at similar speeds and see if I am right. I do not believe the difference between SSE and SSE3 would explain that high a difference between the running times (ie 15 credits per hours on an Athlon 64 at 2.4GHz and 100 credits/hour on a C2D at 2.66GHz).

---

Incorrect, It is a Microsoft Visual Studio build, and No, Intel compiler doesn't do that unless you use certain dynamic dispatch features, which we don't.

Then the executable contains a lot of redundant data. I opened it as a plain text file and did a search on "Intel", and got a large number of strings such as:

GenuineIntel (ie the CPUID string that specifically identifies Intel CPUs)
Intel(R) Core(TM) Duo processors and compatible Intel processors with supplemental Streaming SIMD Extensions 3 (SSSE3) instruction support
Intel(R) Pentium(R) 4 and compatible Intel processors with Streaming SIMD Extensions 3 (SSE3) instruction support

and many more. There are no strings which mention AMD or any other CPU manufacturer. It seems strange that it would have strings which identify specific Intel CPUs if it is not specifically looking for them in preference to other CPU manufacturers.

Also, the SSE3 app on a C2D is finishing work in approx 8 hours or less, but the SSE app is taking in the region of 45-50 hours on an early Athlon 64. I'm going to run the SSE app on the C2D when there is enough work so I can compare it one two systems at similar speeds and see if I am right. I do not believe the difference between SSE and SSE3 would explain that high a difference between the running times (ie 15 credits per hours on an Athlon 64 at 2.4GHz and 100 credits/hour on a C2D at 2.66GHz).

You're comparing an Athlon64 to a core 2 duo? Please GET REAL. Try Phenom 2 and you'll have a more realistic comparison.

[Edit: Just a reminder to anyone who wants optimised code for any particular platform, the (original stock) source code is freely available, or our site has Windows ports oriented toward Intel and Generic Compatible CPUs, as always, as a starting point. It is not in our skill or resources base to optimise targets for every possible CPU out there.]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Debs wrote:

Incorrect, It is a Microsoft Visual Studio build, and No, Intel compiler doesn't do that unless you use certain dynamic dispatch features, which we don't.

Then the executable contains a lot of redundant data. I opened it as a plain text file and did a search on "Intel", and got a large number of strings such as:

GenuineIntel (ie the CPUID string that specifically identifies Intel CPUs)
Intel(R) Core(TM) Duo processors and compatible Intel processors with supplemental Streaming SIMD Extensions 3 (SSSE3) instruction support
Intel(R) Pentium(R) 4 and compatible Intel processors with Streaming SIMD Extensions 3 (SSE3) instruction support

and many more. There are no strings which mention AMD or any other CPU manufacturer. It seems strange that it would have strings which identify specific Intel CPUs if it is not specifically looking for them in preference to other CPU manufacturers.
...

The FFTW static library was built with ICC, because the FFTW authors note that builds made with the Microsoft compiler are incorrect. Comparing the speed of using that static library with otherwise identical builds using the FFTW DLL (DevCPP/MinGW build) supplied by the project, the static ICC version outperformed on both Intel and AMD test systems. The application itself is built with Microsoft tools, the Intel strings must come from that library.

                                                              Joe

Actually, my point is not whether a C2D is faster than an Athlon 64, that goes without saying (hence why I am going to run the SSE opt app on the C2D for one wu when they are available, in order to compare). My point is that the SSE app contains code which looks very much like it is looking for specific Intel CPUs but not for other specific manufacturer CPUs. As I have seen reports that indicate the Intel compiler includes such tests and uses generic code for non-Intel CPUs, I have suggested that maybe that is happening.

I did not aim to start an argument over whether it is right or wrong. I merely asked in my original post if there is a generic SSE2 app so my slower 64-bit systems can use it, as the SSE opti app seems to be running at about the same speed as the non-optimised app (if I ever manqage to download another ap wu on either of the relevant systems, I will confirm this, as have now removed the opt apps from those systems).

---

The FFTW static library was built with ICC, because the FFTW authors note that builds made with the Microsoft compiler are incorrect. Comparing the speed of using that static library with otherwise identical builds using the FFTW DLL (DevCPP/MinGW build) supplied by the project, the static ICC version outperformed on both Intel and AMD test systems. The application itself is built with Microsoft tools, the Intel strings must come from that library.

                                                              Joe

Thanks Joe. That was the most helpful answer I have read.

I will still run tests when ap is back online (probably wait for the new version though) so I can be sure what is ha[ppening between systems and versions :)

Are there any plans for a generic x64 version (I use 64-bit Windows), or is that too much extra work?

---

Ah, thanks for clarifying your position. I can state categorically that the AstroPulse optimised binaries do not use the dynamic CPU dispatch mechanisms offered by Intel compiler.

If you have stock astropulse times, against optimised times that are even roughly equal, I would be very interested to see the stderr output, as nearly all optimisations to date have been generally applicable and boosted performance several fold over stock.

Please note that if you mean AKv8 multibeam binaries then the story is completely different, and we can make more suitable recommendations if you need SSE AMD targetted builds for that.

Jason

[Edit: No immediate plans for x64 specific builds, though they will come when more generally applicable optimisations have been made.]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Ah, thanks for clarifying your position. I can state categorically that the AstroPulse optimised binaries do not use the dynamic CPU dispatch mechanisms offered by Intel compiler.

If you have stock astropulse times, against optimised times that are even roughly equal, I would be very interested to see the stderr output, as nearly all optimisations to date have been generally applicable and boosted performance several fold.

Please note that if you mean AKv8 multibeam binaries then the story is completely different, and we can make more suitable recommendations if you need SSE AMD targetted builds for that.

Jason

I have used both KWSN_2.4V_SSE2_MB.exe and ap_5.00r103_SSE.exe on my Athlon 64 3200+ (socket 754, Newcastle core, SSE2 only) running XP64. I only ran ap_5.00r103_SSE.exe on the clawhammer socket 754 3600+. In all cases, I can only get about 15 credits/hour, compared to the stock app at cosmology@home which gives around 20/hour. I expected the optimised apps here to give more than stock apps elsewhere (although I am also aware that all projects have different standards). I have checked on boincstats.com, and see that typically cosmology gives approx 1.33 * the credits of seti, but I am sure that is compared to all seti users, not just the optimised apps? On the C2D seti optimised pays about 2.5 times what cosmology pays.

Would I be better using different build on the two AMD64 systems?

---

Would I be better using different build on the two AMD64 systems?

Ahh perhaps. For Multibeam you should try (if you haven't) using the 2.4V FFTW build of Crunch3r's, though I don't seem to have a link handy, and am not sure if it is listed on Crunch3r's page anywhere. (Hopefully someone can provide one). I am not certain if he has made a 64 bit variant or not, I think there was some issues with it, but wasn't paying attention as I was busy elsewhere. [EDIT: Sudden thought, Did you try our 32 bit SSE2 AKv8 Build? *slaps own head*]

For AstroPulse, the new release stock 5.03 [BTW: not compatible with our r103] takes even longer, and the performance difference to test optimised builds is even greater (Currently subject to favourable validation test outcomes), and the credit rate is raised to more appropriate levels ~1290 credits / WU . The SSE optimised build should perform roughly 2-3+x stock on minimally blanked tasks.

I did some cosmology work a long time ago, and the credit rate was significantly higher than on S@H at the time (Much more than 33% more). I don't know the status quo now, as I dropped off when they started getting many server problems, But my guess is that since no optimised application is available, the credit rate would correspondingly be high enough to better reward older machines, as here the credit multiplier is scaling against the 'Median Machine' (Whatever that is ;D)

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

[EDIT: Sudden thought, Did you try our 32 bit SSE2 AKv8 Build? *slaps own head*]

I hadn't thought about using the 32-bit SSE2, just assumed the older 64-bit SSE2 would be faster. I will try that at some point.

For AstroPulse, the new release stock 5.03 [BTW: not compatible with our r103] takes even longer, and the performance difference to test optimised builds is even greater (Currently subject to favourable validation test outcomes), and the credit rate is raised to more appropriate levels ~1290 credits / WU . The SSE optimised build should perform roughly 2-3+x stock on minimally blanked tasks.

I've been waiting to see if one of the AMD64 machines will download a stock astropulse app (any of them!) but no joy for now. Hopefully once the optimised app is ready there will also be work for ap :)

---

I've been waiting to see if one of the AMD64 machines will download a stock astropulse app (any of them!) but no joy for now. Hopefully once the optimised app is ready there will also be work for ap :)

Yep, in testing we're in the same boat. Though we have completed a few tasks, and are reasonably happy with the indicated performance (at least for initial release), we have no indication of a 5.03 validation yet against stock wingmen or direct time comparisons. Not surprising I suppose given the long processing time and slow rate of issue (my p4 hasn't managed to pick up one at all yet).

In the meantime, It would be helpful if anyone who does manage to get, and process, a stock 5.03 AstroPulse task, could post their machine/task link to indicate some kind of baseline, as we're seeing some WU processing time variability that caught us by surprise [Though we're fairly certain it's the amount of client side blanking that causes it].

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

ok where do I find the stock AP apps to manual install?

---

"Red Warrior Needs Food Badly"

ok where do I find the stock AP apps to manual install?

If you have Astropulse selected in your web preferences, then the app will be downloaded automatically when you are assigned one of the new WU's. It's all auto-magic.

F.

---

Uhhh, ya. I am going from optimized r103 back to stock ...

---

"Red Warrior Needs Food Badly"

ok where do I find the stock AP apps to manual install?

If you have Astropulse selected in your web preferences, then the app will be downloaded automatically when you are assigned one of the new WU's. It's all auto-magic.

F.

Since he's using optimised apps with an app_info it won't,
he needs to download the apps manually and add them to his app_info.

When i get home in about 45mins, I'll post the links & my app_info unless someone beats me.

Claggy

ok where do I find the stock AP apps to manual install?

If you have Astropulse selected in your web preferences, then the app will be downloaded automatically when you are assigned one of the new WU's. It's all auto-magic.

F.

Since he's using optimised apps with an app_info it won't,
he needs to download the apps manually and add them to his app_info.

When i get home in about 45mins, I'll post the links & my app_info unless someone beats me.

Claggy

Oops. Sorry, insufficient investigation. I'm sure Claggy will get back with a location.

F.

---