archive: Re: SETI@home and processing time

Re: SETI@home and processing time

R.J. Fear ( (no email) )
Wed, 19 May 1999 10:28:12

David (and SETI@Home via CC),

At 08:39 AM 5/18/99 +0100, you wrote:
>>
>> I'll drop my 2 cents worth on the SETI@Home software and then quietly slip
>> out the back door. By far one of the most inefficient processes I've ever
>> had the pleasure to run a profile trace against. The graphics are

Just quickly: don't take my statement wrong, it was an attempt at humor.

>Is the inefficiency in terms of the graphics and windows message loop code,
>or in the numerical stuff itself. (Personally I question the need for
>floating point for most of it and suspect it is all written in high
>level languages.)

>From my cursory look at the general flow the ratio of graphic to numeric
looked slightly heavier on the graphic. I'm only looking at the display of
a buss/processor monitor, I don't know what they're doing just where and
what they're touching. I tend to agree with you that floating point isn't
a great choice, it's often chosen because it's easier to code in C, Basic,
COBOL, etc. Hard to say what the logic was when they made the decision to
pick a language.

>> beautiful but the processing time required to reduce just 200K of data are
>> excessive. Not bad for a first cut, only time will tell.
>
>Don't forget that the data is being solved for a large number chirp rates
>and that the input data is only two bits each of I and Q, so this represents
>400K time samples.
>
I hadn't taken into consideration that the analysis was done over multiple
chirp rates. Explains some of the overhead I'm seeing in loops. I doesn't
look like the developers took the cache and prefetch of Pentium processors
into consideration when they built it. Either that or the high level
language used didn't allow it.

Design Note for the SETI@home folks: On high end Intel type processors
it's better to code loops as tight as possible (try and keep cache prefetch
reloads from happening), or not at all. i.e. don't use loops with index
driven loop counters, instead code a macro to replicate the series of
instructions inline and jump into and out of it. Granted this philosophy
will increase the size of an executable by some very large factors, but it
results in a routine that is very quick (almost scarry). Disk is cheap,
processor is not.

Respectfully,
R.J. Fear

---------- if you're forwarding.... feel free to snip here ---------------

Robert J. (R.J.) Fear North Central Regional Coordinator
President The SETI League Inc.
Topia Inc. ND, SD, NE, MN, IA, WI, IL, MI, and IN
Adaptive Design and Development Corp. Project Argus Station ID: EN70en
225 North Boots Street
Marion Indiana 46952 USA
voice (765) 668-4198 fax (765) 668-4197
email: rjfear@adaptv.com ICQ #: 111461

"If we don't know where we're going how will we know when we're there?"