CodeI have the following piece of code        #define equidIND(divid, recip) (size_t)((divid) * (recip) + 0.5)        ...        // Get index for average velocity        //idx_velo_avg    = (size_t)(velo_avg * funmaps_velo->map_velo_step_recip + 0.5);        idx_velo_avg = equidIND(velo_avg, funmaps_velo->map_velo_step_recip);        // Get effective velocity        velo_eff = sqrt(velo_pos_k * velo_pos_k + accel * delta_s);        // Get index for effective velocity (HOTSPOT)        idx_velo_eff = equidIND(velo_eff, funmaps_velo->map_velo_step_recip);ExplanationIt contains three lines with operationsFirst line - idx_velo_avg = ...  Getting index by value using rounding/NNinterpolation:  Mapping value to index by division turned into a multiplication with the reciprocal:velo_avg * funmaps_velo->map_velo_step_recip Adding 0.5 to the resulting double  Truncating using a cast (size_t). The values are always > 0 btw.The second line computes then the effective velocity, using a call to sqrt.The third line does exactly the same as the first, but with a different base value (first line velo_avg - third line velo_eff)ProfilingVery Sleepy and AMD CodeXL give similar profiling results  The snapshot is taken from AMD CodeXL. Question(s)What I wonder is:Is this way of computing an index a good, fast and secure one?Why does the third line apparently more than 4 times slower than the first. At least this is how I interpret the percentage values in CodeXL and Very Sleepy kind of confirms this interpretation. Has it to do with the intermediate call to sqrt?ASMAs additional information, the assembly view shows the following (link to image)
Two index computations differing in execution time
c;assembly;casting