Shmya Cluster - Задачи, состояние, перспективы
Информация
29.9.2019
Цитата: hoarfrost от 27.11.2019, 01:45Новость-примечание техническая
Если 4-й узел (на Ryzen 3600X) работает просто как обычный компьютер (только без корпуса), то ощущения от работы 5-го узла - разительно другие. Это маленькая тепловая пушка. Маленькая, но эффект от его включения в масштабах одной комнаты - выполне заметен, особенно когда отопление хоть и работает уже нормально, но всё равно чуть-чуть тепла не помешает. То есть тепла выделяется на самом деле много и кулер на 180 Ватт лишним не стал.
Если коснуться радиаторов на подсистеме питания, то сразу же руку - не обжигаешь, но и больше секунды - не продержишь. При этом, элементы на ASUS PRIME B450M-A (в 4-м узле) - ещё более горячие, но на них и радиаторов нет. Рядом с 4-м и 5-м каждым узлом поставил по вентилятору, вытягивающему воздух из околосокетного пространства. В ферме Shmya Cluster аналогичную роль играют вентиляторы на входе, формирующие входящий поток воздуха.
Новость-примечание техническая
Если 4-й узел (на Ryzen 3600X) работает просто как обычный компьютер (только без корпуса), то ощущения от работы 5-го узла - разительно другие. Это маленькая тепловая пушка. Маленькая, но эффект от его включения в масштабах одной комнаты - выполне заметен, особенно когда отопление хоть и работает уже нормально, но всё равно чуть-чуть тепла не помешает. То есть тепла выделяется на самом деле много и кулер на 180 Ватт лишним не стал.
Если коснуться радиаторов на подсистеме питания, то сразу же руку - не обжигаешь, но и больше секунды - не продержишь. При этом, элементы на ASUS PRIME B450M-A (в 4-м узле) - ещё более горячие, но на них и радиаторов нет. Рядом с 4-м и 5-м каждым узлом поставил по вентилятору, вытягивающему воздух из околосокетного пространства. В ферме Shmya Cluster аналогичную роль играют вентиляторы на входе, формирующие входящий поток воздуха.
Информация
30.9.2019
Цитата: atch от 29.11.2019, 15:09Цитата: hoarfrost от 24.11.2019, 19:07
- А может быть просто не задействуются все потоки? Да, включены все ядра и SMT, но просто часть потоков оставлена для чего-то ещё? Ведь часто так делают для того, чтобы быстрее выполнялись вычисления на GPU! Вряд ли, конечно, освобождено много потоков, но так может быть много и не надо?
Заметил такую вещь. Если нагружать CPU на полную, т.е. считать одновременно столько заданий, сколько и потоков у CPU, то результат будет наихудший. Время выполнения заданий может увеличиться на столько, что количество заработанных баллов станет уменьшаться. Поэтому практически к каждому проекту необходимо подбирать число одновременно работающих WU. Всегда находится такое число, ниже которого опускаться не имеет смысла. И оно совсем не обязательно будет равно количеству физических ядер - как правило, больше. Не знаю, с чем это связано. Пробовал мониторить разные датчики с помощью утилит (AIDA, Afterburner и пр.) в надежде, что увижу на каком-нибудь датчике загрузку в 100%, но увы, пришел лишь к сократовскому философскому выводу о нехватке знаний по теме, потому что о проблеме может говорить как 100% загрузка, так и наоборот, отсутствие 100% загрузки.
Сейчас при поиске подходящего числа одновременно работающих WU ориентируюсь на показания двух датчиков: загрузка CPU и загрузка GPU. На CPU загрузка должна быть хотя бы чуть меньше постоянных 100%. На GPU загрузка должна быть максимально, на сколько это возможно, ровной. По опыту уменьшение времени выполнения WU после такой "оптимизации" может составить процентов 5-10. Это всё про Intel и Windows.
Проект RakeSearch - один из не многих, который позволяет задействовать все или почти все потоки CPU (самый худший в этом смысле - какой-то подпроект WorldConnunityGrid), и основываясь на своих наблюдениях, мне казалось, что время выполнения WU в проекте практически не зависит от числа одновременно работающих заданий (повторюсь, на Интеле и под Windows). Поэтому уменьшение времени выполнения задания аж на 25% после уменьшения числа потоков CPU у коллеги звучит для меня крайне удивительно, почти шокирующее.
Что же это за "узкое горлышко", от которого в конечном итоге зависит время выполнения WU? Может, получится составить какую-то формулу для расчета оптимального количества потоков?
Цитата: hoarfrost от 24.11.2019, 19:07
- А может быть просто не задействуются все потоки? Да, включены все ядра и SMT, но просто часть потоков оставлена для чего-то ещё? Ведь часто так делают для того, чтобы быстрее выполнялись вычисления на GPU! Вряд ли, конечно, освобождено много потоков, но так может быть много и не надо?
Заметил такую вещь. Если нагружать CPU на полную, т.е. считать одновременно столько заданий, сколько и потоков у CPU, то результат будет наихудший. Время выполнения заданий может увеличиться на столько, что количество заработанных баллов станет уменьшаться. Поэтому практически к каждому проекту необходимо подбирать число одновременно работающих WU. Всегда находится такое число, ниже которого опускаться не имеет смысла. И оно совсем не обязательно будет равно количеству физических ядер - как правило, больше. Не знаю, с чем это связано. Пробовал мониторить разные датчики с помощью утилит (AIDA, Afterburner и пр.) в надежде, что увижу на каком-нибудь датчике загрузку в 100%, но увы, пришел лишь к сократовскому философскому выводу о нехватке знаний по теме, потому что о проблеме может говорить как 100% загрузка, так и наоборот, отсутствие 100% загрузки.
Сейчас при поиске подходящего числа одновременно работающих WU ориентируюсь на показания двух датчиков: загрузка CPU и загрузка GPU. На CPU загрузка должна быть хотя бы чуть меньше постоянных 100%. На GPU загрузка должна быть максимально, на сколько это возможно, ровной. По опыту уменьшение времени выполнения WU после такой "оптимизации" может составить процентов 5-10. Это всё про Intel и Windows.
Проект RakeSearch - один из не многих, который позволяет задействовать все или почти все потоки CPU (самый худший в этом смысле - какой-то подпроект WorldConnunityGrid), и основываясь на своих наблюдениях, мне казалось, что время выполнения WU в проекте практически не зависит от числа одновременно работающих заданий (повторюсь, на Интеле и под Windows). Поэтому уменьшение времени выполнения задания аж на 25% после уменьшения числа потоков CPU у коллеги звучит для меня крайне удивительно, почти шокирующее.
Что же это за "узкое горлышко", от которого в конечном итоге зависит время выполнения WU? Может, получится составить какую-то формулу для расчета оптимального количества потоков?
Информация
29.9.2019
Цитата: hoarfrost от 29.11.2019, 18:28Тут лучше говорить о конкретных процессорах. Если оставить в стороне тему с GPU (обеспечение его нагрузки - отдельная тема и в данном случае не имеющая к нам отношения - у нас GPU нужен для того, чтобы система запускалась), то как правило, увеличение числа считающих процессов до числа логических потоков CPU - даёт прирост. Но разный. В случае Intel и Hyper-Threading, выигрыш в валовой производительности обычно от 0% до 20% (но бывает и по другому). В случае с AMD и SMT - он значительно больше.
Поэтому ситуация когда человек на 12-ядерном и 24-поточном запускает всего 12 потоков, а время исполнения задания у него уменьшается всего на 25% - это очень хорошо, так как это значит что если мы нагрузим CPU на все 100%, то мы поднимем валовую производительность (по сравнению с 12 потоками) - в ~ 2*(1 / 0.75) = 1.5 раза.
Тут лучше говорить о конкретных процессорах. Если оставить в стороне тему с GPU (обеспечение его нагрузки - отдельная тема и в данном случае не имеющая к нам отношения - у нас GPU нужен для того, чтобы система запускалась), то как правило, увеличение числа считающих процессов до числа логических потоков CPU - даёт прирост. Но разный. В случае Intel и Hyper-Threading, выигрыш в валовой производительности обычно от 0% до 20% (но бывает и по другому). В случае с AMD и SMT - он значительно больше.
Поэтому ситуация когда человек на 12-ядерном и 24-поточном запускает всего 12 потоков, а время исполнения задания у него уменьшается всего на 25% - это очень хорошо, так как это значит что если мы нагрузим CPU на все 100%, то мы поднимем валовую производительность (по сравнению с 12 потоками) - в ~ 2*(1 / 0.75) = 1.5 раза.