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

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

Коротко про 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 в 19:10

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

Tagged with , ,

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

Subscribe to comments with RSS.

  1. Почему же сразу «поздно» — если на нее переложить что-нибудь типа Flume (http://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/FlumeJava.pdf), то можно будет запускать вычисления как в «облаке», так и на Phi, не меняя код.

    И да, мы еще помним COM ;)

    Alexander Buryak (Rageous)

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

    • Локальные облака — это в принципе тоже хорошая идея. В домашних условиях можно например развернуть несколько VM в одной машине (например, по одной на SSD). Тоже себе облако. Phi просто в плане обработки пошустрее будет, но всегда останется узкое место — PCI bus.

      Dmitri

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

      • Да, мне часто на работе доводится запускать что-то локально по 10-20 потоков, т.к. рабочие машины для map-reduce-а в облаке только поднимаются несколько минут, а локальный процесс стартует моментально. И для таких целей дополнительные мощности не помешали бы. Правда с моими задачами узким местом обычно становится не CPU, а сеть: входные данные очень толстые, и даже на 10 CPU не всегда хватает пропускной способности сети. Но их ничто не мешает кэшировать локально, был бы повод…

        Alexander Buryak (Rageous)

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

        • Ну если не хватает пропускной возможности сети на одной ноде, тут хотя бы есть вариант просто открыть еще коннекты с других нодов. А вот если у вас по сети льется больше данных чем вы можете распарсить — вот тут проблема — тут вам и LMAX disruptor и кастомные FPGA фидхэндлеры и всяческий офлоадинг на что только можно.

          Dmitri

          1 декабря 2013 at 20:48

        • Не… у нас такое не взлетит. Мы слишком привязались к х86 уже: все проблемы решаются накидыванием на них гор обычного железа, и кастомные решения не в ходу. Да и я с трудом представляю, как команда разработчиков будет под себя какое-то кастомное железо в датацентр просить тогда, когда все спокойно обходятся обычным.

          Alexander Buryak (Rageous)

          2 декабря 2013 at 10:08

        • Ну если все обходятся, то все хорошо. А вообще, любая команда разработчиков
          спокойно прогнется под любые требования руководства, хоть им VHDL закажи,
          изучат и еще благодарить будут. В квантовой среде конечно такое не
          проходит: ваши конкуренты ставят FPGA фидхэндлер и внезапно начинают
          разбиать FIX на долю секунды быстрее чем вы, или начинают строить стакан
          аппаратно, в то время как вы сидите со своими map-ами и сосете лапу.

          Dmitri

          2 декабря 2013 at 10:26

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

          Alexander Buryak (Rageous)

          2 декабря 2013 at 10:31

  2. Интересный пост… но у меня потекла кровь из глаз после трех постов с «Вообщем».

    Vilen Tambovtsev

    3 декабря 2013 at 13:16


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: