Pull to refresh

Comments 30

Прекрасный цикл статей. И слог хороший, и главное материал просто бесподобный. Пишите, обязательно пишите.


Повесил пином во всех телеграм чатах, где админю. Такое нам нужно!

Однажды, в районе 2015-2016 года одному нашему заказчику продали сервак с Xeon Phi. А заказчик этот заказывал у нас различные computer vision решения для распознавания составов.
Это было на границе расцвета сверточных сетей. И у нас была было два решения. Одно на caffe (ещё не доделанное), второе на классическом computer vsion: что-то вокруг OpenCV, haar, решающие деревья, фильтры канни и.т.д.

И попросил нас заказчик все это дело перенести на Xeon Phi. Мы, естественно, сказали что сначала надо потестить, уж большо странная машина. И где-то несколько недель мы тестировали. Воспоминания живы до сих пор:)
Главное моё непонимание тогда вызвало целеполагание этого девайса. Для кого/для какой аудитории? Процессы для которых была важна скорость одного ядра по понятным причинам работали не очень. По этому отваливался классичеcкий ComputerVision (или требовалось многое переписывать).
Для нейронок на тот момент не работало почти ничего. Билдились только очень обрубленные и старые библиотеки.
Я тогда попробовал посмотреть вокруг и понял что у Xeon Phi тогда было лишь две группы пользователей:
1) Там где закупщики не советовались с разработчиками. А маркетинг у Intel всегда был сильный
2) Метеорологи. Они могли очень просто использовать распараллеливание. В Phi была какая-то неплохая поддержка фортрана.

Мне кажется что в плане ML intel потом как-то развивал платформу, но первоначального опыта хватило чтобы больше нигде с ней не связываться.

О. Напомнили. Надо будет про OpenCV написать статью. Мы ее начинали в ранних 2000х. Хорошие времена были. Я как щас помню Саnny Edge Detector "снизу доверху" написал на Ассемблере. :)

Насчет погодных кодов - один из моих ребят работал с John Michalakes, оснновным разработчиком WRF. Они портировали его на Phi и как то я не припомню там сногсшибательных успехов. Параллелилось оно и правда неплохо. До тех пор пока не упиралось в memory bandwidth. WRF местами чувствителен к нему.

Если я правильно помню, и моя память не спит с другим (с) :)

— Ну ты сам-то вспомни, что сказал, когда первый раз к нам пришел...:)

А чего вспомнилось-то?)

Да по сути то же самое - про частоту.:) Только я сказал, что процессоры для Linpack, DPDK (там тоже частота играет рояль) и Сeph - это три разных процессора. На самом деле большие датацентры (Google, Amazon, Facebook) почти никогда не брали топовые (высокочастотные) процессора. Предпочитали помедленнее и подешевле. Уж не знаю не занимались ли они даунклокингом :)

АWS топовые ставит для ЕЦ2, знаю не по наслышке. Кстати первые приняли 64С АМД-шки и успешно. Не топ по частоте идёт только в стораджи...

что сделает с нами маркетинг за недобор флопов на Линпаке?

Нескромный вопрос, это тот самый известный интелловский беззубый маркетинг? Который не смог сделать внятное название процессоров (особенно свежие ноутбучные линейки). Который мерился нанометрами с плюсами вместо млн. тр. на мм2. Который смог позволить амуде без своего производства отобрать часть рынка.
Или это был какой-то другой маркетинг?

Ну это смотря с какой стороны смотреть. Если извне - то может быть. А внутри конторы не в меру креативным "творцам" иногда прилетало так, что мама не горюй... :)

Концепция была такая – давайте натыкаем кучу слабосильных( в Knights Corner использовалась архитектура Pentium), низкочастотных ядер с “православной” ISA и снабдим их зубодробительной длины SIMD. Все это неплохо работало ровно на одном бенчмарке (угадайте каком). Как только Xeon Phi сталкивался с критическими участками однопоточноно кода (а такими, например, являются огромных размеров “cвитчи” в MPI) – он немедленно шел на дно

какой-то отечественный процессор мне это напомнило, никак не вспомню какой именно


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

Безусловно оптимизация нужна, даже несмотря на то что ISA не меняется. Но далеко не везде возможна. Например в MPI есть огромный switch - там более сотни кейсов. Последовательный кусок с чертовой горой ifoв. И сделать с ним особо ничего нельзя. Я помю этот кошмар на внутреннем постмортеме по Phi показывали.

Где можно посмотреть на этот чудесный switch на сотню case'ов, с которым ничего особо сделать нельзя?

У меня друг спрашивает, он такое любит.

Последнее время наблюдаю как clang периодически оптимизирует такой переход до jmp с вычислением адреса

  • Надо понизить частоту ядра. Ведь оно все равно по большей части ждет ввода-вывода. И чем меньше оно намолотит тактов в этом процессе, тем лучше. –В этот момент у ветеранов тусовки делались уксусно –кислые лица. Типа “ну вот, еще один юный гений”…

не понял, честно говоря, а какую проблему решало это предложение? ну понизится производительность ядра, io от этого не ускорится

Не ускорится. Но будет есть заметно меньше энергии. И в изготовлении будет проще.

Конвеер можно будет покороче сделать...

Там много плюсов на самом деле. Лучше всего будет если удастся избавиться от нагромождения буферов. И всякого разного согласования по частоте.

Не Линпаком единым, как говориться.

Основной плюс Линпака был в его предсказуемости, и довольной большой индефферентности к таким вещам как размер кэша и сетевой подсистемы. Гонка за процент от пика позволяла вычистить узлы еще до начала эксплуатации свежекупленного кластера, и де-факто это был тест на жизнеспособность системы в целом, включая не только сервера но и кондиционирование с электросетью.

Его же плюсы в некоторых местах стали и минусами. Так сеть нужно было проверять дополнительно (IMB, FFT). Чем больше была система, тем дольше ходил Линпак, это тоже минус, т.к. не позволял быстро оценить работоспособность. Да, я в курсе что по первым степам можно оценить плюс минус лапоть, но это тоже время.

Кроме Линпака был еще упомянутый HPCC который показывал среднюю температуру по больнице всех подсистем и классно диагностирует проблемы. Почему то забыт HPCG который был призван заменить HPL но в результате оптимизаций превратился в некий аналог Stream. Так же есть такой тест как Graph500, о который сломано немало копий и там тоже есть интересный ТОП.

Вообще сухой остаток какой - Intel это флопсы, но флопсы это Линпак и поэтому не нужно на них так смотреть? :)

Интересно, почему-то IBM/Apple имеет возможность свитчить ISA с обратной эмуляцией, а вот intel держится за свою священную корову x86 как не в себе.

Казалось бы, вон примеры, как IBM запускает 50-летнее легаси на современных процессорах, а Apple софтово эмулирует старые архитектуры (даже 68k эмулятор в System 7 несли), а Intel не шмогла.

Конечно же были попытки. Из не-x86 можно, кстати, вспомнить суперкомьютер на i860 и несколько так себе кластеров на IA64, но под них весь софт с нуля писался.

Наверное боятся сильно экспериментировать после itanium

Интересно, почему-то IBM/Apple имеет возможность свитчить ISA с обратной эмуляцией, а вот intel держится за свою священную корову x86 как не в себе.
У Intel нет своей экосистемы — OS, приложений и т.д. Если же положиться на стороннюю фирму, Microsoft например, где гарантии, что завтра они не начнут поддерживать конкурентов (ARM, RISC-V) с тем же уровнем совместимости, и монополия Intel на Desktop рухнет.

А разве MS неполноценно ARM поддерживает? ЕМНИП даже свои устройства на ARM выпускает. Стороннего софта меньше, это да, сторонних драйверов меньше, но вот поддержка со стороны Windows полноценная, насколько я знаю.
Ещё в NT 3.5 была поддержка Alpha, MIPS, PowerPC, помогло это тем платформам?

Выше писали про путь Apple
>> возможность свитчить ISA с обратной эмуляцией

То есть чтобы под Win/ARM можно было полноценно запускать ну скажем Fruity Loops x64 или AutoCAD x64, не замечая что они собраны под другую архитектуру.

Из интереса проверил — всё так и есть, запустилась и работает на Windows 11 под ARM, запущенной на маке с M1 в UTM ("обёртка" над qemu, используя встроенный в систему гипервизор Apple).

На Windows 10 под ARM была трансляция только 32-битного софта, лишь в сборках Insider появился транслятор 64-битных приложений, но так и не релизнулся для десятки.

Замечательная статья, с нетерпением ждем продолжения.
Чем-то, все описанное в ней, напоминает "Шальную компанию" Генриха Альтова, чем-то «Хроники лаборатории». В хорошем смысле этого слова.

То, что  Интел постепенно отказывается от AVX-512 служит косвенным доказательством.

Эх, загнал Intel себя в ловушку с Linpack и AVX-512. В принципе же годный набор. И некоторых фич, которые есть только в AVX-512, сильно не хватает в AVX2 или ниже.

Сейчас уже можно откинуться в кресле, и с чувством собственного достоинства изречь "если бы молодость знала, если бы старость могла". Но умные люди (и компании) отличаются тем, что они извлекают уроки из прошлых неудач. Если Интел полностью откажется от AVX-512, то это точно не пойдёт на пользу. Опять придётся догонять, исправлять или ещё что-то.

Есть большое количество сценариев, где AVX-512 показывает неплохие результат и делает пользователей счастливыми. Но эти сценарии не так показательны и известны как linpack, не позволяют вешать "звёзды" на грудь, и, как результат, Интел их "не видит". Отсюда и "постепенно отказывается".

Sign up to leave a comment.

Articles