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

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

Posts Tagged ‘xeon phi

Кластер для финансового анализа

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

В предыдущем посте (посту?) я показал свой комп, но проблема конечно этим не решается. Даже если учесть что у меня сейчас 16×3=48 ядер, этого хватает для того чтобы что-то считать, гонять TeamCity (видите какой я лояльный?) и еще кое-какую сервисную муть. Но этого мало, поэтому касательно вычислительной мощи у меня припасен другой козырь, про который я вам и расскажу.

Когда я ушел из аспирантуры в 2006 году, я не то чтобы уволился. Ну вот не уволился и все тут. Остался на позиции Visiting Researcher (или просто Visitor, чтоб без пафоса) в универе. Зачем? Ну, для начала плюшки простые: я получил от универа кучу софта, доступ в библиотеки (попробуйте поищите статьи в журналах не имея подписки), и другие мелкие плюшки вроде возможности получать академический софт и покупать железки от Altera со скидкой.

Но главное не это. Как я уже говорил, когда я начал заниматься алготрейдингом, я был нищий и вычислительных мощностей у меня практически не было — я гонял нейросети на компе который был HTPC билдом с Пентиум М (ноутбучный!) на борту. Ну, чем богаты тем и рады.

Так вот, тут внезапно оказалось, что мой универ входит в некий консорциум, которому принадлежит второй по размеру кластер в Англии! Хотите глянуть на спеку кластера? Окей. На текущий момент она выглядит как-то вот так:

  • 750 нодов, каждый из которых оборудован двумя ксеонами по 8 ядер (E5-2670) и 64гб оперативки
  • Четыре “толстозадые” ноды с E5-4640 (т.е. 32 ядра) и 256Gb оперативки
  • 12 GPU нодов в каждом из которых по две теслы — сейчас это K20. Одна такая игрушка стоит $5k, что сейчас кажется копейками, но когда-то это было огого!
  • Порядка 10 Xeon Phi 5110P нод которые, как вы понимаете, уже морально устарели.

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

Когда я сунулся во все это я, вообщем-то, тоже был тот еще раздолбай: у меня не было навыков ни в численных дисциплинах ни в программировании. Но я-то знаю как замотивировать себя изучить новый предмет: написать видеокурс по нему! Что я и сделал, записав для Pluralsight курс по High-Performance Computing.

После попадания на кластер, я столкнулся с очевидными ограничениями в работе системы: все данные синхронизованы по GPFS (ухх, InfiniBand, мне б такое!), а поскольку у нод нет своих дисков, это накладывает некоторые ограничения на то, сколько можно всего обсчитать.

Все это привело к моей нескончаемой радости ровно до того момента, когда я понял что мне придется строить собственную кодовую инфраструктуру поверх чужого железа. И несмотря на то что за 12 лет меня еще не выгнали (я не произвожу на универ никакой полезной работы, только беру), эта возможность является совсем не иллюзорной.

Кластер сам по себе управляется с помощью MPI. Межпроцессорное взаимодействие я реализую с помощью OpenMP — достаточно бесячего, но работающего кое-как стандарта. Помимо этого, я порой использую SIMD — либо явно (это конечно не особо желательно), либо путем использования оптимизаций компилятора и подстаивания своих циклов так, чтобы это можно было делать проще через #pragma simd и иже с ними.

Что касается собственно того что я запускаю там, в основном это рассчеты на С++ или MATLAB (там лицензия MDCS) которые, как правило, тестируют ту или иную рыночную теорию. Поскольку вычислительных ресурсов чуть более чем дофига, а платить за них не надо (в отличии от, например, Azure), я гоняю очень много спекулятивной или вычислительно-неэффективной фигни которая, вместо того чтобы использовать механизмы machine learning-а (всякий annealing там), пытается по сути брут-форсить анализ путем рассмотрения избыточных комбинаций данных. Это моя визитная карточка — вместо того чтобы делать все умно (и сложно), я делаю де факто Монте-Карло.

Пока я копошился во всем этом, универ не мудрствуя лукаво решил проапгрейдить всю ту инфру что я написал. Точнее проапгрейдить = закупиться еще, за деньги налогоплательщиков студентов, конечно же.

Спеки нового кластера меня порадовали еще больше — 464 ноды по 40 ядер и 192гб оперативки, особо мощные ноды (которых мало и для них нужно просить допуск — для меня не вариант), а также няшные GPU ноды — 10 нод по 4 GTX1080 и 10 нод по 2 Volta V100. Я пожалуй единственный, у кого есть и навыки программирования CUDA (да-да, по этой технологии я тоже курс сделал, по тем же причинам) а также подходящие задачи чтобы все это амортизировать.

Не будь всего этого добра, я бы не смог анализировать так много, и так быстро. Конечно, сейчас я уже могу позволить себе купить какое-то время в облаке, но согласитесь — бесплатный кластер, которым кроме тебя мало кто вообще пользуется — это просто шикарно. Я правда и пользу приношу — когда что-то в кластере идет не так, я засылаю ответственным людям инфу о поломке с репро-кейсами, что делает их работу чуточку проще. Это делает людей меньшими раздолбаями, т.к. они понимают: либо они чинят поломку здесь и сейчас, либо я пойду к вышестоящим инстанциям универа и их всех вызовут на ковер. А если чего все англичане и боятся, так это личного общения — особенно с руководством. Проще все сделать как Дмитрий хочет.

Как видите, эта история в очередной раз иллюстрирует, что порой нужно встроиться в правильную структуру правильным образом, и будет тебе вычислительное счастье. ■

Реклама

Written by Dmitri

5 февраля 2019 at 19:21

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

Tagged with , , , , , ,

Коротко про 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 , ,