In the unlikely event that something is likely unlikely.

[textbrowser]

Can you provide rationale on your choices of likely() and unlikely()?

void
zsub_nonnegative_assign(z_t a, z_t b)
{
if (unlikely(zzero(b)))
zabs(a, a);
else if (unlikely(!zcmpmag(a, b)))
SET_SIGNUM(a, 0);
else
zsub_impl(a, b, b->used);
}

What if I issue zsub_nonnegative_assign(x, "0") in an iterative process? In this example, the unlikely is very, very, very unlikely (zzero(0) is not just likely, but totally likely). (I see that zsub_nonnegative_assign() may be removed.) How do these branch predictions behave if they are more likely to be incorrect than correct for certain use cases? Perhaps you could allow the user of the library a choice on the use of likely()/unlikely().

[maandree]

If the branch prediction makes a difference at all, and the branch predictions are bad, it will just mean that the performance is reduced a tiny bit. I have chosen to do manual branch prediction cause I don't believe the compiler is in a good position to do branch prediction here. If the user can do better branch prediction she can edit the code, I don't think add compile-time configurations is a good idea, that will become very messy very quick, and run-time configurations is worse and will decrease the performance.

My branch prediction is just what I think is likely to be the case, especially inside loops. In this example, I think it is very unlikely that a = b or b = 0, because the chance that two random numbers are equal or one of the zero is very small.

[textbrowser]

In the loop example, the probability of b being 0 is 1 so the prediction is not necessary. You could introduce a build option to mute the macros.

Thanks anyway.

[maandree]

The probably that you very such a loop in a serious numerical application is 0.
You can do some tweaking in /zahl/internals.h, but I will not add any options for doing so.