Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Posts Tagged ‘computation

Коротко про Xeon Phi

9 комментариев

Программирование высокопроизводительных систем невозможно в принципе. Вот несколько причин почему это настолько сложно что мало кто напрягаться будет:

  • SIMD сложно использовать потому, что нужно конвертировать обычные вычисления в абсолютно другой синтаксис, где, во-первых, другие типы данных (__m128i и подобные), работают далеко не все операции (например, в SIMD может не оказаться деления) и используются они не через обычные операторы: например вместо a*b нужно писать _mm_mul_ps(a,b). Понятно что мало кто будет напрягаться с этим, для этого даже отдельное расширение языка есть. Нет, я не шучу, пожалуйста: Intel Extensions for SIMD. Вы только вдумайтесь – отедльное расширение языка чтобы пользоваться чем-то, что присутствовало в процессорах со времен MMX! Я уже не буду говорить про то насколько все это эволюционирует и что писать для этого портативный код фактически невозможно.

  • CUDA это еще один гвоздь. Казалось бы, что плохого, модель более менее понятна. Но! Оно во-первых не особо портируется между девайсами (сам PTX портируется, но речь не об этом), т.к. девайсы все разные и никакого… свопа на диск и прочего нет, у всех свои параметры, писать обобщенный код нудно. Ну и потом, на CUDA нельзя гнать ничего кроме параллельных вычислений. Параллельных. Вы не можете делать 1024 разные вещи на CUDA. Только одинаковые, или с небольшими вариациями. Для обработки картинок? Супер. Для анализа кода? Да вы издеваетесь… (В эту же корзину идут OpenCL, которым никто не пользуется, и AMP, которым тоже никто не пользуется.)

  • FPGA разработка это вообще рецепт «как сделать классные технологии недоступными для простых смертных». То есть в отличии от SIMD, который у вас поддерживается в проце, и CUDA, которая в любой карте NVIDIA поддерживается в каком-то (порой, правда, весьма унылом) состоянии, FPGAшки остались чем-то на уровне шаманства. И языки другие (VHDL это нечто), и парадигма другая, и самое главное что разработчики не понимают нафиг это надо если не купить COTS продукт и не засунуть его быстренько в комп. На самом деле купить, и засунуть, просто это чертовски дорого, а все хотят выгоду здесь и сейчас. Не получится, товарищи.

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

И казалось бы, идея «купи компьютер и вставь в компьютер» фактически умерла, если только у вас не одна математика (тогда вы в шоколаде). Что же делать? Но недавно мне попалась новая партия добра (24шт.) под названием Xeon Phi. Думаете «еще одна проприетарщина»? А вот нет. Phiшка – это 60 процов которые – важно –

поддерживают x86

Может кто-то из вас не вкурил насколько это круто. Ладно. Попробую объяснить.

В ваш комп, условно говоря, воткнут еще один комп на PCI шине. Этот комп может работать в двух режимах: либо вы его просто используете как, эмм, отдельный комп – у него там Linux на борту, с ним вполне можно общаться; либо же вы отгружаете часть ваших задач на него.

Intel Xeon Phi Card

Вообщем шикарно, да? Вы фактически можете поставлять решения (т.е. полнофункиональные решения software+hardware) на таком девайсе. Но стоп, не все так просто. На самом деле, было бы даже странно, если бы наша лодка счастья не разбилась бы о быт в той или иной форме.

Итак, как вы уже догадались, для использования Фишки нужно

  • Отдельный компилятор

  • Тулзы для коммуникации с Фишкой

  • Магия в коде :(

То, что нужно как-то общаться с девайсом это понятно. Отдельный компилятор понять тоже можно: это конечно продукция Intel, но продукция эта использует другие процы, соответственно внутренняя реализация может как-то отливаться… хотя стоп, это же x86.

На самом же деле, поддержка Intel MIC (MIC = many integrated cores, то есть «очень много ядер к нам пришло») с точки зрения кода выглядит очень похоже на CUDA. Серьезно, посмотрите:

  • Для того чтобы что-то отгрузить на Фишку, можно либо использовать __declspec(target(mic)) int* stuff либо же сделать pragma push/pop.

  • Есть два режима как передавать данные – data sharing и data marshaling. В CUDA тоже вариантов всяких аллокаций и sharing’а вагон.

  • Модель отгрузки поддерживает разные парадигмы, например OpenMP. В этом случае просто пишем #omp parallel for и так далее.

  • В прагме для отгрузки идут отметки о том что отсылается и что получается (in/out/inout), прямо в лучших традициях COM. Я правда не уверен что читатели моего блога знают что такое COM :)

  • В случае с отгрузкой, вызов отгруженной функции выглядит как-то брутально: _Cilk_offload_to (target_id) foo().

  • Если данные шарятся, их нужно по-особенному создавать и удалять: как вам _Offload_shared_align_free(vals).

Вообще смотря на это мне как-то не особенно страшно. Ну да, чуточку прагм и немного головной боли в плане определения того, что дескать я именно вот этот массив хочу получить как результат, и вот тебе его длина. Да, это кстати намек на то что variable-size структуры могут как-то не сростись.

Пока у меня про Фишки все. Признаюсь, что с ними интересней играть чем писать про них. Но что я хочу чтобы вы поняли так это то, что это революция. Только пришла она поздно: сейчас у нас «облака» и уже локально что-то тяжелое гнать не так важно. К тому же, непонятен выигрыш для не-math задач. Нужно поизучать.

И да, судя по тому что пишут, для numerics эта штука послабее CUDA будет. Но это не важно!

Реклама

Written by Dmitri

1 декабря 2013 at 19:10

Опубликовано в Hardware

Tagged with , ,