Опенсорсные они очень серьезно пилят + всякие плюшки добавляют в ядро.
Кстати, Haswell же умеет в transactional syncronisation extensions. Тестов, правда я не видел, но сама идея - ммм..

ну так просим лол ) если есть что сказать . говори тут столько нефанатов что будут только рады да и пока никто не делал замер у кого длиннее в забеге на 2е место в классе чистого декодинга тяжелых фильмов на оптимизациях самих цпу сниму интригу . длиннее всех у Nvidia с их Cuvid способным ускорять абсолютно все .


THG на шине доппитания ( которое идет исключительно на цпу . фазы PCH и памяти идут с 24 пиновика ) ГОЛОГО процессора получили результат в 32 вата Idle и 90 с копейками для LOAD ) с учетом среднего кпд преобразователей погрешность отсилы процентов 5 . декодирование по своей природе не может быть полностью бесплатно . (даже если гпу возьмет видеоряд звук и IRQ все равно должны выпоняться как минимум + нужды ос ) . ват в 40 в проигрывании (lol ) поверю



для амд ? проигрышная таки да . вы не отвлекайтесь . поделитесь с общественностью нагибательским видео . которое положит на лопатки I5 3339y ( I7 4770K даже не интересно в етой дисциплине тестировать ) у которого МАКСИМАЛЬНОЕ тепловыделение 13w в тежиме turbo boost ( 1.8 ггц на ядра / 1.1ггц на гпу HD4000) . что в итоге гораздо меньше чем амдшное чудо даже в простое . вот тада и поговорим об енергоеффективности ))


открытый ? таки да . только оборачиваясь на 6 лет назад сильно это ему помогло ( в плане домашнего использования ) ?



обьективно . раньше они их выпускали . отсилы на новую ос . и как макс багфикс . то есть раз в полгода ) прогресс был но хилый . сейчас ускорилось нехило

Дай угадать, ты не знаешь как работает TB.

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


Зависит от напруги, но КПД сильно меньше.



А им слабо было померять по датчикам в самом процессоре, благо и Intel и AMD это позволяют?
Вот сейчас сижу на профильном, играюсь в онлайновую игрушку - проц жрет суммарно по CPU и GPU около 50 ватт.

devl547
пасиба Acer криво реализовавшим SDP ( scenario design power ) и махинации в инициализации CPU participant можно на Yки слегка подразогнать на ровном месте
Yки от Uшек и отличаются конфигурируемым TB по желанию вендора

Стандарт развивается да и если глянуть на мемберов, то точно в ближайшие лет 5 не загнется:
http://www.khronos.org/members/promoters
http://www.khronos.org/members/contributors
Как минимум сама Apple не даст этого сделать, ибо OpenCL у них чуть ли не на уровне ядра ОС (iOS и OSX) поддерживается. Ну а код пишут мало, потому что стандарт только недавно стал более или менее нормальным. Как только большинство железа перейдет на OpenCL 2.0, тот разработка софта попрет только в путь.

угу . свежо предание да верится с трудом . помнится когда родили 1.0 . кричали вообще все . что все . Nvidia Cuda отбегалась будущее за открытыми стандартами .и тд . уже 6 лет как . прошло . ШЕСТЬ ! Ж) какие высоты достигли компании
AMD
толкли воду в ступе кормя завтраками. обедами . ужинами
Nvidia
2 из 10 ти суперкомпьютера Top 10 .работают на Tesla. ОСОБО ХОЧЕТСЯ ОТМЕТИТЬ ЧТО НА ТЕСЛЕ НОМЕР 2 в списке - Titan лаборатории oak ridge

И при этом кроме Тесл - Оптероны в качестве процессоров.

мне прочесть лекцию о требованиях к CPU внутри CUda программы ? или не стоит ?

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

Что-то я всего 4-е года насчитал

На CUDA было намного проще писать код, пока не появились адекватные либы и обертки для opencl.
На OpenCL 2.0 писать будет еще проще, чем на CUDA, они там многое учли.

Про MacOS уже сказали - в Apple действительно крайне активно пилят ускорение софта на OpenCL.



Всё не так просто (ht assist, 4 канала и прочие феньки, которых нет на десктопе), да и софт там с оптимизацией под оптероны (open64, ACML)

OpenCL 1.0 представлен вместе Mac OS X 10.6 8 июня 2009 года
в основу концепции OpenCL пошли наработки Amd Fire Stream . дата рождения которой 27 декабря 2007 . так что увы идее 6 лет :/ а успехов чуть


2.0 устарел еще даже не выйдя . Xeon Phi показал в красках что существующая модель GPGPU ущербна . предложив assisted node . что концептуально отличается от модели как CUDA как и OCL . тем что на Phi тело программы можно поместить в САМ УСКОРИТЕЛЬ . тем самым вовсе исключа хост машину . и исключа лишние копирования Gpu<->system ram

Nvidia в ответ на эту бадягу . делает maxwell . в котором за тело программы будут отвечать ARM ядра denver ( увы но это наибольшее на что они способны . и макс для чего предназначены ) .

и тут есть такой момент .уже есть целое поколение програмистов наяривавших на cuda . переучивать их НИКТО не будет .это глупо и сомнительно с точки зрения оптимизации. которые с одной стороны будут тормозить развитие CL с другой продолжат развитие подсистемы Cuda . тем же методом MS пересаживала народ на VS чуть ли не бесплатно раздавая.

нет более инертного человека как програмист .



я утрирую не все же тут сидящие знакомы со спецификой )

А НВ и АМД только к концу 2009 года. То есть 4,5 года, не больше.

Идея?! Кто-то мог работать с этой идеей?!

Ни фига подобного.



Вполне используется через OpenCL. Для этого там 3 (если не 4, не помню точно) типа устройств - CPU, GPU и ACCELERATOR. Phi относится к последнему.



Опять же, привет OpenCL 2.0

правда чтоли ? то есть СОВМЕСТНАЯ демонстрация AMD + Nvidia на siggraph asia 2008 . 10го декабря 2008 соответственно . возможностей open CL 1.0 не считается ?

то что кто то боролся с правильным расставлением костылей / не мог /не хотел / было не до этого . влияет ?
1.0 версия была закрыта вместе с слежным барсом ёпл . а ввиде беты была доступна и того раньше

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


привет чему ? для реализации assisted node требуется апаратный CPU на самом чипе с прямым доступом как к системной так и к памяти ускорителя. в случае с PHI ему это не нужно потому что он сам Х86 . и хост кусок можно забросить в сам ускоритель без какиз либо переделок кода. что не удивительно . но сам интель не сильно жалует на Phi CL. хоть тресни .что популярности не добавит

в итоге когда до амд дойдет что поезд опять ушел сойдутся 3 молодца .
Nvidia с набортными ARM ядрами и специфичным обвесом
Intel - которым и так клево .
и AMD- чьи инициативы будут заблокированы остальными 2мя .ибо шансов что стандартизируют чуть менее чем ноль.

Ничего он не устарел - код исполняется на CPU, GPU, FPGA.

Нафига этот костыль в APU Kaveri, если там контроллер памяти общий (читаем что такое HSA)?

Я тебя огорчу, но правильно написанная программа на OpenCL требует изменения 2-3 строчек кода, для того чтобы она могла выполняться на других устройствах.

Что-то ты пургу гонишь - у AMD все уже есть сейчас.

правда ? то есть программа может выполняться целиком на гпу без директив цпу ? или пяток -десяток - полмиллиона ядер радео могут обьединится в 1 меганагибательное ядро ?

аналогом инициативы Intel унд Nvidia является HSA отчасти на костыль сойдет . так как снизит количество обращений к памяти . и пропагандирует во много те же принципы . однако до реализации с отдельным выделенным ядром етому костылю как до луны
1.потому что применим только к APU которые в нужны разве что эльдорадо . (4ре ядра . 4 гига . игровая видеокарта)
2. не обеспечивает снятие нагрузки с хостовых ядер . и не снижает нагрузку кольцевых шин . если вы не знакомы с мейнфреймами и кластерами . это накладные расходы на обмен данными между нодами ( частями кластера )
3. да и к тому же он не применим к дискретным Firepro . по понятным причинам


изменив 2-3 строчки . ты ее запустиш на костылях . оно В ТЕОРИИ заработает . но производительность будет очень печальным зрелищем . оно с горем пополам работает вокруг GF + RADEON. с горем пополам потому что Adobe premiere к примеру имеет 3 пачки оптимизаций . под нвидия и амд с интелем соответственно . да и сами производители советуют использовать профильные SDK . PHI и вовсе требует рекомпиляцию под свою специфику ( а там далеко не 2 строчки ) Intel известные скромняги http://software.intel.com/en-us/article ... oprocessor завуалированно обьяснили что вы должны всю прогу перепилить нафиг . абсолютно также обстоит портабельность вокруг других сочетаний платформ . в итоге стандарт как бы есть . и как бы нет а все удивляются почему же CUDA До сих пор цветет и пахнет ..

Он таки прав. Достаточно изменить тип устройства + размерности (число потоков например). ВСЁ.



Быстро проглядел, но похоже что там общие оптимизации, справедливые для всех платформ.

Оно в реале так работает и без всяких костылей...

Потому что OpenCL на Nvidia работает через жопу - медленно и глючно. Поэтому и используют CUDA. Почему оно так у Nvidia работает думаю объяснять не нужно.

Контроллер памяти общий - программа выполняется как на CPU, так и на GPU (параллельно) безо всякого копирования данных из одной памяти в другую. Читай что такое HSA...


Чего?

HSA гораздо лучше. Там где нужна мощь в однопотоке твой Phi сольется, а Kaveri нет, поскольку у него есть 4 довольно мощных ядра. При этом Phi придется копировать данные в системную память, чтобы центральный процессор мог помочь группе ущербных (первый пень) ядер. Потом результат будет опять скопирован: системная память->CPU-(PCI-E)->GPU->локальная память GPU.


Этих обращений будет ровно столько сколько бы их было в отсутствие GPU и исполнения кода только на CPU.

Ядра уже там на чипе, контроллер памяти общий - ничего подобного у конкурентов нет и в ближайшем будущем в настольном сегменте не появится.


Вся мобильная индустрия (SoC) это APU...

Ты название темы читал? Какие в *опу кластеры? Тут про APU разговор. И какие накладные расходы, если контроллер памяти общий?

Спасибо КЭП... Пиши исчо!

вы хоть читали что я написал ?

у Nvidia гайдлайн и вовсе OpenCL Programming Guide for the CUDA Architecture . и является талмудом на сотню страниц . вкратце напрямую несовместим.. только через костыли. потому что стилистически написаное под Nvidia OpenCL до боли в одном месте напоминает Cuda . под это и затачивалось . а никак не ради поритабельности
Intel - имеет 2 талмуда . первый - как написать приложение по ссылке . второй талмуд гайд по оптимизации . предполагает перепил программы под вовсе другие принципы . сходные с х86 ( sandy )

затачивается под векторизацию ( которая по понятным причинам в гпу невозможна ) .
оптимизации под SSE и жоугую модель паралелизования ( во многом схожую с OpenCL Intel CPU компилятором и OpenCL PHI ) на их использование они и давят . ( для гпу не подходит вариант интеля по понятным причинам ) про что они скромно написали

как итог мир разделился на
- Intel OpenCL compiler for Intel CPUs
- Nvidia OpenCL compiler for Nvidia GPUs
- AMD OpenCL compiler for AMD CPUs
- AMD OpenCL compiler for ATI GPUs

не особо совместимыми друг с дружкой
где то рядом ходит дженсен и ржет . Cuda write once - use many