Marc Glisse ha scritto:
I believe that the check for 0 in mpz_mul actually falls in your first category, it is necessary for correctness (however, mpz_mul also checks whether one of the arguments fits in a single limb, which fits your description better). And the else path is supposedly already heavy enough that the penalty should not be too bad. Did you see a significant performance gain using 2) instead of 3)?
It depends from data set and optimizations done inside the library: suppose we enter in mpz_mul 99% of the times with both operands below 1<<(sizeof(mp_limb_t)*4) and this is treated as a special case, then I think that to avoid two extra comparison can make a difference. My point is that to maximize performance the unavoidable path should be the least computationally expensive. -- Abramo Bagnara Opera Unica Phone: +39.0546.656023 Via Borghesi, 16 48014 Castel Bolognese (RA) - Italy