my-naparst-r3-no-prec
<wu_cpu_time>4600.744603</wu_cpu_time>
my-naparst-r3-prec
<wu_cpu_time>4902.263765</wu_cpu_time>
naparst-r3
<wu_cpu_time>4901.236921</wu_cpu_time>


./rescmp/rescmp result_unit.sah my-naparst-r3-no-prec/result.sah
Result: these are weakly similar.
./rescmp/rescmp result_unit.sah my-naparst-r3-prec/result.sah
Result: these are strongly similar.
./rescmp/rescmp result_unit.sah naparst-r3/result.sah
Result: these are strongly similar.

Gary,

So the conclusion is that the -no-prec-div flag causes a big speedup but
weak similarity, as Tetsuji has claimed?

@Harold

Just a note

analyzeFuncs.cpp: In function 'int v_ChirpData(float*, float*, float, int, double)':
analyzeFuncs.cpp:938: error: 'align' was not declared in this scope
analyzeFuncs.cpp:938: error: '__declspec' was not declared in this scope
analyzeFuncs.cpp:938: error: expected `;' before 'float'

I add "-no-prec-div -no-prec-sqrt" for my-naparst-r3-no-prec, so maybe both of them cause weak similarity.

What would you think would be an appropriate maximum amount of memory
for the caches to use? Although Hans might disagree, (and I might be wrong)
my explorations seem to show that it is important to have more than 8MB cache. The chances of finding cached data are much higher if the cache is larger. Would you think that a cache of 160 MB is OK? Or is that still too large?

I would say the key objective for memory reduction would be to allow the client to run on a system with 256MB ram without swapping, so a maximum of about 160MB (a figure already mentioned) seems about right, leaving 96MB for the system, although I guess it would be nice if this could be reduced further.

Using your ratio of hits/mises analogy above, I guess you need to do some analysis to find the sweet spot.

Ned

What would you think would be an appropriate maximum amount of memory
for the caches to use? Although Hans might disagree, (and I might be wrong)
my explorations seem to show that it is important to have more than 8MB cache. The chances of finding cached data are much higher if the cache is larger. Would you think that a cache of 160 MB is OK? Or is that still too large?

I would say the key objective for memory reduction would be to allow the client to run on a system with 256MB ram without swapping, so a maximum of about 160MB (a figure already mentioned) seems about right, leaving 96MB for the system, although I guess it would be nice if this could be reduced further.

Using your ratio of hits/mises analogy above, I guess you need to do some analysis to find the sweet spot.

Ned

At some point, Boinc developers specified that an application should use less than 64MB of RAM. I personally disagree, plus there is a Boinc bug that allows applications to use unlimited memory.

Anyway, I would like to have two versions of the client -- the "boinc-compliant" low memory client for the 64MB RAM, and the "fastest reasonable" client using 256MB RAM. Why 256MB? I personally do not have computers with less than 512MB RAM. Memory is so cheap these days, especially older PC133 SDRAM and DDR266 SDRAM. Using half of the RAM for Seti is OK with me.

If Hans is correct, which I suspect he is, we'll be able to produce
a client that uses only 8MB cache and has no performance penalty.
Hopefully soon.

... Do I guess right that I'd better trim that down to just:

.boinc/projects/setiathome.berkeley.edu/app_info.xml
<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome-4.07.athlon-xp-static-pc-linux-gnu</name>
        <executable/>
    </file_info>
</app_info>

<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome-4.07.athlon-xp-static-pc-linux-gnu</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome</app_name>
        <version_num>470</version_num>
        <file_ref>
            <file_name>setiathome-4.07.athlon-xp-static-pc-linux-gnu</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>

Hello,

I've updated all setiathome Linux clients for i686,P3,Athlon( K7) and Athlon XP.
And all setiathome clients for EV5, EV6 and EV67 running Linux.
All are based on Harolds 3.0 source.

URL: I WANT VERY FAST LINUX CLIENTS :-)

Hello,

I've updated all setiathome Linux clients for i686,P3,Athlon( K7) and Athlon XP.
And all setiathome clients for EV5, EV6 and EV67 running Linux.
All are based on Harolds 3.0 source.

URL: I WANT VERY FAST LINUX CLIENTS :-)

You're going to kill me. I've released another version-- R3.1.
Get it at http://naparst.name
This one uses only 16MB cache. It could have been only 8MB, but I
couldn't bear the thought of not using any of my multi-cache code, so
I left the cache size at two for old times sake.

I've finally realized that Hans was right all along about the chirp
rate. It needs to be a double precision variable. Now everything is good.
I don't know why I didn't listen the first time.

So the program is just as fast, but it uses practically no memory.
Onward and upward.

You're going to kill me. I've released another version-- R3.1.
Get it at http://naparst.name
This one uses only 16MB cache. It could have been only 8MB, but I
couldn't bear the thought of not using any of my multi-cache code, so
I left the cache size at two for old times sake.

It took me 6 hours to compile ...
I'll do it again :-)

It's 4.20 am here in germany..

You're going to kill me. I've released another version-- R3.1.
Get it at http://naparst.name
This one uses only 16MB cache. It could have been only 8MB, but I
couldn't bear the thought of not using any of my multi-cache code, so
I left the cache size at two for old times sake.

I've finally realized that Hans was right all along about the chirp
rate. It needs to be a double precision variable. Now everything is good.
I don't know why I didn't listen the first time.

So the program is just as fast, but it uses practically no memory.
Onward and upward.

So Hans and Harold have succeeded in their brief to produce a client which uses less memory but retains the full speed improvement - truely amazing!