YadryaraПро разные шаги я бы сказал так:
1. Для паттернов с двумя и более квадратами величина шагов не актуальна, они проверяются Пеллем очень быстро (доли секунд).
2. Для паттернов с одним квадратом величина шагов тоже не актуальна, их проще проверять квадратичным перебором. Причём не по каждому простому, а там легко накладываются достаточно неплохие ограничения на это простое и потому перебор идёт с большим шагом (от сотен тысяч до миллиардов). Не всегда он укладывается в секунды и часы (для 14 и 15), но нескольких суток вроде хватает. Да и паттернов таких весьма немного. Макарова кажется почти все их уже проверила.
3. Паттерны без квадратов. Вот тут глухо. Перебор ускорителем даже до 2e33 даже для наибольшего шага требует порядка трёх суток и соответственно порядка 4 месяцев до 8e34. Для меньших шагов время растёт пропорционально. Подключение квадратичных переборов требует перебора простых до порога -p, который для 14 составляет примерно 4.3e15, а для 15 примерно 2.7e16 (все qr<106 запрещены или проверены до конца). Это слишком много. Это многовато даже для 13, где порог примерно 2.3e12 (qr<118 запрещены или проверены).
А кто-нибудь занимается понижением этого порога?
Без понятия. Чем занимается Хуго информации в открытом доступе не видел. А остальные похоже даже не в курсе как и чем и зачем можно уменьшать порог (готовую программу Хуго не даёт, только исходник) ...
Я несколько раз порывался запустить счёт, но каждый раз увидев оценку времени понимал что выгоднее поступать по другому: каждое конкретное значение qr будет проверяться примерно сутки (здесь и далее везде для счёта в один поток), разных qr<600 чтобы получить -p1e12 (что всё равно слишком много) примерно 150 штук, т.е. грубо надо 5 месяцев на такое уменьшение порога, но очень многие из этих qr или запрещены, или можно проверить относительно быстро (сильно быстрее суток), но надо для каждого руками проверять какие разрешены (программа выходит слишком сложной) и писать отдельную программу перебора (универсальная опять же выходит слишком сложной).
Пытался подойти к этому вопросу с другой стороны: перебрать на асме быстро все большие простые (которые дают и шаг паттерна и начальное число больше порога, ведь это 99% всего квадратичного перебора), но вычисление обратного элемента в кольце по модулю страшно медленно даже на асме, PARI применяет КТО со скоростью примерно 2e7/c (везде указываю интервал, не штуки), а асм простые генерит почти 1e9/c, но обратный элемент (нужный для КТО по схеме Гарнера) лишь 4e7/c, всего вдвое быстрее PARI, это грустно. К счастью обратный элемент можно вычислить лишь один раз для каждого простого в квадрате и каждого шага (он из этой пары и вычисляется), независимо от паттерна с таким шагом, а дальше или быстрые умножения или даже и без них, но это значит встраивать в цикл перебора простых ещё и перебор шагов паттернов, а потом ещё и перебор самих паттернов и возможных мест в них, что совершенно очевидно заметно замедлит и без того медленный перебор простых с вычислением обратного элемента, т.е. скорость упадёт с 4e7/с до скажем 1e7/с и на перебор простых до 2.3e12 понадобится дня три (хотя скорее неделя-две), плюс проверка не отброшенных простых в PARI. Зато это позволит уменьшить порог практически до 1e9-1e10 (как только доля подходящих простых упадёт до долей процента). Ценой встраивания в асм код двух дополнительных циклов по реальным паттернам (от них нужно как минимум начальное число до подстановки дополнительных простых, а лучше и список допустимых мест). При этом на PARI ровно тот же перебор возможных мест в паттернах с однократным вычислением обратного элемента идёт со скоростью 5e6/c (для 5-ти мест, что довольно часто), так что ускорение от переписывания на асм похоже менее чем двойное, а трудности многократные. На PARI перебрать простые до 2.3e12 потребует порядка недели на каждый из 3000 паттернов ... Возможно на асм снижение скорости будет не таким сильным, но она в любом случае не превысит скорости вычисления обратного элемента 4e7/с, т.е. для вычисления всех обратных элементов для p<2.3e12 и 20 разных шагов надо порядка двух недель, ну и плюс проверка начального числа, в итоге несколько месяцев, в принципе достижимо ...
Есть и другая идея: каждое конкретное qr допустимо не для каждого паттерна, некоторые или попадают на занятые места, или не дают нужных остатков по уже расставленным простым. Конечно это как раз и есть те запреты выше, но возможно проверить конкретное qr по списку конкретных паттернов будет проще чем пытаться запретить qr для любых. Но эта идея пришла только вчера и реализовать пока не успел, прикидочная оценка даёт что для qr=106 для 13-ек из 3408 паттернов подходит около 400, в остальные
не вставляется. Это хорошо, возможно получится написать более-менее универсальную программу перебора для каждого qr только подходящих паттернов, ведь там в каждом можно наложить сильные ограничения на
и перебирать их с большим шагом (как и делал руками, а тут будет автоматически). Насколько это просто и выгодно оценок пока не сделал.
Но всё это практически неприменимо к 14 и 15, слишком велик там порог -p, надо выдумывать что-то ещё. Даже просто генерация простых до 2.7e16 займёт порядка года, а ещё ведь по любому надо делать гораздо более медленные проверки ...
И пока совершенно непонятно куда бы тут эффективно прилепить SSE/AVX (кроме одного места с проверкой мест паттернов после вычисления обратного элемента в кольце по модулю). А без SSE/AVX скорость как-то не сильно от PARI отличается и за что тогда бороться непонятно.