>>45343
Ведут, успешно. У новых видеокарт уже по полтысячи конвееров и связанный с этим другой подход к вычислениям.

>>45351
Вот только эта архитектура к сожалению никем не рассматривается как полноценный компьютер. Ну и собственно текущая ситуация, когда CPU приложения не могут без костылей использовать ресурсы GPU, как и приложения GPU не будут без костылей работать на CPU кажется мне не очень хорошей.

>>45352
Какие костыли, няша? http://www.nvidia.ru/object/what_is_cuda_new_ru.html
Вот реальное применение в кластерах:
http://www.ks.uiuc.edu/Research/namd/
И вот
http://www.nvidia.ru/object/cuda_finance_ru.html

>Используя всего 12 графических процессоров с поддержкой CUDA™, Volera проводит анализ всего рынка опционов на акции для США в реальном времени. Ранее эта задача требовала более 60 обычных серверов.

>>45353

> Какие костыли, няша?

Например у видеопроцессора отсутствует прямой доступ к железу, планировщик, какой-либо мониторинг, скорость обмена информацией CPU<>GPU оставляет желать лучшего.

>>45354
Это идёт вразрез с архитектурой, обеспечивающей такую скорость параллельных потоковых вычислений. Многопроцессорные системы не могут эффективно работать другим путём. Поэтому на cpu остаются те задачи, что ты перечислил.

>>45355
Что именно мешает разработать архитектуру, которая позволяла бы иметь как высокую параллельность так и позволяла бы управлять железом?

>>45356
Необходимость синхронизации. Наибольшая эффективность достигается при параллельной независимой работе, сейчас процессор как раз и выполняет все задачи, в которых требуется синхронизация.

>>45357
Синхронизация нужна не всем и не всегда. Есть немало задач, которым она практически не нужна, но которые почему-то до сих пор не перенесли на куду.

>>45358
Совершенно не "почему-то", а потому что, на примере этого сайта, люди предпочитают не кодить, придумывать, создавать новое, а пиздеть за нацизм, мечтать "как здорово сделать пушку, которая воробьев на подлете к окну будет отстреливать" и несколько месяцев подряд безрезультатно кодить непонятно что c гордым названием "система компьютерного зрения". Меж тем, к слову говоря, позволяя себе презрительно отзываться об одинэс-быдлокодерах, совершенно упуская из виду тот факт, что быдлокодерские разработки применяются ИРЛ, а их кр00тые хацкерские лиспохаскельноассемблерные хеловорды - нет.

>>45359
Ах да, про атомный реактор под кроватью забыл упомянуть, гыгы.

>>45359
Думаешь причина только в этом?

>>45359
А что сделал ты, кроме того, что обосрал всех присутствующих?

Конечно же, еще в том, что тем, кто реально занимается делом (например, вот этим чувакам http://avisynth.org.ru/mvtools/mvtools.html круто бы помогла CUDA) не хватает человекочасов, а крутым корпорациям не до полуэкспериментальных технологий, а также в инертности человеческого мышления, но это же не в счет, верно?

>>45362
Я АСУ для управления биореактором с кучей датчиков и двумя двигателями пишу, например. :3 Сойдет?

>>45364
Пруф.

>>45354

>планировщик

В архитектуре Fermi появился хардовый планировщик.

>>45365
Глупые неверьки не могут поверить, что в самом деле можно делать что-то приносящее пользу, и при этом не быть двинутым на голову фашистом-аттеншнвхорой-бабоскорпионом, рассуждающим о Высоких Материях, Научных Проблемах и Судьбах Мира (и роли России, а также хачей с рынка, в их формировании). :3 Пруфов не будет, ибо не нужны. Вот если начнет кто-то тред, кто чего полезного делает и какие скиллы, применимые на практике, прокачал, тогда может и соизволю продемонстриовать фотки и скрины.

>>45362
По ходу работы много чего. В том числе полезного. По специфике компании заказчики от медиков до военных. Плевать, что с их стороны это очередные распилы, я сделал всё что мог. И кстати CUDA - это упрощение, для удобства разработчиков, действительно быстрые алгоритмы пишутся только с учётом специфики gpu.
кг-кун

>>45371
ты пишешь на гпу для медиков и военных? это где ты так устроился? государственное что-то?
>>45343>>45351
под видеокарты языки и обёртка пишутся самим разработчиком железа, он может архитектуру менять как хочет. под процессоры с новой архитектурой нужно писать заново всё, в том числе ядро ос. потому параллелизация только в виде костылей.

>>45371
Эй, cg-кун, когда уже игрушку по тохоте допишешь? Если я тебя правильно идентифицировал, конечно. Я джва года жду такую игру!

>>45358

>Есть немало задач, которым она практически не нужна, но которые почему-то до сих пор не перенесли на куду.

Она появилась сравнительно недавно. К тому же, многим она не подходит тем, что это проприетарная разработка, даже OpenCL предполагает наличие проприетарного драйвера для полноценной работы. Аппаратная зависимость и привязка к вендору тоже не всех устраивает.
Тем не менее опционально поддержку cuda сейчас стараются внедрять в большинство приложений, для win7 и mac уже принято решение разработать поддержку cuda на уровне системы.

>>45382
Кстати у нее открытых аналогов не предвидится?

>>45388
OpenCL
Но всё равно на драйверах с открытым исходным кодом ты много не насчитаешь.

>>45393
А без разделения на CPU/GPU внутри архитектуры?

>>45403
Разве в OpenCL есть такое разделение?

>>45406
Да, оно вообще x86-based.

>>45403
Это невозможно.

>>45407
Ну я имею в виду: там же можно заставить CPU рассчитывать через тот же интерфейс, а не только GPU.

>>45408
Почему?

>>45409
Но зачем? Для унифицированности? А теперь давай вспомним, что cuda применяется для быстрых вычислений. Это знаит, что унификация вторична после скорости, поэтому лучше применять отдельные алгоритмы для рассчёта на процессоре и через cuda.
>>45410
Не сразу понял что ты имел в виду всего лишь >>45409

>>45415

> Не сразу понял что ты имел в виду всего лишь >>45409

Нет, я не это имел в виду, а архитектуру в которой возможно использование нескольких тысяч RISC процессоров/ядер, на которых можно считать как графику/прикладные задачи/обрабатывать прерывания.

>>45418
У группы процессоров и видеокарты совершенно разный подход к вычислению. Если ты будешь использовать к ним те же принципы вычислений, которые применяются в видеокартах тебе придется забыть о >прикладные задачи/обрабатывать прерывания.
На developer.nvidia.com раньше была документация о принципах работы видеокарт, но там дурная навигация.

Когда у тебя 30 процессов и 2 ядра, ты легко можешь распределить процессы по ядрам. Но когда у тебя на 30 процессов 2к ядер, обеспечение должного распределения нагрузок совсем не тривиальная задача, приходится чем-то жертвовать.

>>45419

> обеспечение должного распределения нагрузок совсем не тривиальная задача

Но ведь решаемая же, как-то вот такие штуки работают ведь: http://ru.wikipedia.org/wiki/Jaguar_(суперкомпьютер)

>>45421
Я же написал:

>приходится чем-то жертвовать.

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

>>45422

>В видеокартах общая память

Регистры раздельные, shared memory раздельная для grid'ов, из общего только текстурная память, но она read-only вроде.

>>45422

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

В то же время вполне возможен обмен памятью между ячейками, тем более что это можно реализовать аппаратно и в полной адресации использовать адрес ячейки с этими данными. Задачи, которые не параллеляться, действительно будут работать значительно медленней, но ведь при желании много задач можно вполне успешно параллелить.

>>45423
Да, это простой и производительный способ разделения области записи.

>обрабатывать прерывания

отлично позволяет процессор, там его за глаза хватает. В любой многопроцессорной системе если надо нескольким процессорам обращаться к одному устройству, им либо приходится ждать, пока все другие процессоры его освободят, становясь в очередь, при этом ничего не делая, либо сделать один процессор, который будет единолично читать и писать в устройство, а другие процессоры будут обращаться к нему с меньшей скоростью очередей, либо с этого процессора с заданной периодичностью передавать в общую память все нужные значения и забирать результаты вычислений. По последнему варианту сейчас работает связка cpu+gpu.

>>45426

> В любой многопроцессорной системе если надо нескольким процессорам обращаться к одному устройству, им либо приходится ждать, пока все другие процессоры его освободят, становясь в очередь, при этом ничего не делая, либо сделать один процессор, который будет единолично читать и писать в устройство, а другие процессоры будут обращаться к нему с меньшей скоростью очередей, либо с этого процессора с заданной периодичностью передавать в общую память все нужные значения и забирать результаты вычислений.

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

лучше бы разработали и внедрили троичные ЭВМ

>>45467
На полупроводниках троичный процессор будет иметь куда больше транзисторов нежели двоичный при одинаковой производительности.

>>45467

>лучше бы

Все такие умные.

>>45467
где-то слышал что вычислительные комплексы противоракетных установок с300 и с400 работают в троичной системе, но наверное вранье

>>45513
как она реализована аппаратно и в чём смысл?

>>56832
не знаю, про это как-то вскольз упомянул препод по информатике еще на первом курсе, единственное что сейчас помню что реализована система "0,1,2" с напряжениями 0,5,10в, соответствующие логические значения "нет, хз, да", смысл в более высокой производительности при одинаковом числе логических элементов ну и наверно "чтоб никто не догадался"

>>56834
На заре компьютерных технологий каких только систем небыло и десятиричными никого было не удивить. Только вот подобные системы реализовать сложней, да и работают они не особо эффективно.

>>56836
десятеричный
Стыд то какой.