Faster SETI Processing?

Message boards : Number crunching : Faster SETI Processing?
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile MikeSW17
Volunteer tester

Send message
Joined: 3 Apr 99
Posts: 1603
Credit: 2,700,523
RAC: 0
United Kingdom
Message 220830 - Posted: 24 Dec 2005, 12:18:39 UTC

I am no mathematician, so this may be utterly impossible but...

This thread
reminded me of something that I wondered about a while back.

SETI processing as I understand it uses a lot of floating-point math - which is much slower than integer.

Years ago a fractal generating program appeared called fractint. It generated those intersting mandlebrot sets.
There are lots of fractal generation programs, but fractint used only integer math and was thus much faster than others using FP.

Is there any possibility that the SETI processing algorithms could also be redesigned to use integer math either exclusively or substantially?

ID: 220830 · Report as offensive
Hans Dorn
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 3 Apr 99
Posts: 2262
Credit: 26,448,570
RAC: 0
Germany
Message 220840 - Posted: 24 Dec 2005, 12:40:45 UTC
Last modified: 24 Dec 2005, 12:41:10 UTC

Hi Mike,

integer math only works well for numbers that don't vary much in size throughout the calculation.

This is the case for the mandelbrot set, but not for seti.

Integer math isn't _that_ much faster than floating point nowadays, too.


Regards Hans
ID: 220840 · Report as offensive
Profile Paul D. Buck
Volunteer tester

Send message
Joined: 19 Jul 00
Posts: 3898
Credit: 1,158,042
RAC: 0
United States
Message 220865 - Posted: 24 Dec 2005, 13:34:34 UTC

In theory, you could use "scaled integers" if the dynamic range is not that great. And, if done, would possibly result in a faster processing of each "atomic" calculation.

The same math operation using floating point numbers would be slower in each of these cases.

However, when the application is "optimized", the vector type and other extension instructions can be used which over the length of the vector returns values much more quickly than you might see with the integer only math operations. WIthoug the added problems of scaling.

As an example, when I toured a facility with a Cray, the particular machine took 96 clock cycles to do one floating point operation. But, once the vector cache was filled, it emitted one result each remaining clock cycle. So, if the vector was longer than 96 values you would see a hugh gain in average operation speed.

The truth of the matter is, as Hans said, effectively, when compiled to the target hardware there is no difference and in fact, overall, is likely to be faster now with floating point than integer. Plus being easier to code ...
ID: 220865 · Report as offensive
Profile MikeSW17
Volunteer tester

Send message
Joined: 3 Apr 99
Posts: 1603
Credit: 2,700,523
RAC: 0
United Kingdom
Message 220883 - Posted: 24 Dec 2005, 14:14:40 UTC

Thanks chaps.
It's rather as I suspected it might be.
IIRC fractint goes back to the days of distinct integer/fpu chips aka 80386/80387 when I suppose the difference between Integer and float was could have been an order of magnitude or worse. I didn't have a BOINC benchmark to measure it back then ;)

ID: 220883 · Report as offensive

Message boards : Number crunching : Faster SETI Processing?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.