Новости проекта RakeSearch
После обработки первой партии заданий с приложением, скомпилированном на Эльбрусе-8C и использовавшимся как "анонимное", была сделана попытка зарегистрировать его в проекте, привязав к новой платформе, которую мы назвали e2k-linux-gnu (в соответствии с принятым в BOINC подходом), после чего перейти к расчётам в штатном режиме, без app_info.xml.
Зарегистрировать в рамках проекта новую платформу удалось, как и приложение для него. Так что теперь в RakeSearch есть официальное приложение для Эльбрусов! По крайней мере - для 8C и более поздних версий.
С запуском расчётов получилось интереснее. Когда app_info.xml был убран, BOINC-клиент - перезапущен и стали получаться новые задания, то они сразу же стали падать с ошибкой Error while downloading. Ошибка, насколько я сейчас вижу, связана с тем, что после скачивания файла расчётного модуля, клиент начинает проверять его соответствие подписи, приходящей с сервера проекта (это делается для безопасности)... и эта процедура почему-то этого соответствия не подтверждает. При этом сам файл скачивается корректно, его контрольная сумма совпадает с файлом на сервере... и тем же самым файлом, который лежит в соседнем каталоге и который и стал официальным приложением. 
Почему возникает такая ситуация - пытаюсь понять. Её удалось обойти путём ручного редактирования файла client_state.xml (файлу расчётного модуля, который был уже коректно загружен, но не мог пройти проверку, я просто сопоставил статус 1 - о том, что с ним всё в порядке), после чего расчёты стали запускаться и на данный момент, 7 результатов уже прошли проверку. Ещё 5 - её ожидают, ошибочно посчитанных - нет. Посмотреть на сам компьютер и результаты можно зайдя в свойства компьютера 9813.
Немного о производительности, которая, безусловно, интересует всех. В данный момент, страничка Compare для этого компьютера не отображает актуальных данных из-за того, что во время обработки первой партии заданий мы, как уже говорил, столкнулись с аномалиями в поведении BOINC-клиента, вызванными, возможно, тем, что он пытался обращаться к подсистеме X11 (даже работая только в виде фонового приложени, без графической оболочки), а нормальная работа самой X11 была нарушена одним из процессов, работающих из-под root. Из-за подвисаний клиента, он не мог корректно учитывать время вычислений, из-за чего правильно учтённым, на нынешний момент, оно является примерно у последних 15. При этом сами расчёты проходили корректно. Примерно дня через 3, когда первая партия результатов (а заодно - и "ошибки загрузки") - уйдут в архив, страницей Compare можно будет пользоватся.
А о предварительных результатах на основе корректных данных (которые в некотором объёме уже есть) - чуть позже.
Божественно! Больше экпериментов с боинком на эльбрусе!
Наш проект RakeSearch попал на конкурс научно-популярных работ молодых учёных Карельского научного центра РАН! Намного красивее и интереснее об этом - написано на страничке основателя проекта. Победитель определяется голосованием в группе совета молодых учёных, проходящим до 19 января.
Цитата: hoarfrost от 30.12.2019, 23:42Цитата: Yura12 от 30.12.2019, 21:38И ещё 1 смежный вопрос - а ведутся ли сейчас работы, чтобы сделать приложение для R10 для счёта на видеокартах NVidia или AMD?
Возможно, Panda поделится новостями. Насколько я вижу, GPU-образно алгоритм не параллелится, были попытки запустить на GPU очень много заданий одновременно.
Получилось запустить на одном ГПУ одновременно 128 заданий (gt 1030). Время выполнения всех заданий более недели. Ускорение удалось получить на уровне 10-11 раз по сравнению с fx-8300.
Долго выполняются задания по причине того, что при параллельном запуске множества заданий часть из них конкурирует за ресурсы видеокарты и находится в ее памяти. Решение проблемы найдено: расчётной приложение должно нумеровать потоки, чтобы они не конкурировали за ресурсы.
Небольшая подборка новостей проекта за последнее время
1. Были подведены итоги первой половины и декабря в целом.
2. В личный кабинет участников добавили ссылку на статью с описанием проекта, вышедшую в рецезируемом издании Communications in Computer and Information Science.
3.Подвели итоги и первой половины января. Январским значком стал иней:
4. Выпустили официальное приложение для платформы Эльбрус + Linux! В данный момент оно работает как миниум на 3 вычислительных машинах.
5. Проект RakeSearch (в лице организатора - Наталии Никитиной) принимает участие в конкурсе научно-популярных работ молодых учёных Карельского научного центра РАН! И те, кому неравнодушны распределённые вычисления - могут его поддержать в голосовании, которое продлится до конца 19 января!
А теперь график процессорного времени (и, одновременно числа потоков, активных в рамках проекта), с начала поиска R10 до 10 января:
А теперь - про прозводительность Эльбруса!
Несколько дней назад, багодаря Игорю, был получен доступ к машине с 4(!) Эльбрус-8C, что позволило оценить производительность подобной системы в рамках нашего проекта не косвенным, а прямым методом. И это очень интересно! В том числе и потому что очень большое число прикладных задач из коммерческого сектора, связанных с базами данных, web-серверамии т.п. в основном выполняют операции не с плавающей точкой (хотя и их бывает немало), а с целыми числами. И вот теперь, у нас уже есть первые проверенные результаты - компьютера № 9991.
Для начала однопоточная производительность. Сама по себе она мало что значит, но можно сделать некоторые выводы.
Что мы видим - с одной стороны, скорость вычислений "на одном потоке" в Эльбрус-8C проигрывает современным десктопным процессорам (они отмечены зелёным цветом) в 2-3 раза, в некоторых случаях - до 4-х (только у этого Core i7-8700K - отключен Hyper-Threading!). Однако при сравнении с серверными процессорами (выделены синим цветом), разрыв уменьшается - до 1.5 - 2 раз, так как их частоты - значительно ниже. Но в них - больше ядер и потоков. А в Эльбрусе - частота ещё ниже - всего 1.30 ГГц, и если мы это учтём, то увидим, что производительность на такт у него как минимум не хуже, чем у лучших десктопных и серверных процессоров.
И, самое интересное - валовая производительность (в квадратных скобках после модели CPU идёт число потоков, опознанных BOINC-клиентом):
Смотря на эту диаграмму, надо понимать, что вы видите. Это не производительность отдельно взятого(ых) процессора(ов), это производительность систем, которые были сделаны на их основе. В случае с десктопными процессорами (также отмечены зелёным) - в системе может быть только 1 CPU. В случае серверных систем на основе Xeon E5 - до двух CPU. А вот в случае с Эльбрус-8С в сервер можно поставить и 4 процессора! И это существенно уменьшает отставание в ситуации, когда у того же Xeon E5-2683 v3 на один сокет приходится 14 ядер (и 28 потоков), а у Эльбруса - 8. Двусокетной машине с 28 ядрами, уже сейчас можно сопоставить машину на Эльбрусе с 32!
Из диаграммы ясно видно, что хотя существующие модели не смогут конкурировать с десктопными системами ни по производительности ни, скорее всего, по цене (официальных цен нет, но по интернету гуляют примерные цены). В этом нет никакой интриги. А вот в серверном сегменте ситуация - куда интереснее - система, аналогичная серверу с 2 x Xeon E5-2683 v3 будет стоить где-то $10 000 .. $12 000 и, возможно, что в отдельных секторах этого рынка Эльбрусы могут составить конкуренцию уже сейчас. В случае же, реализации планов по наращиванию числа ядер (в Wiki говорят о вариантах с 16 и 32 ядрами) и частот, ситуация может стать ещё лучше.
По мере работы системы статистика будет накапливаться и, будем надеется, мы увидим ещё немало интересного!
Думаю, что к диаграммам выше стоит добавить ещё одно пояснение - про параллельность внутри потока. Если мы посмотрим на любую программу, то скорее всего увидим, то даже в "исключительно однопоточном" в силу алгоритма коде, далеко не все операции (или строки кода) процессор обязан выполнять строго последовательно. Например, в одной из двух основных по времени работы функций в расчётном модуле R10 есть вот такие строчки:
...
<начало цикла>
rowId = path[cellId][0];
columnId = path[cellId][1];
isGet = 0;
cellValue = Square::Empty;
freeValuesMask = (1u << Rank) - 1;
freeValuesMask &= flagsColumns[columnId] & flagsRows[rowId] & flagsCellsHistory[rowId][columnId];
...
Первые четыре из этих строк - описывают действия, полностью независимые друг от друга! Шестая - зависит от пятой, но, по сути, они могут быть склеены в одну строку, состоящую из нескольких операций, часть из которых также может быть выполнена параллельно! То есть, в рамках нашего алгоритма есть возможность распараллеливания на уровне отдельных инструкций. Но, в тоже время, число подобных действий - невелико, в пределах 5-10, что, скорее всего, позволяет неплохо задействовать эти возможности в современных процессорах от AMD и Intel, которые могут выполнять как раз где-то около 5-8 инструкций одновременно, но лишь частично задействует возможность Эльбрус-8C в котором число одновременно выполняемых инструкций может достигать 25! А это значит, что в задачах с более высокой степенью "внутреннего параллелизма" соотношение может изменяться в пользу Эльбрус-8C до 3-5 раз и, даже системы, существующие сейчас, в ряде задач могут выходить в лидеры и по однопоточной производительности, и по валовой производительности CPU, и по валовой производителности системы. Результат в RakeSearch, по сути - это результат в самых неподходящих условиях. И это делает данные результаты ещё интереснее.
Цитата: Disel от 12.01.2020, 08:40А под какой ОС работает, там указано, что это Debian, так и есть? Или операционка то же Эльбрус (но определяется как Debian)?
Это ОС Эльбрус (наш дистрибутив, достаточно близкий ныне к Debian, хотя ведёт свою историю от Gentoo). Определяется как Debian, видимо, из-за lsb_release.
Цитата: hoarfrost от 20.01.2020, 05:00Результат в RakeSearch, по сути - это результат в самых неподходящих условиях. И это делает данные результаты ещё интереснее.
Я сейчас посмотрел дизассемблированную _ZN10RakeSearch11PermuteRowsEv, которая отъёдает 75% CPU на поток, там в целом всё нормально - по 7-8 команд, где удаётся, вполне ложатся в одну, ожидания есть только на переходах. 25, конечно - это совсем синтетика, чтобы так уложить команду, нужно всё подготовить очень хорошо (фактически - писать горячий цикл на ассемблере и распихивать команды вручную, рассчитывая длительность каждой; и то это не спасёт от задержек на промахах в кэш, ну и подобрать так команды, чтобы все 25 исполнительных устройств делали что-то - сложно: они не одинаковы, каждое может что-то своё, какие-то математику, какие-то - предикаты, какие-то - лоады/сторы и т.п.).
Минутка юмора. На cnews появилась статья «Эльбрусы» приблизились по производительности к Intel 2014 года. Есть что процитировать: "В Сети появились результаты частного сравнительного исследования производительности отечественных процессоров «Эльбрус-8C». Выводы эксперта под ником Seti уже некоторое время размещались на интернет-форумах. 27 февраля 2020 г. их на своем сайте опубликовал Максим Горшенин, сотрудник МЦСТ — компании, занимающейся разработкой упомянутых чипов."
Далее, смотрим в содержимое, смотрим откуда оно взялось и понимаем, почему надо ставить источник новости - потому что ссылка бы шла на BOINC.Ru.
>:D