reader50
Senior Member
Posts: 205
Registered: Jun 2000 posted 07-16-2000 07:09 PM ΚΚΚ ΚΚΚΚ ΚΚ
------------------------------------------------------------------------
I recently downloaded Motorola's LibMotoSh floating point library and decided to put it to the acid test using SETI@home. I copied my next work unit (entire SETI folder) and set the copy aside. After crunching the WU, I again copied the entire SETI folder as the Normal result. The original unsolved folder copy was substituted, the LibMotoSh extension was installed, reboot, and SETI was allowed to re-crunch the same WU using the LibMotoSh library. The final result folder was again copied as the LibMotoSh result. Then I compared the Normal result folder & the LibMotoSh result folder.
Configuration details: G4 350 Sawtooth, 64Meg, VM on, SETI used as screen saver only, no other applications running when SETI runs, screen set to go blank after one minute. I have tried turning VM off but got no speed difference. The main result was that there was no memory left over for anything else, so VM stays on. Will get lots more memory when the price comes down, I have a strong reluctance to pay double for the same product.
My normal average time runs about 7 1/2 hours at present, with some variation. The test WU ran longer than average. Screen shots compared:
Next, I compared the result files. The good results turn out to be in the Outfile.sah, where the client sends back the best result with plain english labels. The Result.sah file contains headers with the Outfile contents tacked onto the end. My Outfiles were identical with both methods except for time logging, and calculated spike power. I have copied out the spike power values below:
Solved Normal: power = 8.855247e+01
Solved LibMotoSh: power=8.855243e+01
LibMotoSh error: 0.99999954829
Time Normal = 8.15111111111 Hours
Time LibMotoSh = 8.7205 Hours
Time Difference: 1.0698541439 or about 7% longer.
General Conclusions
* System stability was not an issue. No odd behavior was noted.
* LibMotoSh looks like it cuts a few corners in the rounding department. The difference is extremely small, and would be significant only in repeated engineering calculations where exact accuracy is critical. I do not believe that this compromises the SETI@home results, so I see no ethical questions here.
* I suspect Apple has patched the standard SANE routines to take advantage of AltiVec when running on a G4. LibMotoSh, on the other hand, was last updated 5/31/1996 and could not have any AltiVec awareness. It would be interesting if someone with a G3 or earlier repeated my test to see if LibMotoSh takes longer on non-AltiVec systems.
On my G4, I have removed LibMotoSh. I chose to send in the Normal result.