opt. SETI@home AP app?

[Sutaru Tsureku]

I saw now in the SETI@home forum, that Astropulse will come next week..

We will see in the near future an optimized Astropulse application? 

How must look my current app_info.xml that my rigs can download AP WUs?
Because if I don't edit the app_info.xml my rigs don't download AP WUs, right?


BTW.
If I understood the infos correct on the SETI@home homepage..
AP is searching not extraterrestrial intelligence. But natural phenomena.. like black holes and others?

[Jason G]

Hi,
   Don't know about others but I've been leaving astropulse to the project for the dust to clear and for them to iron any wrinkles out (and to get my own work done ).  Raistmer's on holiday too.  In a few weeks I (and others may be already) will probably try simple recompiles, get oriented with the program structure/optimisation possibilities and go from there.  I have looked at the berkeley repository already (and poked around a bit)  and will delve deeper only gradually, as I have schoolwork to do.  New tools need to be made for benchtesting and validating too, as a priority, including creation of some shortened WUs for testing (if possible).

At this stage there is no 'easy' method to running stock astroppulse with the optimised app, you have to download the astropulse files manually and edit the app_info.xml, though I'm sure others will will provide the app_infos, I'll think about possible easier methods.

The 'About AstroPulse' page says in part:

Astropulse is a new type of SETI. It expands on the original SETI@home, but does not replace it. The original SETI@home searches for narrowband signals, as does a conventional AM or FM radio. Astropulse, on the other hand, listens for broader-band, short-time pulses.

and

In addition to ET, Astropulse might detect other sources, such as rapidly rotating pulsars, exploding primordial black holes, or as-yet unknown astrophysical phenomena.

You can imagine that SETI@home is a search for a gold needle (ET) in a haystack. During the search for a gold needle, Astropulse might occasionally find a silver needle (a pulsar or black hole.) These silver needles have their own scientific value, even if they don't represent extraterrestrial communications.

So you're looking for ET, but may stumble upon other important stuff too

Cheers, Jason

[Raistmer]

We will see in the near future an optimized Astropulse applicatioo? 

I did instrumented ICC compiled build (w/o any additional manual optimization) of AP app before my vacations and leave it to collect profile data. Need to synchronize with current threads on forum and after will provide some data about gain in speed for AP from ICC/PGO.

[Richard Haselgrove]

Current AP release candidate (v4.35) seems to be showing very poor performance on AMD-based systems.

Anyone with access to the code and experience of these sort of things care to comment?

http://setiathome.berkeley.edu/beta/forum_thread.php?id=1372

[Jason G]

Thanks, will keep this in mind when delving deeper for optimisation opportunities. There are likely compound smaller issues that are cumulative to see the disparity:

 - Compiler options chosen: presumably GCC
 - cache structure, the nature of the algorithms may currently be taking advantage of larger cache available on the Intel CPUs.
 - Actual CPU performance disparity to some degree
 - Memory access patterns and/or perhaps function ordering , could be breaking prefetcher performance,and/ or hitting some sensitivity to unaligned loads.
 - SSE level, different chips in both brands have better implementations, though I'd expect GCC to be using mostly SSE2 which should be fairly convergent, though perhaps stock AP is currently reliant on non-sse-code, dunno yet.
- On newer AMD chips (and soon Intel), the move is to large shared l3 cache and much smaller l2 cache, so many of the abovementioned factors would be compounded again by increased cache subsystem latency in the event of misses.

Given that the optimisation process is largely about reduction of the cache miss component of the last issue listed, it therefore addresses each of the previous ones by inheritance.  Intel compiler seems to be particularly good at trying to keep things in higher cache levels, picking better instruction combinations. Memory access patterns are algorithmic issues where key hotspots can be hand coded to alleviate exposure of the memory subsystem latencies. At the moment a larger cache would shield this penalty to a high degree.

I guess the above would have only been done to a basic level at this stage, and refinement should see clock for clock performance converge somewhat, making allowances for micro architectural differences.  In essence you may be seeing the characteristic that AMD's lower transistor count demands simpler circuitry, therefore is more sensitive to penalties typically found in unoptimised code, whereas the die shrink enjoyed by 45nM core2s allows more specialised circuitry to deal with these exceptional penalty cases, rendering them less sensitive to things like unaligned loads and various stalls common in raw 'first cut' code.

It may, in fact, be an early indicator that improvement by optimisation may help overall performance significantly.

Hope that helps a little, still a lot of exploration to do.

Jason

[Josef W. Segur]

FWIW, I believe the AP application is built with VS 2005 or VS 2008. Apps built with DevC++/MinGW generally link to msvcrt.dll, I'm not even sure it's possible to go to static linkage for that runtime code. Dependancy Walker doesn't show any direct usage of msvcrt.dll, though of course there's indirect usage through the fftw dll built with MinGW.

AP also does have the linkage to IsDebuggerPresent in Kernel32.dll symptomatic of recent MS compilers lack of Win95 compatibility.
                                                               Joe

[Jason G]

FWIW, I believe the AP application is built with VS 2005 or VS 2008. Apps built with DevC++/MinGW generally link to msvcrt.dll, I'm not even sure it's possible to go to static linkage for that runtime code. Dependancy Walker doesn't show any direct usage of msvcrt.dll, though of course there's indirect usage through the fftw dll built with MinGW.

AP also does have the linkage to IsDebuggerPresent in Kernel32.dll symptomatic of recent MS compilers lack of Win95 compatibility.
                                                               Joe

Ahh ok, not a lot of 'easy' optimisation leverage with that combo then.  Might be an opportunity to resolve the win95 issue 'properly' early on and verify that no clr startup stuff has crept in 'accidentally'. I wonder do Linux builds, presuming there are some, demonstrate similar performance characteristics...

Jason

[Sutaru Tsureku]

How it's looking? There are some news because of a date of publishing an opt. AP-app? 

Ahh.. yes.. my QX6700 need SSSE3..
..and my old Athlon 600 need MMX..
 

[Jason G]

LoL, sorry not anytime soon Sutaru. We're just wetting our feet in what is going to be a big, long term project (not just a simple recompile this time).  What helps a lot is that the code does look very well organised in key places, with exceptionally helpful comments, and will likely facilitate modifications for good current machines and future hardware  as well. Sadly, I can't recommend that MMX will ever be useful or practical for AstroPulse, though SSE and up are being considered.

Cheers, Jason

[WHRoeder]

How must look my current app_info.xml that my rigs can download AP WUs?

Code: [Select]

<app_info>
    <app>
        <name>astropulse</name>
    </app>
    <file_info>
        <name>astropulse_4.35_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-1-1a_upx.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>ap_graphics_4.35_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>astropulse</app_name>
        <version_num>435</version_num>
        <file_ref>
            <file_name>astropulse_4.35_windows_intelx86.exe</file_name>
            <main_program/>
        </file_ref>
        <file_ref>
            <file_name>libfftw3f-3-1-1a_upx.dll</file_name>
            </file_ref>
        <file_ref>
        <file_name>ap_graphics_4.35_windows_intelx86.exe</file_name>
            <open_name>graphics_app</open_name>
        </file_ref>
    </app_version>
    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>AK_v8_win_SSE2.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>517</version_num>
        <file_ref>
            <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>527</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>528</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>reference: Advanced Users