Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ...
It’s a layer cake --> “allows the creation of” [Binary Math Ops] –> [Integer Math Ops] -- if your CPU only understands INTs -- Floating Point can be emulated with Int Math and Binary Ops [Binary Math Ops] –> [Integer Math Ops] --> [Floating Point Math Ops] -- ^ ^ If the CPU does native Floating Point ^ ^ -- If all integer control logic is removed, Binary Math Ops go at true clock speed -- Int and Float math will never really reach true clock speed, as there is an inherent overhead as both are based on Binary Math Ops (and Microcode based CPUs are worse for speed for this reason) This is why ASICs do binary hashes so fast, yet Cray XPs struggle in massive parallelism to perform Floating Point at anything like real clock speed. Moral : When in doubt go to the fundamental underlying framework to help solve a problem, if no other solution is working. MP DSN @ Home PS : I have designed a CPU, but C is for Climate ... http://www.scribd.com/doc/209133631/Climate-Prediction-Coprocessor -------------------------------------------------------------------------------- My feeling about this is that computing credit should be measure general-purpose FLOPs, i.e. FLOPs that are usable by most science applications. FFT FLOPs are not general-purpose. So the right thing would be for SETI@home to grant both computing credit and project-defined credit. CPU and GPU jobs would be granted both; jobs done by ASICs or FPGAs would be granted only project-defined credit. Similarly, BU could grant computing credit for mining jobs done by CPU or GPU; but for ASIC jobs it would grant only project-defined credit. Of course this is all subjective and fuzzy; you might argue that GPU FLOPs are not general-purpose because some apps don't map well to GPUs. But we need to draw a line somewhere, and I think that, with the advent of OpenCL, GPUs can be considered general-purpose. -------------------------------------------------------------------------------- _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
