Обсуждаем проект Folding@Home.
Номер нашей команды: 47191
Страница регистрации в проекте F@H: https://apps.foldingathome.org/getpasskey Обязательна для получения бонусных очков
По вопросам работы универсального клиента обращайтесь в соответствующие ветки:
Универсальный (SMP+GPU) клиент v.7
Folding@Home под Linux
Статистика заданий и рекорды команды: [F@H] Статистика заданий
В этой ветке все о мониторинге клиента FAH http://forums.overclockers.ru/viewtopic ... 1&t=122378
Статусы основных серверов F@h: https://apps.foldingathome.org/serverstats
Список текущих проектов: https://apps.foldingathome.org/psummary?visibility=ALL
Статистика команды на сайте extremeoverclocking.com: https://folding.extremeoverclocking.com ... s=&t=47191
Статистика по общему количеству CPU\GPU, мощности проекта: https://stats.foldingathome.org/os
Статистика по отдельным картам и процессорам в проекте: https://folding.lar.systems/gpu_ppd/overall_ranks
Официальный форум проекта: https://foldingforum.org
Мы в Telegram - https://t.me/TSCRussia

Да да, переделали так, что производительность ниже, а FPS выше.

LAV48 а количество отрендеренных кадров в секунду (FPS) разве не является одним из показателей производительности?

DmGun Речь о математической производительности.

LAV48 математику и кадры (3d эффекты) они разными местами счетают? Думаю, просто расчетное ядро не адаптировано под кеплер полностью.

Добавлено спустя 3 минуты 47 секунд:

я об этом, если камрад прав )

DmGun

удивишься но да, всякие как ты говоришь эффекты требуют в разы большее время чем чистая геометрия и все последние усилия как раз направлены в область уменьшения затрат в этом месте, так что будущие чипы могут иметь геометрический блок медленный в разы чем сейчас, но за счет всяких хитростей по налочению за 1 проход например будут давать больший FPS

А с чего это вдруг вычислительная производительность у Кеплер ниже?
Огранизована по другому, но общая математическая мощность не ниже, а выше.
Другое дело что для "наращивания FPS" сделали может даже больше - в первую очередь скорость текстурирования в ~2.5 раза увеличили: 128 текстурных блоков на частоте 1000 мгц против 64 блоков на частоте 770 мгц (GTX 680 vs GTX 580).
Но и по математике тоже прирост есть солидный. И по остальным параметрам либо тоже некоторых рост либо как минимум сохранение уровня Ферме. Вот подробный сравнение архитектурных различий. На примере полных(не урезанных) чипов GTX 580/680 (Fermi/Kepler):
GTX 580 vs GTX 680
4 GPC(Graphics Processing Clusters) vs 4 GPC - верхний уровень организации чипа остался без изменений

4 шт SM(Streaming Multiprocessors)на 1 GPC=16 SM в чипе vs 2 шт SM на 1 GPC=8 SM - мультипроцессоров стало в 2 раза меньше, но каждый из них стал намного крупнее и мощнее

32 Cuda ядра на 1 SM=512 CUDA ядер@1544 мгц vs 192 Cuda ядра на 1 SM=1536 CUDA ядер@1000 мгц - общий прирост суммарной выч. мощности тут почти в 2 раза и собственно эти ядра основную часть вычислений (сложение, умножение, деление и прочие стандартные мат. операции) и производят
В флопсах разница по куда ядрам 1.6 ТФЛОПС vs 3.1 ТФЛОПС (теоретическая пиковая, с приведением к х86 стандарту)

4 SFU(Special Function Units) блока на 1 SM=64 SFU@1540 vs 32 SFU на 1 SM = 256 SFU@1000мгц - рост выч. мощности в 2.5 раза. Эти блоки занимаются сложными мат. операциями (тригономертрические функции,извлечение корня, логарифмы и т.д.).

16*16=256 блоков LD/ST vs 32*8=256 - эти блоки отвечают за загрузку/выгрузку данных из памяти в/из вычислительных блоков. В относительном выражении (по сравнению с выч. блоками) их стало меньше, так что где-то это может быть стать узким местом огранчивающим рост скрости, но в абсолютном по крайней мере не хуже предыдущего чипа (даже получше, за счет простого роста частоты).

2*16=32 диспетчера инструкций vs 8*8=64 диспетчера - занимаются "скармливанием" и распределением иструкций между вычислительными блоками, рост в 2 с лишним раза раза (2х блоков + рост частоты)

ПСП ~192 ГБ/с vs ~ ПСП 192 ГБ/с - роста никакого нет, но по крайней мере не хуже, кеширование памяти при этом работает быстрее, т.к. существенно выросла частота самого чипа (770 vs 1000 мгц)

В общем по всем основным вычислительным параметрам Кеплер существенно превосходит Ферми, слабое потенциально узкое место - работа с памятью, но и оно не слабее чем у Ферми.

И да, одно дейсвительное серьезное ухудшение относительно Ферми(на котором в т.ч. сэкономили транзисторов, чтобы сделать больше обычных выч.блоков) - меньшая скорость расчетов с 2й точностью. Точных данных не нашел, но где-то в 2 раза медленнее на операциях с двойной точностью.

Но как понимаю F@H как и подавляющее большинсво других проектов РВ вполне одиночной точностью обходится. (иначе карточки без поддержки двойной точности вообще считать не смогли бы). У меня карточка например вообще в DP считать не умеет в принципе(это не у всех AMD карт, а только у некоторых моделей). Однако F@H считать может. Как и все остальные проекты. Я пока знаю только 1 проект, где без DP обязателен - Milkyway@Home. И то, там не все расчеты в DP идут, а относительно небольшая часть.

Так что резкий слив Кеплера в F@H это проблема не кеплера, а Фолдинга и его кривого софта. (Так же как и резкий слив AMD карточек). На нормальном софте Кеплер закономерно рулит из nv карт - почти во всех проектах РВ. В т.ч. например в GPUGrid, который практически тоже самое (фолдинг/взаимодейсвие белков) считает и такими же методами(молекулярная динамика), только на собственном софте. Весь ТОП быстрейших хостов забит Кеплер-картами:
http://www.ps3grid.net/top_hosts.php

Полностью согласен. Так что пусть докторишки делают софт гибким и работоспособным.
При 100%-ой загрузке видеокарты у меня наблюдаются микролаги в интерфейсе, вплоть до того что дольще по времени заходит в программы + обязательно нужно включать АЭРО-эффекты, иначе невозможно пользоваться компьютером и мне не понятно, почему я не могу регулировать степень этой загрузки. В вышеупомянутом GPUGrid я считал видеокартой, без малого, год. Так вот там загрузка видеокарт 80-90% процентов, что абсолютно не мешает использовать компьютер и даже играть в тяжёлые игры.
Посему, не считаю картой, которая способна приносить большую пользу в виде вычислительных мощностей для проекта и приличного количества очков для команды, уже пару месяцев и меня это абсолютно устраивает.
На радеонах (да и на GTX тоже), у которых в архитектуре увеличили вычислительную мощность, которые вышли почти год назад, до сих пор невыгодно считать.
И это в проекте такого масштаба.
Немного странно, Вам не кажется? Или я что-то не до конца понимаю?

Тоже лагает компьютер при счете GPU. Пускай пилят с новым GPU-программистом.

killer2636
Zhomart
,
вы бы господа определились, что вам нужно - чтоб считала хорошо или чтобы не мешало за компом сидеть
Mad'Max
помимо цифорок голых еще бы архитектуру не мешает сравнить в плане тонкостей работы

sco01 Чтобы считала и не мешала работать, это вполне выполнимые задачи, их я описывал выше.

killer2636
если будет считать в 50% то даже играть можно - вот тока как это вяжеться с твоими же высказыванием о том что карточка должна считать в полную силу даже больше теперешних теоретических 99%?
я вполне допускаю что если картка в среднем показывает 80% то ничего лагать и не должно т.к. она не загружена

sco01
Я писал про то, что неплохо было бы сделать управление по желанию пользователя загрузкой этой карты. При 80-90 процентах никаких лагов нет и не будет. Проверенно в проекте GPUGrid.

только меня коробит такое неуважение?

Насчет лагов при работе - кроме ограничения максимальной загрузки карты зачастую достаточно просто размер пакетов (скармливаемых видяшке за 1 раз данных/запускаемых за 1 раз итераций) поменьше сделать. Лаги зачастую не от самой нагрузки как таковой, а от того, что за раз очень большой пакет отправляется и пока он считаться на закончит, ОСь не может вставить свои данные необходимые для обсчета и отображения интерфейса, т.к. до "переключения задач" и распределения приоритетов потоков как в ОС для ЦП видеокарточки пока не доросли (да и не факт, что там это нужно). Программеры обычно стараются сделать их побольше, т.к. это позволяет немного снизить "накладные расходы". В некоторых проектах, так увлекались, что сталкивались с тем, что Винда долгое время не могла достучаться до видеодрайвера, решала что он вообще завис и перезапускала его (естественно убивая все шедшие рассчеты). Сделать этот параметр настраиваемым пользователем и все дела - если карточка выделена исключительно под счет, ставим больше и чуть выигрываем в скорости. Если параллельно юзер работает, ставим меньше и получаем отзывчивый интерфейс, ценой небольшой потери скрости счета.
Впрочем это проблема не только в F@H почти нигде программеры такими вещами особо не заморачиваются.
Может у нового GPU программера до этого руки дойдут... Хотя врядли скоро - сначала наверняка будет заниматься оптимизацией клиентов под Кеплер и AMD карты.

Добавлено спустя 31 минуту 53 секунды:
sco01
Голые цифры это было бы просто сказать XXXX пиковых ГФЛОПС против YYYY ГФЛОП. А я как раз выч. архитектуру и сравнил.
Ну а какие тонкости еще нужно? Сами "считалки" - исполнительние модули, которые непосредственно всю работу связанную с вычислениями выполняют (CUDA ядра, включающие в себя целочисленные и вещественные ALU; SFU ядра; LD/ST модули) не менялись и их реализация переехала в наследство от Fermi.
Зато очень серьезно изменилось их количество, частоты работы и организация внутри чипа. Вот как раз все это я и расписал выше (что относится именно к вычислениям, пропустив части относящиеся к графике - установке и расчетов вершин полигонов, текстурированию, фильтрации текстур, закраске полигонов и т.д.)

А проблема с производительностью кеплеров скорее всего достаточно примитивна - или вообще пока еще не реализовано гибкое изменение числа параллельно работающих "потоков" и их кол-во и схема взаимодействия осталась ориентированной на ахритектуру Fermi (а кеплеру для реализации его потенциала нужно их в ~3 раза больше).
И/или где-то какие-то данные перестали укладываться в L1/L2 кеш чипа (т.к. объемы кешей остались примерно те же, а вот число выч. модулей выросло в разы-каждому достанется меньший объем в разделяемом между ними кэше) и пошли тормоза из-за постоянной загрузки/выгрузки данных через "медленную" (относительно кеша и с учетом кол-ва параллельно работающих модулей) память.

Mad'Max
про видеодрайвер - даже при самой жестокой нагрузке в 100% он всегда ответит винде, варианты ответа тока могут быть разными
Перезагрузка драйвера в 7 винде это либо в 90% аппаратный сбой (как правило переразгон) либо какая то софтина перехватила управление драйвером (например GPU-Z)

Что касается потребления видеопамяти то фолдинг ни разу не видел чтоб сьел больше 490м... А на всех видиках сейчас гиг да есть минимум


Фишка появилась тока в 5 версии CUDA которая вышла совсем недавно - сам видик может на лету менять кол-во задействованных модулей, учитывая что важен результат докторам - явно они будут долго тестировать валидность этой функции (я даже не уверен что она в 17 версии ядра появиться, которая надеюсь все таки появиться до конца зимы)

Добавлено спустя 7 минут 54 секунды:
Mad'Max
"Голые цифры это было бы просто сказать XXXX пиковых ГФЛОПС против YYYY ГФЛОП."
как то не вяжеться с твоими же высказываниями типа:
"У i7 и близко нет 230 Гфлопс", "Приписывать больше сотни Гфлоп текущим процессорам это изобретение маркетологов Штеуд, которые скорость собственно самого процессора со скоростью встроенного в него графического ядра складывают"

я не зря попросил подтвердить эти детские фанатские наезды фактами/ссылками - где интел заявлял 230гфлопс, да даже где она вообще заявляло просто гфлопс не указывая что это и как посчитано - пока ты привел тока одну ссылку которая опровергает твои же высказывания...

Насчёт гигофлопсов.
Мой i7 920, при частоте 3.8, показывает 95 Гф (+/- 1 Гф), каждые 100 Mhz дают прирост виличиной 2.5 гигофлоп. Соответственно в номинальных частотах (2.66 Mhz) этот показаль будет в районе 65-67 Гф.

Ты не одинок.

Это(сбос видеодрайвера) не к F@H относилось, а вообще к счету на видеокартах и их связи с лагами/тормозами. Такое (постоянный сброс видеорайвера виндой, из-за сильной загрузки чипа большой очередь из крупныных пакетов) в одном из проектов на BOINC платформе было. Видеокарточка конечно-рано или поздно ответит, просто винда до бесконечности ждать не будет, она переодически ее опрашивает, если ответ за несколько секунд не пришел, считает драйвер зависшим и его перезапускает. Хотя карточка все-го была очень занята, а не висела. Народ там поначалу реестр патчил, чтобы отключить(/увеличить время ожидания) эту проверку и можно было нормально считать. Потом программеры сообразили в чем дело и в след. версии счетного модуля стало работать уже нормально.

Насчет объемов памяти я вообще-то ничего и не говорил. Только про ее скорость ну про объемы КЭШа.(а не самой памяти)

Добавлено спустя 6 минут 28 секунд:

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

Кстати, кто знает, последние OpenMM ядра еще на CUDA делаются или уже на OpenCL?

Господа, вам не надоело разводить пустой флуд про Гфлопсы и прочую дурь?..