Обсуждаем POEM@Home. Проект закрыт

• Официальный сайт проекта.
• FAQ (научная и техническая стороны проекта, примеры файлов конфигурации)
• Альтернативный файл настроек app_config.xml
• Быстрая настройка проекта POEM
  
  Объявления:
  
  • Статистика PPD GPU

На данный момент:
командное место в общем зачете: 5 (еще статистика)
командное место по скорости: 6 (еще статистика)

ТОП-10 команды по суточному вкладу (от stats.free-dc.org):
#77

ТОП-10 команды по общему вкладу (за все время участия):
#77

sashmxm
А где почитать про занятое место в забеге?

MegaCalcii http://boincstats.com/ru/stats/challenge/team/chat/673

sashmxm
Какие-то сикитурадастра нас обгонали в 2 раза, выскочки

MegaCalcii они до Utopia были абсолютными лидерами - мне кажется, им там по уставу команды полагается рвать и метать или из банды исключат. Вон, один Ross только сколько нащёлкал

Благодаря мегаподдержки подтянувшихся к проекту камрадов, вырвались временно даже на 1-ое место по скорости. Идем на обгон L'Alliance Francophone. неделя.... Спасибо всем, кто с нами!

Кстати, с 2 000 000 000 нас!!! Урааа!

sashmxm
про забег в шапку не хочешь закинуть? как в 2013 там щас висит наподобе..?

Так, подведём итоги нашего общего забега в проекте B@P POTM - POEM@HOME - 10.- 17.05.2015
в забеге учавствовали 16 команд, среди которых мы заняли почетное и уверенное 2-ое место, насчитав за эту неделю 43 430 201 - между прочим для сравнения , в забеге Spring 2013 POEM Challenge года был очень похожий результат - 40,184,35.
В неравной борьбе 1-ое место заняла команда Sicituradastra., насчитав практически х2 больше нас, где , безусловно, особый вклад сделал кранчер Ross* с 36,464,600.
2ое и 3ое места у нас и в индивидуальном зачете - у наших камрадов Smoke77 и Mad_Max.
Особая благодарность камрадам из Фолдинга, которые поддержали команду!!

Сводные таблицы
1. В командном зачёте - 10-ка лучших
#77
2.В индивидуальном зачёте - 20-ка лучших
#77

Взяли 8 место, обогнав команду L'Alliance Francophone! Следующий соперник BOINC.Italy(33 дня до обгона с текущей скоростью), потом SETI.Germany(76 дней с тек. скоростью), есть реальные шансы подняться выше в рейтинге этого проекта за короткое время, всех приглашаю, желательны видеокарты, не в ущерб остальным проектам, например, если у Вас 2 ВК, можно отдать одну в этот проект

MegaCalcii
а какие видюхи рулят в нем? амд или нвидиа?

tguskill
Не знаю, моя 980 выдает 535к в сутки. Сколько выдает 290x надо спросить камрадов

Около 500к выдавала во время забега, точнее не помню.

tguskill да топовые рулят, тут нет приоритета теперь - красный, зеленый. 970 и тут показывает результаты. А по успехам на данный момент можно в 5-ку лучших подняться. Это мы тут особенно не напрягаемся, считаем себе в свое удовольствие. Если подключатся пару топовых карты, мы тут всех порвем, особенно конкуренции никто не составляет, если только у кого-то азарт не появится, как это было во времена версии 1.05. когда всякие Мити-Пети, как подключались, что сервак не выдерживал. Тут у нас реальный спортивный интерес, выхлоп нормальный для карт. С заданиями таких уже нет проблем, я про батник и забыл, что пользовался когда-то. Так что - велкам!! Если что, заходите!

MSI 290X Lightning At 1120Mhz (stock at 1080Mhz) - 530k в день (в 1 поток)
EVGA 04G-P4-2978-KR 970X at 1443Mhz (stock) - 430k в день.(в 2 потока, на PCIex 1x шине - на 16x на 3% больше)

если кратко, то без переписывания кода выигрыш будет до 5% (В основном на топовых картах. На mid end почти ничего.). Если переписать алгоритм под эти фичи, то может до 20% будет быстрее, но это долго.

Пока, если появляется свободное время, то пытаюсь понять почему AMD не может правильно синхронизировать кэш карточки и копирование с нее, когда запущено 2 WU. Пытаюсь удалять код, чтобы баг оставался (есть разные удаления, которые убирают баг, но те части кода не могут иметь такой эффект). Осталось около 50кб кода на c++ и 10кб на opencl

Если найду, то это будет +10% на 290X за счет двух потоков и еще +10% ко всем карточкам за счет уменьшения runtime проверок, которых сейчас много.

vtankovich, а программировать на OpenCL тяжело, например, по сравнению с C++?

Сделать чтобы работало не намного сложнее чем на С++ - немного почитать о том как с карточкой общаться и как запустить opencl код на карточке на своих данных.
Сделать чтобы было быстро - сложно. Чтобы загрузить 290X полностью, надо обеспечить работой где-то 40000 потоков (чем больше, тем лучше). Тоесть основная проблема: как организовать вычисления так, чтобы они были сильно распаралелены. Плюс ко всему этому дополнительные ограничения по регистрам которые можно использовать в 1 потоке, по синхронизации ( очень желательно чтобы блоки по 64 потока выполняли одну и туже инструкцию в каждый момент времени), по синхронизации за пределами блоков по 64, по обращению к памяти - если обращаться, то последовательно(кэши маленикие). итд.

PS: 25k C++, 6k opencl осталось. Отослал repro в AMD - может посмотрят. Там сейчас все очень просто написано

vtankovich, код, который вы написали для Poem, на основе которых состоят нынешние задания для GPU, если я верно интерпретировал последнюю информацию по проекту, - он, я так понимаю, до конца не "вылизан". Например, при работающих GPU-заданиях, я запустил Valley Benchmark и стали наблюдаться при этом "фризы" и рывки картинки, так же, все задания, выполняемые на GPU в этот момент, - крашились (завершались с ошибкой) одно за другим. Предыдущий код таких проблем не вызывал и я, в своё время, без проблем считал его несколько месяцев, правда, он "съедал" одно процессорное ядро.
Проблема в чём то конкретном или просто физически не хватит времени одному человеку написать код, который бы позволил не затрагивать общий интерфейс системы, не вызывая при этом ошибок?

Это 2 разные проблемы. Фризы возникают потому что пока выполняется opencl код видеокарта ничего другого не может делать. Раньше kernel выполняло очень мало работы на GPU и это занимало несколько милисекунд и не было заметно. Теперь количество работы выбирается так чтобы время выполнения было не намного больше 100мс - соответственно FPS будет меньше 10 (там сложнее, но смысл тотже). Можно это значение уменьшить - будет плавнее интерфейс, но это вопрос к немцам. Для меня эта проблема - by design.

Проблема с ошибками - это то с чем я пытаюсь разобраться последний год, когда появляется свободное время. Основной смысл тех ошибок в том, что когда карта под постоянной нагрузкой (2 потока POEM или 1 POEM и 1 еще что-то), то может произойти следующее:
1) kernel пишет в память
2) вместо записи напрямую в память данные попадают в кэш
3) kernel завершает работу. данные все еще в кэше.
4) начинается выполнение чего-то из второго потока, что грузит шину памяти и кеш все еще не попал в память.
5) CPU код первого потока понимает, что kernel отработала и начинает копирование результатов с карточки в основную память.
6) скопированные результаты не содержат той части, которая все еще лежит в кэше. Если попытаться скопировать несколько раз, то они все-таки доходят.

Этот баг с рассинхронизацией кэша и завершения "работы" может проявляться еще несколькими способами, когда карточка под большой нагрузкой. Сейчас посидел и сократил размер кода для repro до небольшого, чтобы не было подозрений на всякие buffer overrun, и послал в амд - может или пофиксят, или подскажут в чем не прав.

этот баг я видел только на быстрых картах от amd. также некоторые компьютеры со старыми драйверами и tahiti картами могут успешно по 2 задания выполнять, но не все. также на Linux все работает нормально, тоесть большой шанс что это у амд с драйверами проблема, но, учитывая их плачевное состояние, они врядли на это будут смотреть.

По времени у меня этот проект занял около 200 часов на протяжении 6 месяцев. Основное время ушло на планирование как распаралелить. потом еще около 200 за последний год, чтобы понять почему на амд падает. По работе на CUDA пишу - там намного все надежнее и стабильнее, а тут, пока писал, нашел 2 бага компилятора, которые подтверждены амд, но до сих пор не пофикшены %)

vtankovich, но ведь, в теории, можно как-то отладить код, чтобы он выполнялся и одновременно не сильно затрагивал картинку? Ведь, например, такие проекты как SETI и Moo! Wrapper, написанные на OpenCL, не вызывают подобных проблем.

Цитата:

а тут, пока писал, нашел 2 бага компилятора, которые подтверждены амд, но до сих пор не пофикшены %)

Да, что там говорить, красная помойка, под названием АМД, сначала похоронила процессорный рынок, а соответственно, и конкуренцию, теперь же это убожество, купив в своё время, более-менее неплохую и стабильную компанию, ATI Technologies, подписала и графическому рынку смертный приговор. Как они обвалили за последний год-полтора долю на рынке - это ещё суметь надо. Зарубежные форумы кишат сообщениями разъярённых пользователей о проблемах в драйверах, которым срок - более полутора лет (речь о R9 2xx) с которыми ничего не могут сделать, ввиду своей мозговой импотенции. Сертифицированные драйверы, выходящие раз в пол года, стали нормой. Перед тем, как "залечь на дно" и расслабиться на пол годика, выпустили маркетинговый шлак, под названием - Омега, якобы написаный с нуля, который является таким же кривым, как и все предыдущие, вызывающий во многих ситуациях чёрный экран. Люди сами дорабатывают всевозможные баги официальных драйверов и выкладывают в виде фиксов. На днях заметил, что они закрыли, в понимании нормального человека, форум, сделав из него подобие гостевой книги. Видимо, думали, что если более-менее резво и безпроблемно считается Bitcoin, то можно сидеть и плевать в потолок, не улучшая комманду разработчиков, пишущих код и драйверы, не вкладывать в компанию деньги, которые они наоборот в последнее время лишь сокращали. Расчёты Bitcoin на видеокартах прилично сдулись и начался схлопываться вслед за этим красный мыльный пузырь.
P. S.: Локти все искусал, не надо было продавать, в своё время, первый Титан.
Давно бы слез с этого красного ужаса, если бы была алтернатива.