Симметричные кортежи из последовательных простых чисел

[Yadryara]

С некоторым запозданием комментирую. Вроде бы удобную систему обозначений предложил:

Длина-Диаметр-Номер.

Паттерны и известные минимальные чистые кортежи:

17-240-1   0  6 24 36 66 84 90 114 120 126 150 156 174 204 216 234 240
17-240-2   0 12 18 30 42 72 78 102 120 138 162 168 198 210 222 228 240
17-240-3   0 12 30 42 60 72 78 102 120 138 162 168 180 198 210 228 240

17-240-1   1006882292528806742267
17-240-2   24300494153317939112651
17-240-3   258406392900394343851

Возможно, стоит и другие паттерны обсчитать в 0-59#. И сделать табличку: прогноз-факт (чистые, все).

[Dmitriy40]

Yadryara в сообщении #1656754 писал(а):

С некоторым запозданием комментирую. Вроде бы удобную систему обозначений предложил:

Да, удобную. Но есть тонкости: номер назначается фактически наобум (никак не связан с самим паттерном (в отличие от длины и диаметра), только с сортировкой всего их множества); для многих паттернов номера ещё не назначены (скажем 17-252); кроме нас двоих такую нумерацию никто не поддержал, а я пишу всё же не только лично Вам; плюс к тому же я просто не помню их по номерам и могу ошибиться (ну 17-240-1 конечно помню, но другие нет) -- и потому мне не лень набрать лишних символов для пояснения какой из нескольких паттернов имею в виду.

Yadryara в сообщении #1656754 писал(а):

Возможно, стоит и другие паттерны обсчитать в 0-59#. И сделать табличку: прогноз-факт (чистые, все).

Думал над этим, для 17-240-3 даже весь 59# не нужен, хватит примерно 1/8 или всего часов трёх-четырёх счёта (или проще меньше суток на основном рабочем). Но для 17-240-2 размера 59# уже не хватает, надо 20.72% от 61#, а это исправление программы и главное больше 10 суток счёта. Не увидел в этом смысла. Проще поверить Врублевскому что найденные им кортежи минимальны, по крайней мере 17-240-2. С 17-240-1 задача ведь именно в этом была, проверить минимальность, грязные получились бонусом. А минимальность 17-240-2 и 17-240-3 никого особо и не интересует. А так можно и оба известных 17-252 начать проверять, и кучу остальных ... Жалко на это времени компов.

[Yadryara]

Не наобум, а лексикогрфически. Пока паттернов мало, проблем с этим нет.

Dmitriy40 в сообщении #1656764 писал(а):

для многих паттернов номера ещё не назначены (скажем 17-252);

Находим их все, а затем сортируем.

Dmitriy40 в сообщении #1656764 писал(а):

Думал над этим, для 17-240-3 даже весь 59# не нужен,

Dmitriy40 в сообщении #1656764 писал(а):

Но для 17-240-2 размера 59# уже не хватает,

А вот мне как раз для единообразия представляется логичным именно что весь 59# считать для всех трёх паттернов 17-240. И пусть для 2-го ни одного чистого не найдётся.

Но это не очень интересно, да. Мы и так знаем, что HL-1 прекрасно работает и для чистых и для всех.

[Dmitriy40]

Как и ожидалось, ночью нашлась вторая известная с августа грязная 19-252:
1791808741444077180184441: [ 0, 6, 12, 30, 42, -58, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222,-228, 240, 246, 252], len=21, valids=19
Кроме неё с 29.09 нашлись ещё 5шт valids=18, в том числе такая прекрасная:
152280801556172495686561: [ 0, 6, 12, 30, +42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246, 252], len=18, valids=18
Плюс нашлась интересная цепочка:
2818119519177428738516611: [0, 6, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 246, 252], n=17 - снова с симметричными пропусками, 17-ка с другим паттерном
И цепочка со всего одной дыркой (по версии НМ):
3321558363716512589630041: [0, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 190, 210, 222, 240, 246, 252], valids=18
С двумя дырками нашлось уже 8шт, из них 5шт с правильными концами.
На текущий момент проверено 17.0% от всего 67#.
Всего найдено 840К цепочек (логи 157М) с len>16, в том числе 66.4К с len=19 и 26.4К с len>19.

Интересно что цепочек находится непропорционально меньше чем старой программой, там на 21.6% было 3.77М цепочек, тут на 17.0% всего 0.84М, в 3.5 раза меньше, хотя должно быть одинаково. Я вижу две совместно влияющие причины: по прежнему в более грязных группах находится почти вдвое больше цепочек (сначала файлы были 30К более чистых vs 130К более грязных, сейчас 45К vs 100К); с возрастанием величины чисел количество цепочек должно уменьшаться так что 3.77М так велико из-за нахождения в нижней части всего диапазона 67#. Если первую причину видно просто по размерам файлов лога, то вторую проверил напрямую, подсчитав количество цепочек из 840К меньших 1.7e24, их оказалось 246К, вместо 0.216*840К=181К, в 1.36 раза больше, что вместе с увеличением логов пожалуй вполне даст нужный коэффициент 3.5, т.е. никакой аномалии на самом деле нет.

[Yadryara]

Yadryara в сообщении #1658118 писал(а):

Возможно, с новым компом буду вникать по новой.

Да, приобрёл новый комп и со вчерашнего дня помогаю Дмитрию. Скорость счёта на этом 6-ядернике оказался почти вдвое выше ожидаемой. Уже прикинул, что если не брошу помогать, то теоретически можно закончить обсчёт $0-67\#$ в начале марта, а не в конце мая.

Вот первая находка с 17-ю родными за почти сутки счёта:

3892856982464516840894047: [ 0, 6, 12, 30, +42, 72, 90, 96,-102, 120, 126,+132, 156, 162, 180,-186, 210, 222, 240, 246, 252], len=19, valids=17

Такие цепочки, то есть именно с len=19 и valids=17 я называю ранер-ранер. Бегом-бегом двигаем ровно два числа и вуаля

[Dmitriy40]

Добавлю, что я не понимаю откуда берётся двухкратное ускорение. Если только это не эффект гипертрейдинга. Но тогда AMD красавчеги! Даже с весьма неновыми архитектурами. Ибо у Intel гипертрейдинг даёт лишь около 20% ускорения, никак не 100%. Код программы идентичный.

[Dmitriy40]

Демис смог протестировать программу на современном процессоре Intel Core i7-14700K с 8 P-ядрами с гипертрейдингом и 12 E-ядрами без оного. Причём в двух вариантах, только на E-ядрах и на всех. Это позволило оценить вклад гипертрейдинга в общую скорость.
Итак, 12 E-ядер на 4.3ГГц посчитали тест за 3050с, а 8 P-ядер на 5.1ГГц плюс 12 E-ядер на 4.1ГГц посчитали тест за 1287с. Что даёт ускорение от гипертрейдинга в 80%. Это очень много.

И про 20% ускорения от гипертрейдинга я выше получается был не прав про новую программу, тесты показывают иное. Возможно это на старой программе было 20%.

Такой высокий вклад гипертрейдинга позволяет объяснить странно высокую скорость теста Yadryara на AMD Zen2 в 3394с, достаточно предположить что он разогнался от номинальной частоты 3.7ГГц до разрешённой турбо 4.1-4.2ГГц. Правда при полной загрузке всех 6 ядер, но с достаточным охлаждением почему бы и нет. Вклад гипертрейдинга оказывается 84-88%.

У меня на основном компе Core i5-4690 с 5 ядрами на 3.7ГГц тест показывает 10800с, что лишь на 1.5% хуже цифр Демиса.
На сервере на одном процессоре из двух с 16 ядрами с гипертрейдингом тест показывает 8560с в 8 потоков на 2.5ГГц, 5280с в 16 потоков на 2.02ГГц, 3800с в 32 потока на 1.89ГГц, что даёт вклад гипертрейдинга лишь 49%. А скорость уже на 9% хуже чем у Демиса. Какой-то немного странный у меня сервер получается.

[Yadryara]

Dmitriy40 в сообщении #1658599 писал(а):

Такой высокий вклад гипертрейдинга позволяет объяснить странно высокую скорость теста Yadryara на AMD Zen2 в 3394с, достаточно предположить что он разогнался от номинальной частоты 3.7ГГц до разрешённой турбо 4.1-4.2ГГц.

Он у меня разогнался до 3.82-3.84ГГц.

Между тем ситуация у меня исправилась. Мне пришлось считать почти сутки до первой цепочки с valids=17, зато после первой они посыпались, их уже 10 штук и распределение по длинам таково:

  Len  Found
   17      1
   18      3
   19      4
   20
   21      1
   22
   23      1
____________
          10

Насколько понимаю, сейчас счёт идёт в 25-й группе, самой чистой из не посчитанных.

VAL, где Ваши 24 ядра? Простаивают? Присоединяйтесь, нас ждёт мировой рекорд, если правильно понимаю, 19-252 ищут уже 10-й год и вот наконец-то есть реальный шанс.

[Dmitriy40]

Yadryara в сообщении #1658602 писал(а):

Он у меня разогнался до 3.82-3.84ГГц.

Это даёт вклад гипертрейдинга 100%. В такое не верится. Чего-то я всё же не понимаю в работе своей программы ...