Pull to refresh

Comments 23

Спасибо за «просто о сложном». Несколько раз натыкался на упоминание о Intel Ct, но сразу понять для чего это нужно и как это работает не смог.
Ой, да это же «Летайте самолетами Аэрофлота»! Может мы снова с MS договоримся, что будем завышать потребность софта, чтобы покупали новое железо.
Ирония фразы «Летайте самолетами Аэрофлота» заключалась в том, что во времена оной рекламной кампании других самолетов не было.

Не совсем правильно ограничивать понятие «потребности софта» десктопом. Ct, например, будет в первое время более актуально для рабочих станций и датацентра. (по-крайней мере мои клиенты там его будут использовать)
Хм, а на CPU от AMD проги, слинкованные с этой либой, работать не будут? ) Или будут работать намного медленнее, как после Intel CC?
Тот вопрос решается одним ключиком (не секретным, с первой страницы хелпа). Здесь должно быть не сложнее, хотя я не пробовал еще. Вещь новая, свое время я пока трачу на тестирование на нашем железе.
Так не сказали главного: в чем же отличие от OpenCL (и CUDA)?
Те же кернелы (Ct-код), таже «JIT-компиляция», почти тот же язык…
А в чём отличие OpenMP от Intel TBB?..
Просто Intel Ct является набором абстракций функционального програмирования для реализации отсутствия побочных еффектов. Jit нужен для того что-бы подогнать код под конкретный GPU или CPU камень. Если Intel TBB это человеческий OpenMP для процессора СРU, то Intel Ct относится как к GPU так и к CPU.
Я думаю что тенденция Intel Ct повторится как и с Intel TBB:
1) Заработают денег — сделают ОпенСорсной
2) Не заработают денег — тоже сделают ОпенСорсной
Так что нам, товарищи, как бы и все карты в руки…
Опять новая всежрущая библиотека распределенного програмирования, или очередной загруженый баян? Поживём — увидим.
Вообще говоря Вы так и не ответили — в чем разница. У OpenMP от Intel TBB разница есть как минимум в подходе к программированию. В свою очередь OpenCL — стандартизован, у него поддержка многих компаний. И тут бац — появляется Ct. Должно же быть отличие, чтобы мы сказали — ну вот — будем теперь использовать его, так как он лучше ввиду…

Кстати, Ct работает поверх TBB, но им, очевидно, не ограничивается.
Intel Ct умеет исполнять код на GPU?
Только если вдруг это GPU поддерживает X86 и ее модель памяти.
Ну вот и я так думаю. А товарищ eox425 что-то путает.
Присоединяюсь к вопросу. Мне тоже непонятно.
Ключевое отличие заключается в том, что все текущие и перспективные X86 архитектуры имеют когерентную память. В отличие от. Следовательно, в Ct программист никак не беспокоится о барьерах и синхронизациях.

Ну и по мелочи — Ct более «правильно плюсовая», чем OpenCL.

Ну и Ct как родные поддерживает x86 SIMD, я не знаю, как с этим будет у OpenCL, когда/если она будет доступна для X86.

Ну и еще очевидная разница в списке поддерживаемых платформ.
Ну в общем всё вполне логично. Как таже CUDA даёт больше свободы и удобства при работе с GPU от nvidia, так и Intel Ct выжимает всё от нативной платформы.

Скажите, а как эта разработка впоследствии будет или уже связана с Intel Paralle Studio?
Когерентная память в Ct — это интересно — я бы почитал. Возможно в ее реализации действительно единственно важное отличие.

Насчет «правильно плюсовая» — это не отличие. Для OpenCL есть C++-обертка (и множество оберток для других языков) — пользователь не заметит разницы — правильная она или не очень.

OpenCL поддерживает CPU x86 по стандарту. Вы просто запрашиваете список доступных GPU, CPU и других устройств (например, Cell), на которых можно вычислять и выбираете устройство по некоторому вашему критерию. Другое дело — насколько оптимально оно реализовано, но это уже не столь важно для выяснения отличий.

По списку поддерживаемых платформ уточните, пожалуйста.
Да, я кривовато сказал про поддержку x86 в OpenCL. Пытался намекнуть про возможную реализацию от Intel.
Да, спасибо, что напомнили. Код в Ct — выражает алгоритм с точки зрения вычислительной задачи, совершенно прозрачно относительно платформ, на которых он может выполняться. Рантайм разбирается с платформой, и нет необходимости запрашивать устройства и менять реализацию, или беспокоиться о blocks/warps/threads.
Я бы даже сказал что идеология Сt является частным случаем Лямбда и Pi функционального подхода. Помните старый, добрый Erlang?- Там всё есть процес и всё есть рекурсия,
самое класное что все переменные read only. Эти факторы избавляют данный подход от всех побочных эфектов распределённых систем, типо приоритетов, data race conditions и тому подобных.

Но кто отменял этот подход относительно С++? (ну разве что относительно переменных =) )
Я думаю что подобное движение только в пользу культуре програмирования, которая, по-моему в данный момент немного отошла на задний план.

Лично я использую openCL + openMP
Иногда для меня очень важна скорость и подключение внешних библиотек типа CUDA и TBB не самое оптимальное решения подобных задач.
Спасибо за наглядный пример, как не нужно оформлять топики.
До «ката» должно быть написано что и зачем, а под катом уже как и подробности.
вроде это назывется совместимость вверх
Спасибо, сейчас поправлю.
Дык оно ядра от видеокарт получается не трогает? Тогда какое-такое «железо, во многих формах»?
К сожалению, пока ни о каком другом железе, кроме X86 CPU, говорить не имею право. Но если скачать, можно догадаться путем хитрого reverse engineering.
Sign up to leave a comment.