Here are some short term objectives:

  - Check tifa_cofactor() on real cofactors from a number field sieve (dumps
    from CADO-NFS, for example). So far it has only been measured on
    synthetic cofactors: integers without small factors, of the sizes a
    sieve leaves.

  - Machine-specific parameters. The defaults of SIQS from 160 to 220 bits
    were retuned on an Apple M5 Pro and on GitHub's x86-64 runners (0.4.3);
    sweeping the factor base, the sieve width and the threshold on both, in
    November 2026, found them within 2% of the best everywhere, the machines
    disagreeing on the rest (a larger factor base at 190 bits on x86-64, a
    smaller one at 210). Tuning files (tifa-tune) can take that last 2% to
    3% on each machine. Above 220 bits the defaults are still extrapolated.

  - ECM on one to four limbs (mont_ecm.c), measured on 30 October 2026:
      - The setup of a curve takes 0.3 us (Z/2 x Z/8) to 0.6 us (Suyama),
        3% to 6% of a curve with B1 = 50 on two limbs, 1% with B1 = 800;
        its inversion is half of that. ecm() keeps the plans of its levels
        from one call to the next (0.4.2), where building them took 1 to 2
        us each for B1 up to 200 (about 3% at 100 bits).
      - The baby and giant steps of stage 2 are chains of dependent xadd,
        13% of ecm() at 100 bits. As two chains each (steps of 4.P and of
        2.d.P), their xadd in interleaved pairs, ecm() took 0.955 to 0.98
        of its time from 70 to 128 bits on the M5, but 1.04 to 1.23 on
        x86-64 with GCC (Zen 3 and Zen 5): the pairs spill there. Not kept.
        GCC's inlining of add and sub in these kernels also shifts with the
        size of mont_ecm.c: forcing it slowed x86 by 13% to 15% on three
        and four limbs.
      - Not faster: a dedicated Montgomery squaring in the ladder step
        (0.97 to 1.00 of stage 1); two curves interleaved in one step (0.68
        on one limb, whose numbers go to factor_u64 instead, 0.87 to 0.92
        on two, 0.95 to 1.00 on three and four).
      - tifa_cofactor's schedule (ecm_schedule.c) still runs Suyama's
        curves, retuned for them, where ecm() starts with the Z/2 x Z/8
        table.

  - SIQS, in shares of a run (November 2026, after 0.4.4): the sieve's fill
    55% to 75% from 160 to 220 bits, at about one cycle per hit on the M5;
    the bucket fill 15% at 220 bits on the M5, 19% to 20% on x86-64; at 180
    bits, the candidate pre-check and the candidates' values 6%, the batch
    smoothness test 7% to 9% and the trial division of the relations 3% to
    4%; the linear algebra 2% at 220 bits (FILTERED_GAUSS_ELIM).
      - The bucket fill with AVX-512 (0.4.6) compresses each vector of
        hits once per bin: from 225 bits, with 14 chunks per side or more,
        looping over the bins its lanes hit might keep more of its gain.
        Without AVX-512 the fill stays scalar. Bins of their own for the
        second roots, faster in a microbenchmark whose bins stayed in
        cache, were 1% to 3% slower in SIQS: measure such kernels with the
        caches flushed between runs.
      - The candidates the pre-check drops have their values u = a.x + b
        computed for nothing, and the trial division of the relations could
        start from the small primes the pre-check found: 1% to 2% at 180
        bits, perhaps.
      - The code of fill_sieve_chunk is sensitive to its layout on the M5:
        three instructions before its loops moved them and cost 3% at 150
        bits. Time 150 to 160 bits on the M5 after changing it.
      - Not faster: groups of medium primes with AVX2 (no better than SSE2)
        or NEON (slower on the M5); 128 KiB sieve chunks on the M5; testing
        128 bytes at a time in the scan; three-limb lanes in the batch test;
        trial division of every candidate instead of the batch test (1.06 of
        the time at 110 bits, 1.28 at 200), or testing them against the
        roots of their polynomial, four primes per NEON vector (not enough
        to pay for an x86 path); a retune of the parameters (see above);
        with the AVX-512 fill, buckets from 8192 to 32768 rather than 1.5
        chunks (49152), whose profile made them look cheaper per hit than
        the SSE2 groups: 1.00 to 1.03 of the time from 180 to 220 bits on
        two EPYC 9V74, 0.97 to 0.99 at 200 to 220 on an EPYC 9V45 (within
        2% of the noise there).
      - Double large primes: about 80000 candidates per 200-bit run have a
        cofactor between pmax^2 and the square of the large primes' bound,
        each costing 1 to 5 us to split; they are for larger numbers.
      - Threads: the collection of relations would split over several cores
        (the library is thread-safe), for its wall-clock time.
      - From seven primes in 'a', the approximer sorts up to 18424 triples
        of primes per run (0.5 ms, 0.5% at 170 bits): pairs, which fixed six
        primes, gave slower 'a' there, but finding the best triple without
        the table would keep the same 'a'.
