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

[Yadryara]

Кстати, может я неправильно считаю.

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

Юнит у них сейчас считается в среднем за 46.8 минут. Округлю снова в их в пользу — 40 минут.

Демис, Дмитрий, а что указано в этом самой графе "Время выполнения последних задач в часах: среднее, минимальное, максимальное"?

Может это в расчёте не на один комп, а на один поток? И тогда нужно 96 тысяч разделить примерно на 12 (моих потоков)?

[DemISdx]

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

Демис, Дмитрий, а что указано в этом самой графе "Время выполнения последних задач в часах: среднее, минимальное, максимальное"?

Если я правильно помню (пишу на память),
то там просто делается выборка, в разрезе (отфильтровывая) конкретного приложения.
Сиквельный запрос выполняется с параметром min (минимальное) и второй с параметром max (максимальное).
Получаются две границы.
И плюс от полученных значений считается среднее значение.
Наличие в min 0 или 0.01 - это однозначное наличие ошибок в приложении.
Которым уже полгода как.
И, судя по всему, никто не собирается их исправлять...
Как писала ТС "и так посчитают, подумаешь ошибки" (это на память написал, можете на форуме у нее найти дословное утверждение, но общий смысл передан).

-- 11.07.2025, 20:22 --

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

Плюс прямо жалко владельца сервера - 1.3млрд записей в БД займут терабайты. Так что сгенерить 1.3млрд вушек конечно не проблема, а вот сохранить их в БД, да ещё с выдачей их кранчерам и сохранением ответов от них - уже проблема.

Именно так и есть.
Подозреваю, что решаться этот вопрос будет как всегда "мне нужен еще один сервер".
А не приведением в порядок текущих расчетов.
Очень выгодная, позиция, кстати...
Напоминает "Вы мне плохую машину продали, у нее вечно бензин кончается!" ...

И все таки корректнее не устраивать панибратство

(Оффтоп)

а если есть необходимость то и процитировать источник:
https://boinc.berkeley.edu/forum_thread.php?id=15523&postid=116118#116118
You ignored everything I wrote to you but demand some special attitude to your project.
What is more important - you ignore your community.
If you want anything from anybody - be ready for cooperation.
Currently I see none.
That is not in our interest to make any exception for your project.

Что по нашенски выглядит так:
Вы проигнорировали всё, что я вам написал, но требуете особого отношения к вашему проекту.
Что ещё важнее — вы игнорируете своё сообщество.
Если вам что-то нужно от кого-либо — будьте готовы к сотрудничеству.
В настоящее время я не вижу никаких предложений.
Делать какие-либо исключения для вашего проекта не в наших интересах.

[Yadryara]

DemISdx, чего-то я не понял. Я хотел сравнить скорости работы программы Дмитрия на своём компе и скорости работы программы в приложении для 15-к.

Вроде бы это был простой способ — взять среднее время счёта юнита, которое публичное. Или оно некорректно посчитано из-за ошибок? Может, те задания для которых время 0, и не идут в зачёт, то есть не влияют на среднее время? Я спросил: это время для одного потока? Или это невозможно установить?

Или лучше скачать эту новую прогу для 15-к из приложения (где она, кстати?) и запустить на своём компе в один поток? Дмитрий вроде так делал с прогой для 17-к. И определил, что она в 700 тысяч раз медленнее.

DemISdx в сообщении #1693947 писал(а):

И все таки корректнее не устраивать панибратство

Вообще не понял, про какое панибратство и с чьей стороны речь.

Вы процитировали Виталия. Руководство Боинка в курсе. И Дэвид тоже наш форум читал.

[Dmitriy40]

DemISdx в сообщении #1693947 писал(а):

Сиквельный запрос выполняется с параметром min (минимальное) и второй с параметром max (максимальное).
Получаются две границы.
И плюс от полученных значений считается среднее значение.

Очевидно среднее считается по другому: "0.62 (0 - 7.5)" - 0.62 никак не равно среднему от 7.5 и 0.

Yadryara
Среднее время - это именно среднее время на вушку за некий период (24ч или 7д, вот тут не помню), т.е. сумма всех времён обработанных вушек поделённое на их количество.
Учитываются ли ошибочные вушки - не знаю. Но их не слишком много (надеюсь), можно проигнорировать погрешность, да и они же и в будущем так и продолжат валиться, так что оценка как раз правильная будет, независимо учитываются они или нет, исправлять же ошибки никто не собирается.

[DemISdx]

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

Вроде бы это был простой способ — взять среднее время счёта юнита, которое публичное. Или оно некорректно посчитано из-за ошибок? Может, те задания для которых время 0, и не идут в зачёт, то есть не влияют на среднее время? Я спросил: это время для одного потока? Или это невозможно установить?

Вы изначально спросили:

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

а что указано в этом самой графе "Время выполнения последних задач в часах: среднее, минимальное, максимальное"?
Может это в расчёте не на один комп, а на один поток?

И я дал ответ на этот вопрос.
Начнем с того, что потоки тут вообще не причем.
В том смысле, что наличие число потоков влияет только на "сколько времени" займет работа той или иной программы.
Но основным показателем будет именно "то самое время".
Берем три значения:
"Программа1", "задача1" и "потраченное время".
В БД проекта будут записи по вертикали примерно как:

"Программа", "задача", "время в минутах".
программа1,1,40;
программа1,2,0;
программа1,3,45;
программа1,4,35;
программа1,5,42;
программа1,6,54;

Выборка min по полю "время в минутах" даст значение = 0
Выборка max по полю "время в минутах" даст значение = 54
Ну и среднее еще посчитается исходя из числа строк.
Не важны потоки, важно время.
И все.

(Оффтоп)

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

Вы процитировали Виталия.

Я процитировал и дал ссылку. В отличии от Вас.

И напоминаю, что в развитии платформы boinc принимают активное участие много людей.
А не "только тот" или "только этот". Все они - разработчики.
Это сообщество, труд которого принимается и используется во всем научном мире.

(Оффтоп)

Нужно с уважением относиться к другим людям, а не хлопать по плечу, давай, давай...
А то, что разработчик (как представитель сообщества) выступил со своим мнением необходимо, на мой взляд, учитывать...
Это нормально, это этично.

-- 11.07.2025, 21:59 --

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

Учитываются ли ошибочные вушки - не знаю.

Не учитываются.
Т.е. ошибочные по расчету на клиенте просто не попадут в итоговую таблицу.

А вот те, которые сами по себе допустили ошибки (т.е. в математическом расчете проекта), вот те попадут.
Даже войдут в статистику. (И по ней тоже видно, что ошибки есть)
И именно они светятся на сайте, и их там очень много, десятки тысяч...
(Хотя может уже и сотни... Давно не смотрел.)

[Yadryara]

DemISdx в сообщении #1693957 писал(а):

Берем три значения:
"Программа1", "задача1" и "потраченное время".
В БД проекта будут записи по вертикали примерно как:

"Программа", "задача", "время в минутах".
программа1,1,40;
программа1,2,0;
программа1,3,45;
программа1,4,35;
программа1,5,42;
программа1,6,54;

Выборка min по полю "время в минутах" даст значение = 0
Выборка max по полю "время в минутах" даст значение = 54
Ну и среднее еще посчитается исходя из числа строк.

Считается средневзвешенное время? Вот так?

$$ \frac{40+0+45+35+42+54}{6}=36$$

Или вот так?

$$ \frac{40+45+35+42+54}{5}=43.2$$

Правильно ли понимаю, что один юнит с помощью программы на PARI можно обсчитать только в один поток?

[DemISdx]

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

Считается средневзвешенное время? Вот так?

Не могу ответить.
Используется в коде обычный avg, но как именно он считает "по математике", честно говоря - не изучал.
https://dev.mysql.com/doc/refman/8.4/en/aggregate-functions.html#function_avg

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

один юнит с помощью программы на PARI можно обсчитать только в один поток

На текущем коде - да.

Более того, судя по присылаемым ответам пользователей,
текущий код часто, но не всегда,
допускает запуск одного юнита на нескольких потоках одной машины одновременно.

Это тянет за собой богатый веер ошибок.
Что бред, но является фактом (до сих пор не исправленным с ноября месяца).
В логах это хорошо видно.

Но есть и положительный момент - это все превосходно размножается по всем приложениям.

[Yadryara]

Спасибо. Я вроде понял что прога Дмитрия быстрее в 7 тысяч раз. Потому что сейчас в Боинке среднее время счёта юнита — 37 минут.

Лучше конечно код Calc15Tuples у себя запустить и засечь время. Он есть в открытом доступе?

DemISdx в сообщении #1693967 писал(а):

Но есть и положительный момент - это все превосходно размножается по всем приложениям.

Шутка такая? Надеюсь, Вы не желаете этому проекту зла.

[DemISdx]

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

код Calc15Tuples у себя запустить и засечь время. Он есть в открытом доступе?

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

Один раз (одно приложение, кажется самое первое) что-то было опубликовано, фиг знает где и все.

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

Вы не желаете этому проекту зла

Да нет наверное.
Я радуюсь за него...

DemISdx в сообщении #1693967 писал(а):

допускает запуск одного юнита на нескольких потоках одной машины одновременно.

Когда тестировал увидел, что параллельный поток умудряется переписывать строку с ответом.
Красиво же.
Как будто ничего и не найдено в задании...

[Yadryara]

DemISdx в сообщении #1693969 писал(а):

Один раз (одно приложение, кажется самое первое) что-то было опубликовано, фиг знает где и все.

Демис, я нашёл:

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

Разница в скорости по скорости проверке диапазона: 5.1e19/7e13=730 тысяч раз.

Но нашёл я хитрым способом. Сам я этого поста не вижу, только фрагментик! (Мои проблемы с интернетом так и остались при мне.) Так вот, вроде в том посте Дмитрий даёт ссылку на код.

Но если кода нового приложения в открытом доступе и правда нет, то это вроде как нарушение правил Боинка.

[DemISdx]

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

Сам я этого поста не вижу, только фрагментик! (Мои проблемы с интернетом так и остались при мне.)

Это конечно не есть хорошо.

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

это вроде как нарушение правил Боинка.

Это так.

По ссылке Дмитрия откроется пост в котором другая ссылка, на ядиск, а не сам код.
Причем код ручного приложения.

Если почитать там посты найдутся и сами коды.
Но опять-же ручных приложений, а не проекта.

Но как тогда определить однозначность, применяемого в проекте, кода?
Никак.

Установить какой именно код работает в том или ином приложении - невозможно.

Как проверить код пари или его обвязки (для компиляции в составе проекта) на ошибки?
А никак.
Тайна за семью печатями.

Еще раз:

DemISdx в сообщении #1693969 писал(а):

у проекта не было опубликованного и упорядоченного кода.

Полагаю, что ТС не заинтересован в этом.
Ведь будут носом тыкать, а изменять что-то в лучшую сторону не моГет.
Лучше афрокопством заниматься...
Нет у нее задачи что-то найти.
Ехала болела...

Учитывая, что вроде начались попытки что-то там поэффективнее посчитать, спустя 9-ть месяцев,
то такими темпами до кода доберется лет через десять...
Ничего страшного.

-- 12.07.2025, 12:50 --

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

Очевидно среднее считается по другому: "0.62 (0 - 7.5)" - 0.62 никак не равно среднему от 7.5 и 0.

Да.
Вы правы.
Считается по функции avg в прямо в запросе, т.е. используется встроенная функция мускула для запросов.
Исходник на сегодня:
https://github.com/BOINC/boinc/blob/501570127b9df08baded0ec1f663acaf5d37b1b1/html/user/server_status.php#L419

[Yadryara]

Насколько помню, на тот момент код был опубликован именно на Боинке, как полагается.

И сильно подозреваю, что убран он по очень простой причине. Именно чтоб мы не могли его у себя запустить, сравнить, увидеть гигантский проигрыш в скорости счёта и вновь опозорить ТС. На самом деле это не очень-то позорно — очень мало кто умеет писать настолько быстрые программы как Дмитрий.

Можно конечно зарегаться как кранчер и получить рабочую программу. Но на кой такая возня. Я уже и так оценил по времени счёта. Сейчас, поскольку время обсчёта юнита снизилось до 33 минут — в 6 тысяч раз медленнее, чем один поток на моём компе.

Плюс, поскольку 15-ки обсчитаны хорошо, можно оценить скорость счёта по результатам. 1100 15-к делим на 432 месяца, получаем средний темп — 2.5 кортежа в месяц. Это в предположении, что по 100 тысяч юнитов в сутки смогут обсчитывать. Если не смогут, тогда и находить будут в среднем меньше.

На всякий случай, если кто-то не понимает или притворяется что не понимает: они будут находить по две с половиной 15-ки в месяц именно в среднем. То есть вполне возможно, что ни одной в месяц, а в какой-то месяц могут и 5, и 10 найти.

Так вот, если будут находить явно больше чем этот мой прогноз, значит скорость счёта у них выше.