Да, о этом. Но о экскаватора ничего внятного не нашел.

Эхсперты по микроархитектурах не раз заявляли, потому что их словарного запаса максимум хватит для 3х букв.

"дабы избежать накладок и иных согласования для передачи данных."
может быть слово "иных" лишнее?

Интел еще в сандике дала ГПУ доступ в кэш Л3. Иви научился даже записывать туда.
Планируют они много чего, они и опен сл на 19хх запускали, и физику на этих же гпу продемонстрировалли раньше нвидии. Кроме майнинга, гп от от ати, до сих пор ничего не ускоряют в обычных программах. У интела хотя бы quick sync есть годный, хотя этим не гпу вроде занимается.

Если правильно понял, то теперь расчетами занимается сразу весь комп? Или как? Просто уменьшили задержки для памяти без кеша?

terenty79
Ещё два раза по 15 рублей. Молодец, постепенно идёшь к успеху.

АМД молодцы, не дают скучать!


так понимаю не будет разницы видеопамять или системная память - всё едино, одно адресное пространство.

Умные дядьки в АМД засели, лишь бы не ушли

Это проблема сегодняшнего дня. AMD же старается упростить процесс программирования многоядерных систем, сделать его прозрачным для человека. По-крайней мере, если они смогут вменяемо заменить один FPU на кучку таких же, но поменьше, сделать процесс параллельных вычислений доступным для среднестатистического программиста - флаг им в руки, я болею за них.

Infinite_madness а что сложного? Языковые средства позволяют писать параллельный код более чем прозрачно.
последовательный код

параллельный код


последовательный код

параллельный код

Ну, ок, а компилируемые языки? Какие языковые средства позволяют писать параллельный код?

Infinite_madness а чем вам JIT - не компилируемый? Я же не про руби/питон говорю. Энивей тот же самый результат можно получить при компиляции, просто нужно при установке вручную внести параметры системы вроде числа ядер или объема памяти, а в данном случае просто среда вместо нас все это сделает. В чем разица, хранить в папке, в реестре или позволить среде хранить где-то еще и просто у нее дергать в автоматическом режиме?

Согласен, разделение на компилируемые/интерпретируемые языки весьма условно, к делу не относится. Я переформулирую свой вопрос: какие современные языковые средства позволяют заменить OpenCL/CUDA? Оставим просто параллельный код(есть же OpenMP, хоть и является отдельным стандартом), но вернемся к числодробилкам. Задача HSA принести GPGPU в массы, не так ли? Так какая есть альтернатива на сегодняшний день? И не просто альтернатива, а прозрачное и дружелюбное к пользователю(программисту) средство.

p.s. лол, а ведь есть же еще, внезапно, OpenACC и С++AMP. Отстал от жизни, беда-беда:(

Infinite_madness что касается managed-языков, есть GPU.Net для тех же целей (то же, что использование TPL, только используя GPU), еще парочка, на джаву тоже там свое что-то есть. Так что не все так плохо. Особенно с внедрением функциональных фич в ЯП, вроде лямбд, замыканий, функций как объектов первого класса и прочих вкусностей. А на функциональщине параллелить вообще проще простого, никаких дедлоков, гонок и прочего.

Вот еще можете почитать: http://www.rsdn.ru/article/dotnet/CudaLibs.xml

Одна задача, множественные данные. Ха, так конечно не сложно! А вот попробуй синхронизировать несколько разных потоков. И попробуй распараллелить однопоточный алгоритм, хотя бы quicksort, никуда не подглядывая.

PsiAmp а в чем сложность? На каждой итерации мы делим пополам и сортируем каждую половину независимо. Следовательно получаем

такой код отработает за логарифм, что тащем-то очень неплохо. И все что потребовалось, пара слов async/await;

бедняги АМД... хорошие и умные люди, но труды их куда-то пропадают. Сколько не вспоминаю первые 64 битные камни, первые доступные (и настоящие!) 4-х ядерники, потом 8-ми ядерники, сейчас APU. Но кто-то или что-то просто не даёт им реализовать потенциал. Обидно.

Такие люди как terenty79 и не дают. Свято уверенные, что i3 гораздо быстрее, чем 8350.

Irlander а вы знаете, почему именно х86 победила, хотя были намного более выгодные архитектуры? Подсказка: начинается на "марке", а заканчивается на "тинг".

вы понимаете разницу между "запись в кеш в специальный выделенный участок" и "запись / чтение и обмен адресами данных из оперативной памяти"?
чет мне не вериться что запись в л3 у интла настолько же крута как у амд из реализация - я думаю даж рядом не валялась.

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

Цитата:

Барьером на пути hUMA и унифицированной памяти может стать нежелание работать в связке с AMD компаний Intel и NVIDIA. Компания Microsoft тоже заняла выжидательную позицию, хотя и вошла в состав HSA Foundation. Всех их можно понять: NVIDIA лелеет технологию CUDA, Microsoft — DirectCompute. Есть ещё Apple, которая ставит на OpenCL и Google, верующий в Renderware, как и колеблющиеся, например — Qualcomm.

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