Message boards :
Number crunching :
Faster SETI Processing?
Message board moderation
Author | Message |
---|---|
MikeSW17 Send message Joined: 3 Apr 99 Posts: 1603 Credit: 2,700,523 RAC: 0 |
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? |
Hans Dorn Send message Joined: 3 Apr 99 Posts: 2262 Credit: 26,448,570 RAC: 0 |
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 |
Paul D. Buck Send message Joined: 19 Jul 00 Posts: 3898 Credit: 1,158,042 RAC: 0 |
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 ... |
MikeSW17 Send message Joined: 3 Apr 99 Posts: 1603 Credit: 2,700,523 RAC: 0 |
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 ;) |
©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.