Maybe test an idea: cell pool for bignums

[jpellegrini]

I tested removing the allocation of mpz_t and reusing the old cell in abs (which is wrong, I know, it's just for understanding the impact), and the code ran 10x faster.

So maybe we could have a bignum pool?

i don't know if what is costly is allocating, initializing, or both... But we could try.

[jpellegrini]

But it would likely require a separate pool array (because mpzs should be initialized in a specific way), and that would possibly imply difficulties for bootstrapping. No?

[egallesio]

I think I don't understand what you want to do

• mpz_t are generally not (directly) heap allocated, but stack allocated.
• bignum_objs (which contain a mpz_t) are heap allocated but since their size is small (it is the size of a cons on my machine), they already in the pool of cons, and all xxx_obj` whose size is 3 words.

But I have perhaps not understood the use case you are thinking of.

[jpellegrini]

I wasn't clear at all, sorry.

This is what I mean: if you change, in the code for àbs`, this:

    case tc_bignum:   if (mpz_sgn(BIGNUM_VAL(x)) < 0) {
                        mpz_t tmp;

                        mpz_init(tmp);
                        mpz_neg(tmp, BIGNUM_VAL(x));
                        x = bignum2scheme_bignum(tmp);
                        mpz_clear(tmp);
                      }
                      return x;

into this:

    case tc_bignum:   if (mpz_sgn(BIGNUM_VAL(x)) < 0) {
                        mpz_neg(BIGNUM_VAL(x), BIGNUM_VAL(x));
                        return x;

then it obviously becomes incorrect.
However, it is 10x faster. I wanted to understand why, and if it's possible to alleviate the slowness here.
I don't know if it's mpz_init or bignum2scheme_bignum that is slow (maybe both), but it certainly is one of those...