Форум

Пожалуйста or Регистрация для создания сообщений и тем.

О проекте SiDock@home

PreviousPage 45 of 46Next

hoarfrost,  А что у нас с длинными заданиями? У меня на 2-х машинках по двое суток считались.. всё застряло на 99,2%.

А дедлайн 12-го января.  Как Вы рекомендовали,  сделал на компиках logoff-logon. После чего,  задания завершились и ушли на сервер проекта. Но сидеть нянькой для остальных заданий проекта - какбэ не вдохновляет. Сообщите нам, если что-нибудь изменится.

 

Array

Если такие задания попадуться ещё, то посмотрите пожалуйста, каким приложением они считаются: "CurieMarieDock on BOINC + zipped input, checkpoints and progress bar" или же "CurieMarieDock 0.2.0 long tasks"?

Если вторым, то пришлите каким-либо образом название workunit-а, я проверю его расчёт у себя, попробую также "зациклить".

Спасибо!

P.S. Задания для текущих мишеней 2 суток считаться не должны. На Ryzen-е где-то от 3 до 8 часов (но это уже редкость), в основном - от 3 до 5 часов для TMPRSS2 и часа полтора для Sprot.

Array

И небольшое пояснение про новое приложение. Мы его назвали "CmDock 0.2.0 Long tasks" для того, чтобы оставить себе возможность завести ещё одно приложение - "CmDock 0.2.0 Short tasks", не ломая "систему названий". Если второе приложение появится, то оно будет идентично первому, но для него мы будем создавать более короткие задания, например не из 500 лигандов, а из 100 или 200, что может быть удобно для одноплатных компьютеров и прочих не очень мощных устройств.

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

Array
V0d01ey отреагировал на эту запись.
V0d01ey

Интересное наблюдение участника Bryn Mawr про зависание заданий. Он связывает это с недостатком памяти.

Array

Мы переходим к реализации варианта, описанного чуть выше. Создано приложение "CmDock 0.2.0 short tasks", предназначенное для одноплатных компьютеров на основе ARM. В ближайшие 1 .. 2 дня мы продолжим рассылать одинаковые по размеру задания вида "Sprot_delta_v1_*_RM" для обеих приложений, так как они достаточно короткие и для того, чтобы быть запущенными на одноплатных компьютерах - на RPi 4 задачи выполняются за ~24 000 секунд, на RPi 3 Model B за ~ 55 000 секунд (с некоторыми выбросами).

Через примерно пару дней проект начнёт рассылать задания для новой мишени (о ней мы расскажем отдельно). Сначала это будет короткая выжимка размером в ~1% от полного размера библиотеки и выполнятся она будет только в виде "длинных задания", которые будут действительно длинными - 12 и более часов для Ryzen! Обработка подобной выжимки нам нужна для оценки удачности параметров расчёта, которые будут использоваться для расчётов по всей библиотеке. В это время, для "short tasks" будут продолжать выдаваться задания для мишени Sprot*RM.

После начала раздачи обычных заданий для новой мишени (о ней мы напишем чуть позже) для приложения "long tasks" будут выдаваться задания обычного размера, а для "short tasks" - в 5 раз меньшие по числу лигандов, которые будут покрывать свою часть библиотеки.

Возможно, что в "long tasks" задания будут отправляться с одного конца бибилиотеки, а в "short tasks" - с другого. Но возможны и другие варианты. Какой из них возьмём на вооружение - посмотрим! В любом случае - очень интересно сколько будут выдавать "малинки" и их собратья.

Array
Pavel Kirpichenko и AenBleidd отреагировали на эту запись.
Pavel KirpichenkoAenBleidd

Привет всем.
Когда-то давно тут уже регистрировался, но не смог найти учетку. Попробовал запросить восстановление на все свои почтовые ящики - пишет нет такого пользователя. Была что-ли чистка давно неактивных пользователей за прошедшие годы? Ладно, буду значит новичком-новорегом тогда...

Не знаю может уже задавали вопрос (пару последних страниц с сообщениями за последние месяца 3 просмотрел только)...

Можно немножко провести тюнинг приоритета выполнения основного рабочего приложения (не обертки) на Windows платформе?

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

Замечал это уже очень давно (полгода минимум назад уже было такое, т.е. это не в последней версии появилось, вероятно вообще изначально так и было) - что если считается на компьютере SiDock, то производительность GPU расчетов сразу проседает. Отключаешь SiDock заменив его на какой-нибудь другой CPU-only проект - производительность GPU возрастает обратно.

Не то, чтобы критично, но на 10-25% просаживается, что довольно неприятно. А с учетом того, что GPU cчитают во много раз быстрее CPU, эти 10-20% просадки вообще могут быть больше чем все то, что успел SiDock насчитать на CPU и общий объем полезной выполненной работы(не для конкретного проекта, а суммарно по всем к которым подключен компьютер) был бы больше если бы он вообще ничего не считал.

Очевидную вещь - что просто приложение SiDock работает не с наименьшим (фоновым) приоритетом я проверил еще когда первый раз это заметил. Но не в этом было дело - хотя его процесс-"обертка" работает с нормальным (не пониженным - 8/normal) приоритетом, но она ресурсов процессора практически не потребляет (кроме моментов запуска/завершения задачи) и следовательно это влиять не должно. А основной расчетный модуль (cmdock.exe) работает как и положено с фоновым минимальным приоритетом (=4/idle).

Тогда в прошлом году я "решил проблему" очень просто - отключив SiDock со всех своих компьютеров и заменив его на CPU задания из WCG и Einstein@Home, которые не тянут ресурсы на себя от GPU.

Но сейчас после того как вернулся в проект дошли руки посмотреть подробнее в чем же там все-таки дело.  И оказалось дело в приоритете не процессов, а нитей вычислений (thread) назначенных внутри cmdock.exe.  Точнее в данном случае нить одна единиственная. И работает она с приоритетом =4, а это совсем не минимальный приоритет для нитей. Для нитей минимальный/фоновый приоритет = 1. И именно с приоритетом = 1 подавляющее большинство BOINC приложений и работает, а SiDock из-за большего выставленного приоритета тянет у них ресурсы на себя. И если для CPU-only проектов это особого значения не имеет, т.к. общая (суммарная) производительность от этого не снижается, а только слегка перераспределяется между проектами.

То с GPU вычислениями это важно, т.к. общая производительность компьютера из-за этого снижается - из-за "обкрадывания" CPU части GPU приложения, она не всегда успевает вовремя поставлять данных на GPU и количество и продолжительность моментов его простоев/работы с неполной загрузкой увеличивается и как следствие время счета заданий для других проектов работающих на GPU.

На скринах пример работающего SiDock и для сравнения Mapping Cancer Markers из WCG (но аналогично почти во всех CPU приложениях для BOINC настроено)

Загруженные файлы:
  • sidock.png
  • wcg.png
Array
hoarfrost, V0d01ey и _tribal_ отреагировали на эту запись.
hoarfrostV0d01ey_tribal_

Привет!

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

Здесь же отвечу на вопрос про GPU. (На форуме проекта тоже напишу, но более кратко). Про них все прекрасно знают и разработчики CmDock-а в том числе. Заявления о том, что его попробуют сделать были, насколько помню, чуть ли не с момента запуска проекта, но его до сих пор нет. Лично я исхожу из того, что в обозримом будущем его не будет и ещё неизвестно что будет раньше - появится приложение для GPU или проект завершит свою работу (а когда-нибудь это случится, ничего вечного не бывает). Не добавляет оптимизма и почти тотальная "огрызочность" современных дектопных GPU, добравшихся в double до уровня Radeon 7970 только в 2021 году (в случае AMD) и начале 2023 года, в виде GeForce RTX 4090, в случае NVIDIA. Если, конечно, не считать Radeon VII и TITAN V.  Но это уже детали, а основная причина, подозреваю, что алгоритмическая.

 

Array

Немного о 22-й мишени - "corona_RdRp_v2"

RdRp - это сокращение от "RNA-dependent RNA polymerase" - это фермент, выполняющий репликацию РНК вируса (а ДНК у них как правило нет). Если ранее производилось что-то вроде общего исследования этого белка, то теперь решено обратить внимание на отдельные его участки, наиболее важные для его работы. Один из них - это участок NSP12 называющийся так потому, что он является неструктурным белком (см. non-structural protein) - то есть белком, который кодируется РНК вируса, но не входит в его состав самой вирусной частицы. NSP12 обеспечивает "плетение" новой цепочки РНК и ранее исследовалась возможность подавления его работы такими соединениями как ремдесивир, галидесивир, молнупиравир и др.

Побольше можно прочитать в Wiki:
https://ru.wikipedia.org/wiki/РНК-зависимая_РНК-полим..
https://ru.wikipedia.org/wiki/Рибонуклеиновая_кислота
https://ru.wikipedia.org/wiki/Транскрипция_(биология)

или следующих статьях:
Structure of replicating SARS-CoV-2 polymerase

Identification of novel SARS-CoV-2 RNA dependent RNA polymerase (RdRp) inhibitors: From in silico screening to experimentally validated inhibitory activity

RNA dependent RNA polymerase (RdRp) as a drug target for SARS-CoV2

Ribavirin, Remdesivir, Sofosbuvir, Galidesivir, and Tenofovir against SARS-CoV-2 RNA dependent RNA polymerase (RdRp): A molecular docking study


Полимераза RdRp (бело-серого цвета) и цепочка РНК с молекулой N4-гидроксицитидин (красная молекула) из молнупиравира, которое мешает работе полимеразы по построению РНК новой копии вируса.

P.S. Та же новость, но в группе проекта в VK.

Array
V0d01ey и Шмяка отреагировали на эту запись.
V0d01eyШмяка

Как вы, возможно, уже знаете, на НСКФ-2022 был доклад Марко Юкича о научной основе проекта. Организаторы выложили его на YouTube, можно посмотреть вот здесь: Modern medicinal chemistry collaborative research projects on SARS-CoV2.

Array
Шмяка отреагировал на эту запись.
Шмяка
Цитата: hoarfrost от 26.01.2023, 01:55

Привет!

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

Ну я же вроде четко и подробно написал, что не в приоритете самой программы (процесса) cmdock дело. Сам процесс получает приоритет от процесса-облочки при запуске, да. И это как уже написал это как раз происходит корректно - назначается низший(фоновый) приоритет процесса = 4.

А дело в приоритете нити/потока вычислений (thread) внутри процесса cmdock. Которых вообще внутри одного процесса может быть много, хотя в данном конкретном случае поток вычислений в процессе только один.  Это задается еще при программировании: http://programming-lang.com/html/visual_studio.net/glava12/index8.htm. В отличии от приоритетов процессов, задаваемых "на лету" - при запуске или даже у уже запущенного процесса средствами ОС его можно менять. А вот приоритетом потоков внутри своей программы управляет программист.

В общем в других проектах и приоритет процесса - idle и приоритет основного счетного потока в нем - idle и как итог реальный приоритет вычислительных потоков =1 (низший из всех возможных, считаем только когда процессору уже больше нечего другого считать, делается это так чтобы ничем всему остальному работающему на компьютере никак не мешать и забирать только действительно неиспользуемые ресурсы - те, которые иначе просто уходили бы простой) .
А у cmdock.exe приоритет процесса - тоже idle, а вот приоритет потока - normal, что дает приоритет потока = 4 (normal приоритет потока наследуется от приоритета процесса).

Array
PreviousPage 45 of 46Next