АО НПЦ ЭЛВИС — проектирование микросхем в России
АО НПЦ ЭЛВИС — проектирование микросхем в РоссииВедущий российский разработчик
систем на кристалле
и устройств на их основе
Компания является центром компетенций в области процессорных архитектур, аналого-цифровых и радиочастотных ИС, искусственного интеллекта, компьютерного зрения, обработки радиолокационных сигналов, интегрированных систем безопасности.
50-ЯДЕРНАЯ ГЕТЕРОГЕННАЯ СНК
ДЛЯ ВСТРАИВАЕМЫХ СИСТЕМ
И РОБОТОТЕХНИКИ
СнК RoboDeus обеспечивает производительность алгоритмов искусственного интеллекта на основе нейронных сетей на уровне 16 Tflops и предназначена для построения интеллектуальных мультисенсорных встраиваемых систем
СИСТЕМА НА КРИСТАЛЛЕ ДЛЯ МОБИЛЬНЫХ
И ВСТРАИВАЕМЫХ СИСТЕМ СВЯЗИ,
НАВИГАЦИИ И МУЛЬТИМЕДИА
СнК «Скиф» предназначена для построения телекоммуникационных, навигационных, мультимедийных приложений, мульти-сенсорной обработки сигналов, робототехнических систем, планшетов, умных камер, систем мониторинга
СИСТЕМА НА КРИСТАЛЛЕ
ДЛЯ ИНТЕРНЕТА ВЕЩЕЙ
СнК «Элиот», предназначенная для применения в условиях ограниченного энергопотребления и обеспечения доверенности в IoT-сетях
О компании
Создание
регистрация
Первые в России
проектирование
импортозамещение
1990
Создание
ГУП НПЦ «ЭЛВИС» было образовано в 1990 году на базе структурного подразделения научно-производственного объединения «ЭЛАС», выполнявшего в 1960-80 гг.
передовые разработки в области космической электронной техники.
АО НПЦ «ЭЛВИС» образовалось в результате приватизации ГУП НПЦ «ЭЛВИС» методом реорганизации.
АО НПЦ «ЭЛВИС» это
750+
Сотрудников
6
Докторов наук
26
Кандидатов наук
600+
Потребителей
30+ лет
Опыт работыОСНОВНЫЕ НАПРАВЛЕНИЯ ДЕЯТЕЛЬНОСТИ
Разработка микросхем
Компания разрабатывает микросхемы типа «Система-на-Кристалле» (СнК) на базе собственной платформы
проектирования «МУЛЬТИКОР». Среди них: процессоры «Мультикор», радиационно-стойкие микросхемы для
космических аппаратов, микросхемы для СВЧ трактов широкополосных систем связи.
Системы безопасности
Вторым направлением деятельности компании является разработка высокотехнологичных систем безопасности на основе технологий искусственного интеллекта, компьютерного зрения, радиолокационного наблюдения, биометрической идентификации.
Made at Intel. Architecture and religion — 2 / Хабр
Это — продолжение (но еще не окончание!) первой главы. Начало – здесь.
Linpack – как важнейшее из искусств
Второй важнейший “культ”, который определял развитие серверной архитектуры на протяжении десятилетий – это “сакрализация” Linpack. Сам бенчмарк представлен Джеком Донгаррой аж в 1979 году. Но культовым статусом своим он обязан усилиями маркетологов из многих IT компаний (Intel, AMD, IBM, Nvidia, Fujitsu и тд). Linpack имеет массу неоспоримых достоинств.
Это всего лишь ОДИН тест, в отличие от скажем SPEC CPU, где их 40 с хвостиком.

К тому же (в отличие от SPEC) он совершенно бесплатный.
Очень легко обьяснить, что Linpack делает. Он решает систему линейных алгебраических уравнений с числами двойной точности. Используется метод (P)LU разложения (Гаусса) с выбором ведущего элемента.
В качестве результата Linpack выдает ОДНО число – измеренную производительность системы в (гига -, тера -, пета -, экза) флопах. На основании Linpack строится мировой рейтинг суперкомпьютеров TOP500 и российский TOP50.
Так же вычисляют эффективность (искушенные люди обращают на нее внимание), как отношение измеренной производительности к пиковой. Правда, в последнее время само понятие эффективности является несколько “размытым”, из-за того что в процессе исполнения теста тактовая частота может “плавать”.Linpack идеально параллелится (MPI, OpenMP и вообще что угодно) и векторизуется.
И наконец Linpack обеспечивает практически полную (>90%) загрузку вычислительных устройств.
В то время как обычные приложения редко показывают больше 20.
И все же Linpack – это всего лишь ОДИН (и к тому же весьма специфичный) тест и переоценка его роли обходится очень дорого. Тем не менее история показывает, что зачастую так оно и происходило.
Гении Линпака
Несмотря на интенсивный promotion со стороны маркетинга Linpack не приобрел бы и половины своей популярности, если бы не вклад многих талантливых инженеров. Вслед за Донгаррой безусловно надо упомянуть Kazushige Goto. Этот парень –настоящий гений (вот только разговорный английский у него хромает), а его статья Anatomy of High-Performance Matrix Multiplication давно стала “настольной книгой” для разработчиков библиотек. Я часто приходил к нему с разными вопросами по Линпаку “Гото-сан, почему так?”. И он обычно начинал свои обьяснения фразой “Ну вот представь, что ты – Linpack. Как бы ты поступил на его месте?”. Конечно, я ничего не представлял. Просто сидел и слушал с открытым ртом. Потому что для меня это какой то запредельный уровень понимания.
Велик вклад ребят из интеловских MKL (а linpack это на 95% dgemm) и MPI. А также их аналогов для других платформ. Ну и не забуду коллег из Intel Competitive Response Team, в которой я провел 8 лет (2005-2013). В нашу задачу входила поддержка больших тендеров в области High Performance Computing , а также сопровождение подачи заявок в рейтинг Top500 Supercomputers для свежепостроенных кластеров на базе процессоров Intel.
Мерило тщеславия
Top500 – самый престижный мировой рейтинг суперкомпьютеров. Чтобы попасть туда люди тратят десятки и сотни миллионов долларов. Нужно купить и собрать систему , которая может насчитывать десятки тысяч узлов и сотни тысяч интерконнектов. И когда все это сделано, остается последний (и очень ответственный штрих) – измерить производительность системы с помощью теста Linpack и подать заявку. Задача эта отнюдь нетривиальная – у нас была разработана многошаговая процедура для достижения максимального результата. Но надо понимать –что Linpack это не только Computer Science, это еще и игра вероятностей.
Продолжительность теста зависит от многих факторов – производительности процессоров, количества памяти на узел, количества MPI ранков и OMP тредов (если используется гибридная схема параллелизации) и тд. Таким образом время прогона может варьировать от часа до 10 (а то и больше). А за это время с системой из нескольких тысяч узлов может случиться все что угодно – перегреться один из процессоров, отвалиться интерконнект, “cнести башню” драйверу и тп. Поэтому мало все сделать правильно – нужно чтобы тебе еще и немного повезло. И ты не можешь предсказать когда это случится. Для того чтобы получить хороший результат может потребоваться несколько сотен экспериментальных и “боевых” прогонов. Поэтому за 3-4 недели до International Supercomputing (июнь) и US Supercomputing (ноябрь) у нас начиналась горячая пора. Работа велась посменно и не прекращалась круглые сутки.
В тот день была моя очередь и появился на работе в 8.30. Экстремально рано по своим меркам. В офисе было пусто – график посещения в нашей развеселой лавочке был фривольный и раньше 10-11 обычно никто не появлялся.
Застал я только Серегу Шальнова, который гонял linpack в ночную смену на немецком кластере.
— Че как? – осведомился я за текущий статус.
— Ночной ран не выжил, — мрачно откликнулся Шальнов. – Сразу несколько узлов скопытились. Я полночи ковырялся, чтобы их вычислить и удалить из списка. – Потом мы наскоро прикинули “расклад” (параметры Np, P и Q) с учетом изменившегося количества узлов и в этот момент у Сереги зазвонил телефон. Оказалось, что это Войтек, польский чувачок, который занимался технической поддержкой того кластера, на котором мы гоняли тест. Процесс его настолько захватил, что он приперся на работу даже раньше восьми по своему времени.
— Серега, заряжай! – прокричал Войтек так, что даже мне было слышно.
— Ты куда торопишься? – спросил Шальнов. – Скорее в историю войти?
— Дело не в этом. У нас тут похолодало. У меня в подсобке возле датацентра – 7 градусов. И если ты сейчас не запустишь Linpack (а тепла в процессе теста выделяется дай Бог), я тут сдохну от холода.
— Серега положил трубу, посмотрел на меня уставшими, красными после бессонной ночи глазами и изрек.
— Предназначение Линпака не в том чтобы быть мерилом человеческого тщеславия. Предназначение Линпака в том, чтобы приближать тепловую смерть Вселенной…
Linpack vs HPCC
Если речь зашла о разных “мерилках”, то уместно будет упомянуть об HPCC. Мой товарищ Андрей Нарайкин активно продвигал этот набор бенчей как “альтернативу” Линпаку. Нет, разумеется, HPL в составе HPCC тоже был. Но кроме этого там присутствовали Stream (вечный “антипод” Линпака), Random Access и FFT (плюс несколько дополнительных). Я тогда стебался в том духе, что ”Излюбленное занятие джентльменов – мериться размерами достоинства. А ты хочешь указать им на то, что у достоинства помимо длины есть еще и другие тактико – технические характеристики. Например, толщина, коэффициент расширения, угол стояния и тп.” 🙂 А теперь, спустя более 15 лет, я понимаю, насколько Андрюха был прав. Если бы джентльмены не зацикливались исключительно на длине достоинства, Интел сумел бы впоследствии избежать многих болезненных проблем.
Влияние на архитектуру
Колоссальное (при этом не всегда положительное). Я не знаю, другого бенчмарка, который оказал бы сравнимое воздействие на историю вычислительной техники в области HPC. Вторым наверно, идет SPEC CPU, но разрыв огромен (по вышеперечисленным причинам). По сути SSE2-SSE4, AVX, AVX2, AVX512 – это все про Линпак. Я здесь остановлюсь на трех кейсах, которые протекали при моем (прямом или косвенном) участии.
FMA впервые в истории Intel X86 увидел свет в процессоре Haswell. Fused Multiply-Add – это настолько же естественно, как улыбка младенца. Если ты занимаешься умножением, то сложение можешь получить практически бесплатно. Для целых чисел это очевидно, для чисел с плавающей точкой (IEEE754) чуть сложнее, но ненамного. К тому же, по счастливому стечению обстоятельств, наши алгоритмы (например Dot Product) устроены так, что количество сложений и умножений примерно одинаково. И когда инициативная группа ребят предложила FMA под лозунгом “Линпак – в двойку!” c ними практически никто не спорил.
Не, ну а чего спорить, когда ты получаешь сплошные плюсы без каких либо серьезных минусов.AVX512. Cледующая попытка удвоения производительности была связана с расширением длины SIMD. И вот тут, как говорится, “нашла коса на камень”. Возражения возникли моментально и сколько мы копий тогда сломали в 2010-2013м (примерно) пером не описать…
a. Нет в природе столь длинных векторов, чтобы эта машинка давала какие-то преимущества.
b. Tail processing. Чем длиннее SIMD, тем большей проблемой становится обработка “хвостов” циклов, не кратных 8 (16, 32 и тп) операндам. Частично проблема решается маскированием, но лишь частично.
c. Mы в очередной раз уродуем кодировку команд, вводя расширение EVEX.
d. Bytes/Flop. Это было мое основное возражение. Мы усугубляем извечную проблему баланса между загрузками и числодробильными операциями (отношение stream/linpack!). И эту архитектуру становится все тяжелее программировать.

e. Непонятно, насколько хорошо можно реализовать всю эту концепцию с физической точки зрения. Как ни странно, в тот момент “люди с паяльниками” вели себя на удивление тихо. Типа “надо – сделаем”. И, как оказалось, напрасно…
И все же сила заклинания “Линпак — в двойку!” оказалась достаточной, чтобы перевесить все эти соображения :(. AVX-512 появился в Xeon Phi и Хeon (начиная со SkyLake) и сразу столкнулся со сложностями. Выяснилось, что основную роль играет именно последнее возражение. Функционирование AVX-512 приводит к перегреву кристалла, и непонятно как с этим бороться. Упрощенно, ситуацию можно описать так. При задействовании AVX-512 в единицу времени срабатывает очень много транзисторов. И они рассеивают много энергии в виде тепла. И ладно бы нагревание происходило равномерно по площади кристалла. С этим можно бороться – поставить кулер помощнее, подвести жидкостное охлаждение и тп. Но беда в том, что перегрев происходит локально и это делает проблему куда более злобной.
Поначалу Intel пошел по пути наименьшего сопротивления – просто начал сбрасывать частоту при задействовании AVX-512 (в экстремальном случае чуть ли не на Гигагерц). Это серьезно подсаживало производительность системы, но на тот момент представлялось временной мерой. Другой путь состоял в том, чтобы “размазать горячие вычисления” по площади кристалла (ядра). Однако, тут возникла другая проблема – с синхронизацией и собиранием результата “в кучу”. И она оказалась сложнее, чем представлялось изначально. За 8 лет усилий лучшие умы в области электроники так и не смогли подобраться к решению. То, что Интел постепенно отказывается от AVX-512 служит косвенным доказательством. И все же хочу сказать пару слов в защиту наших тогдашних решений. Это сейчас представляется “научно доказанным фактом”, что 256 бит – оптимальная длина SIMD. А 10 лет назад это было ни разу не очевидно. Наступать на грабли – удел пионеров.
Xeon Phi явился, наверно апогеем культа Linpack.
AVX-512 хотя бы умирает (и не факт, что умрет) мучительной смертью, следуя пожеланиям обычно нордически-сдержанного Линуса Торвальдса. В то время как Xeon Phi так и не сумел толком оторваться от взлетной полосы. Он задумывался, как ответ набиравшим силу GPGPU. Концепция была такая – давайте натыкаем кучу слабосильных( в Knights Corner использовалась архитектура Pentium), низкочастотных ядер с “православной” ISA и снабдим их зубодробительной длины SIMD. Все это неплохо работало ровно на одном бенчмарке (угадайте каком). Как только Xeon Phi сталкивался с критическими участками однопоточноно кода (а такими, например, являются огромных размеров “cвитчи” в MPI) – он немедленно шел на дно (кстати, ISA тут не при чем.) Всего этого можно было бы избежать, если б в качестве основного теста был взят не HPL, а хотя бы HPCC. Но увы, случилось так, как случилось….
И снова о “гениях”
В момент краха Xeon Phi я был от этого уже довольно “далеко”. Последние годы в Intel (2016 -2020) я провел возглавляя команду VTune.
И фокус моего внимания был сильно смещен в сторону uncore. Во-первых, хотелось какого-то разнообразия. Во-вторых, uncore поляна, в отличие от core была сильно менее изученной и “затоптанной”. В-третьих, становилось понятно, что с увеличением числа ядер в процессоре роль core падает, а uncore – растет. Центром анкорной мысли тогда была тусовка под названием – IO-intensive workloads group. Я еще в шутку называл ее “клубом любителей DPDK”. Кроме самого DPDK в игре были и другие прилаги – базы данных, Hadoop, Ceph. Но всепроникающая сила Линпака в Интеле была такова, что он сумел меня достать и там. Проблемы наша группа обсуждала суровые. Вот есть core, uncore, шина и девайс – и все это работает на разных частотах. Как сопрячь, буферизовать и синхронизировать? А как быть с RDMA? В- общем почти любой доклад на этой группе так или иначе превращался в “плач Ярославны”. И если core – тусовка, периодически наступая на грабли, оставалась более или менее на позитиве, то наша лавочка напоминала сборище неисправимых нытиков.
Был там такой “обряд посвящения”, стихийно сложившийся и от того особенно смешной. Бывало приходил к нам мальчик, только что закончивший Стенфорд, Беркли или другое уважаемое учебное заведение Обьединенных Штатов Северной Америки. Первый раз он обычно сидел тихо, внимательно слушая наши стенания. Зато в следующий раз приходил одухотворенный.
-Ребята, я понял, что надо сделать.
-Ну и?
— Надо понизить частоту ядра. Ведь оно все равно по большей части ждет ввода-вывода. И чем меньше оно намолотит тактов в этом процессе, тем лучше. –В этот момент у ветеранов тусовки делались уксусно –кислые лица. Типа “ну вот, еще один юный гений”…
— Все это логично, правильно и было бы хорошо, если б не одно “но”, – в тот день была моя очередь “резать правду- матку”
— Какое?
— Знаешь, что сделает с нами маркетинг за недобор флопов на Линпаке? Он утопит нас в пруду. Вcех в одном мешке, как котят. Даже не будет разбираться, чья идея была.
— Правда? – голос у паренька заметно дрожал.
— Ага. Добро пожаловать в реальный мир. – На этом разговор закончился, но спустя некоторое время пожилой и уважаемый всеми индус, который председательствовал в группе, сделал мне замечание в личной беседе.
— Зря ты так, Валер. Парнишка прям серьезно расстроился.
— Да ладно, пусть привыкает. Здесь не Стенфорд. –И тут он меня ненавязчиво осадил.
— Ну ты сам-то вспомни, что сказал, когда первый раз к нам пришел…:)
Главная вера
И все же важнейшей религией Intel является сама x86 ISA.
To be continued…
л.с. Тест Linpack для компьютеров с распределенной памятью
HPL — портативная реализация высокопроизводительного Тест Linpack для компьютеров с распределенной памятьюHPL — портативная реализация высокопроизводительного Linpack Тест для компьютеров с распределенной памятью |
HPL — это программный пакет, решающий (случайную) плотная линейная система с двойной точностью (64 бита) арифметика на компьютерах с распределенной памятью.
Таким образом, его можно рассматривать как
портативная, а также свободно доступная реализация High
Тест производительности Linpack.Алгоритм , используемый HPL, можно резюмировать следующим образом: следующие ключевые слова: Двумерное блочно-циклическое распределение данных — Правильный вариант факторизации LU с частичной строкой поворот с несколькими глубинами просмотра вперед — панель Recursive факторизация с комбинированным поиском сводки и широковещательной рассылкой столбцов — Различные топологии вещания виртуальных панелей — уменьшение пропускной способности алгоритм swap-broadcast — обратная замена с опережением глубиной 1,
Пакет HPL содержит программу тестирования и синхронизации для количественной оценки точность полученного решения, а также время, затраченное на его вычисление. Лучшая производительность
Тем не менее, при некоторых ограничительных предположениях относительно
сеть межсоединений, описанный здесь алгоритм и его
прилагаемая реализация масштабируется в смысле
что их параллельная эффективность поддерживается постоянной относительно
к использованию памяти на процессор.Пакет программного обеспечения HPL требует доступности в вашей системе реализации интерфейса передачи сообщений MPI (совместимый с 1.1). Реализация или базовой линейной алгебры. Подпрограммы BLAS или Векторное изображение сигнала Также необходима библиотека обработки VSIPL . Машинно-специфичные, а также общие реализации ИМБ, БЛАС и VSIPL доступны для большого разнообразие систем.
Благодарности : Эта работа была частично поддержана
по гранту Лоуренса Министерства энергетики
Ливерморская национальная лаборатория и Лос-Аламосская национальная лаборатория
в рамках контракта ASCI Projects номер B503962 и
12187-001-00 4р.
Инновационная вычислительная лаборатория
последняя редакция 2 декабря 2018 г.
################################################### ####################### файл hpl-2.3.tar.gz для HPL 2.3 — портативная реализация высокопроизводительного Linpack , Тест для компьютеров с распределенной памятью Антуан Петите, Клинт Уэйли, Джек Донгарра, Энди Клири, Петр Лущек Обновлено: 2 декабря 2018 г. ################################################### ####################### файл hpl-2.2.tar.gz для HPL 2.2 — портативная реализация высокопроизводительного Linpack , Тест для компьютеров с распределенной памятью Антуан Петите, Клинт Уэйли, Джек Донгарра, Энди Клири, Петр Лущек Обновлено: 24 февраля 2016 г.################################################### ####################### файл hpl-2.1.tar.gz для HPL 2.1 — портативная реализация высокопроизводительного Linpack , Тест для компьютеров с распределенной памятью Антуан Петите, Клинт Уэйли, Джек Донгарра, Энди Клири, Петр Лущек Обновлено: 26 октября 2012 г. ################################################### ####################### файл hpl-2.0.tar.gz для HPL 2.0 — портативная реализация высокопроизводительного Linpack , Тест для компьютеров с распределенной памятью Антуан Петите, Клинт Уэйли, Джек Донгарра, Энди Клири Обновлено: 10 сентября 2008 г. ################################################### ####################### файл hpl.tgz для HPL 1.0a — портативная реализация высокопроизводительного Linpack , Тест для компьютеров с распределенной памятью Антуан Петите, Клинт Уэйли, Джек Донгарра, Энди Клири Обновлено: 20 января 2004 г.
################################################## ######################## файл hpl_qs22-2008-11-30.patch для реализации высокопроизводительного эталонного теста Linpack для IBM , системы QS22 с процессорами PowerXCell 8i. Файл является патчем , для HPL 1.0a. от IBM файл IBM_LICENSE.TXT для IBM Уведомление об авторских правах для QS22 HPL от IBM файл IBM_README.txt для README для IBM QS22 HPL от IBM Обновлено: 30 ноября 2008 г. ################################################### #######################
Rangsiman Ketkaew — Сравните свой кластер с дистрибутивом Intel для LINPACK Benchmark
Введение
Проект TOP500 ранжирует и детализирует 500 самых мощных нераспределенных компьютерных систем в мире. Вы знаете, как узнать лучшую производительность компьютера? Вы когда-нибудь хотели оценить скорость/производительность вашего процессора и сравнить его мощность с другими? Этот пост объяснит вам шаг за шагом, как измерить или протестировать производительность вашей машины!.
Для этого можно использовать этот LINPACK для сравнительного анализа вашего собственного ПК/кластера/суперкомпьютера или чего-либо еще, состоящего из процессоров в качестве процессоров.
LINPACK — это программная библиотека для выполнения численной линейной алгебры на цифровых компьютерах. Он был написан на Фортране Джеком Донгаррой. LINPACK в основном использовался для тестирования суперкомпьютера, чья лучшая производительность была оценена и оценена TOP500, самым известным веб-сайтом с рейтингом производительности HPC. Пользователи как Windows, так и Linux могут загрузить высокопроизводительный тест Intel LINPACK (HPL) под названием Intel Optimize LINPACK Benchmark и Intel Distribution for LINPACK Benchmark из библиотеки Intel Math Kernel Library (MKL). Тест MKL и руководство для разработчиков можно найти здесь.
Целью этого теста является измерение производительности ЦП Intel путем решения десятков математических уравнений — линейных уравнений — измеряемых в единицах FLOPS, таких как GFlop/s или TFlops. Для теоретического пика производительности формула для расчета GFlop/s выглядит следующим образом:
Производительность узла в GFlops = (скорость ЦП в ГГц) x (количество ядер ЦП)
x (инструкций ЦП за такт) x (количество процессоров на узел)
Дистрибутив Intel для LINPACK Benchmark измеряет время, необходимое для факторизации и решения случайной плотной системы линейных уравнений (Ax=b) с реальной*8 точностью .
Все тесты, представленные здесь, основаны на библиотеке тестов Intel Distribution for LINPACK, которую можно использовать для запуска на нескольких вычислительных узлах или на одном вычислительном узле с несколькими процессами MPI.
Intel Xeon Scalable Series, один из самых эффективных процессоров Intel.
Саммит: самый быстрый компьютер в мире (1 -й TOP500)
Содержание
. Бесхул ваш кластер, используя распределение Intel для Linpack Clarkmark
ВВЕДЕНИЕ
Содержание
1. Подготовка и предварительные. Обработка SMP и MPI
1.2 Получить Intel MKL Benchmark
1.3 Спецификация моей машины
2. Проведем сравнительный анализ вашей машины!
2.1 Использование LINPACK: версия с общей памятью
2.2 Результаты сравнительного анализа для версии с общей памятью
3.1 Использование LINPACK: версия с распределенной памятью
3.2 Результаты сравнительного анализа для версии с распределенной памятью
Сравнение результатов теста SMIT суперкомпьютер.
(для версии с распределенной памятью)
4.1 LINPACK Benchmark суперкомпьютера SUMMIT, ORNL, США (первое место в TOP500)
4.2 LINPACK Benchmark моего узла Intel Xeon, узел Chalawan Head, Нарит, Таиланд
4.3 Эффективность
4.4 Повышение производительности Эталонный показатель
5. Используйте LINPACK в ОС Windows
5.1 Инструкция
5.2. My Naptop Spec
5.3 Результаты эталона моего ноутбука
6. Linpack на мобильном устройстве
Android: Mobile Linpack
IOS: N/A
7. Ссылки
1. Подготовка и предварительные условия
3
1. 10062
3
. Тест Intel LINPACK для обработки SMP и MPI
Существует два типа тестов Intel MKL для LINPACK: версии с общей памятью и версии с распределенной памятью.
- Тест Intel® Optimized LINPACK Benchmark относится к версии с общей памятью.
Эта версия представляет собой тест скомпилированного кода, который можно найти в каталоге linpack . Этот тест поддерживает только чистую систему OpenMP. Поэтому, пожалуйста, отключите технологию Intel Hyper-Threading. Подробности можно найти здесь. - Дистрибутив Intel® для LINPACK Benchmark относится к версии с распределенной памятью (используйте библиотеку MPI). Эту версию можно найти в каталоге mp_linpack .
1.2 Получите тест Intel MKL Benchmark
1. Перейдите на https://software.intel.com/en-us/articles/intel-mkl-benchmarks-suite
2. Найдите пакет для используемой ОС , доступный для Linux, Windows и macOS. Затем загрузите на свой компьютер
Например, я использовал следующую команду для загрузки файла l_mklb_p_2018.3.011.tgz tgz в свой Linux.
wget http://registrationcenter-download.intel.com/akdlm/irc_nas/9752/l_mklb_p_2018.3.011.tgz
Для Windows и macOS нажмите ссылку для загрузки и сохраните zip-файл на свой компьютер, возможно, в папку Download.
3. Распакуйте zip-файл, двоичный файл находится в подкаталоге с именем Benchmark_2018 . Например,
- Linux
/home/rangsiman/intel/compilers_and_libraries_2018.3.222/linux/mkl/benchmarks
- Window
C:\Users\rangs\Downloads\w_mklb_p_2018.3.011\benchmarks_2018\windows\mkl\benchmarks
1.3 Спецификация моей машины
Архитектура: x86_64
bits -bit
Порядок байтов: Little Endian
ЦП: 24
Список процессоров в сети: 0-23
Поток на ядро: 2
Ядер на сокет: 6
Сокеты: 2
Узлы NUMA: 2
Идентификатор поставщика: GenuineIntel
Семейство процессоров: 6
Модель: 63
СТУПИНГ: 2
ЦП MHZ: 2400,221
BOGOMIPS: 4799.29
4456. : 32KКэш L2: 256KКэш L3: 15360KNUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22NUMA узел 1 ЦП: 1,3,5,7,9,11,13,15,17,19,21,232. Проведем сравнительный анализ вашей машины!
2.1 Использование LINPACK: версия с общей памятью
1. Просмотрите каталог linpack . Например,
cd /home/rangsiman/intel/compilers_and_libraries_2018.3.222/linux/mkl/benchmarks/linpack2. Запустите LINPACK
./runme_xeon64Обратите внимание, что число физических потоков по умолчанию равно количеству физических потоков. ядра. Если вы хотите определить количество потоков, установите
OMP_NUM_THREADSв следующем скрипте. Например, для 64-битной системыexport OMP_NUM_THREADS=4Вы можете увидеть и изменить настройки по умолчанию номера проблемы и ее размера, изменив входной файл с именем lininput_xeon64
vi lininput_xeon643.
Подождите процесса. завершено. Результаты тестов будут записаны в текстовый файл с именем lin_xeon64.txt
2.2 Результаты тестов для версии 9 с общей памятью0020
Откройте файл
lin_xeon64.txtс помощью текстового редактораПример файла данных lininput_xeon64.
Частота ЦП: 3,199 ГГцКоличество процессоров: 2Номер ядер: 12Количество ниток: 12
Параметры. 15Количество уравнений для решения (размер задачи): 1000 2000 5000 10000 15000 18000 20000 22000 25000 26000 27000 30000 35000 40000 45000Ведущий размер массива: 1000 2000 5008 10000 15000 18008 20016 22008 25000 26000 27000 30000 35000 40000 45000Количество испытаний: 4 2 2 2 2 2 2 2 2 1 1 1 1(в Кбайтах) : 4 4 4 4 4 4 4 4 4 4 4 1 1 1 1
Максимальная запрашиваемая память, которую можно использовать = 162004, размер = 45000
=====
Размер LDA Выровн.Время (S) GFLOPS Остаток остаточной (норм) Проверка
1000 1000 4 0,024 27.2993 9.394430E-13 3,203742E-02 Pass1000 1000 4 0,006 107,6577 9.394430E-13 3.203742E-02. содержимое пропущено...35000 35000 1 99.141 288.3358 1.275258e-09 3.701880e-02 pass40000 40000 1 146.370 291.5210 1.516881e-09 3.373595e-02 pass45000 45000 1 213.964 283.9451 2.008430e-09 3.533621e-02 pass
Сводка по производительности (Гфлопс)
Размер LDA Align. Среднее Максимальное1000 1000 4 86,9113 107,6577...содержание пропущено...40000 40000 1 291.5210 291.521045000 45000 1 283.9451 283,9451
Остаточные чекиintel intel intel для Linpack для Decles Memmores
. Shares rescemes rasteresntel ntel ntel ntel n.
. Этот тест был выполнен с размером задачи = 45000, что является настройкой по умолчанию. Настройка параметра должна быть регулируемой, чтобы улучшить бенчмаркинг.
3.1 Использование LINPACK: версия 9 с распределенной памятью0020
1. Просмотрите каталог mp_linpack , где доступен двоичный файл LINPACK, интегрированный с библиотекой MPI. Например,
cd /home/rangsiman/intel/compilers_and_libraries_2018.3.222/linux/mkl/benchmarks/mp_linpack2. Перед запуском теста LINPACK для системы с распределенной памятью необходимо загрузить необходимую переменную среды компилятора Intel и библиотеки MPI. первый.
<родительский каталог>/bin/compilervars.sh intel64<каталог mpi>/bin64/mpivars.shЕсли вы не установили Intel Parallel Studio XE, который предоставляет компилятор Intel и библиотеку MPI, прочтите этот пост.
3. В файле HPL.dat установите размер задачи (N) равным 10000 (строка 6).
10000 Nsгде N (размер задачи) — размер матрицы, при которой наблюдались измеренные характеристики.
Для реального теста производительности Intel предлагает, чтобы N составляло 80% памяти, что наиболее подходит для максимальной производительности кластера. Поэтому N можно оценить по следующей формуле
sqrt(( Размер памяти в Гбайтах * 1024 * 1024 * 1024 * Количество узлов) /8 ) * 0,80
Например, в моем случае общая память составляет 32 ГБ, а свободная память — 28 ГБ.
Далее вычисляется N на основе общего объема памяти
sqrt(( 32 * 1024 * 1024 * 1024 * 1 ) /8) * 0,80= 52428 (~ 53000)Далее вычисляется N на основе свободная память
sqrt(( 28 * 1024 * 1024 * 1024 * 1 ) /8) * 0,80= 49042 (~ 50000)4. Значение параметров Ps и Qs, установленных в файле HPL.dat , представляет собой количество строк и столбцов в сетке процесса соответственно.
Обратите внимание, что Ps должен быть меньше или равен Qs. Кроме того, Ps * Qs должно равняться количеству процессоров MPI, указанному в (4). Например, я установил количество процессов MPI равным 12, поэтому Ps и Qs в HPL.dat могут быть следующими:
1 Количество сеток процессов (P x Q)3 Ps4 Qsили (альтернативно)
1 Количество технологических решеток (P x Q)2 Ps6 Qsили (альтернативно)
2 Количество технологических решеток (P x Q) 5 5 Ps2 0 3 6 4 Qs5. Установите порог подкачки в строке 27 в HPL.dat на 64, в противном случае оставьте значение по умолчанию.
64 порог переключения6. Установите MPI_PROC_NUM и MPI_PER_NODE в сценарии runme_intel64_dynamic .
- MPI_PROC_NUM - общее количество процессов MPI
- MPI_PER_NODE - количество процессов MPI, этот параметр должен быть равен 1 или номеру сокета в вашей системе.
Используйте команду lscpu , чтобы проверить, сколько сокетов есть на вашем компьютере.
Например,
export MPI_PROC_NUM=12
export MPI_PER_NODE=2
Выполнить сценарий runme_intel64_dynamic ,
./runme_intel64_dynamic
7. Проверьте выходной файл
less xhpl_intel64_dynamic_outputs.txt
3.2 Результаты тестов для версии с распределенной памятью
Ниже приведен пример выходных данных моего узла LINP.
============================================== ===============================
HPLinpack 2.1 -- Высокопроизводительный тест Linpack -- 26 октября 2012 г.
Авторы: А. Петите и Р. Клинт Уэйли, Лаборатория инновационных вычислений, ЮТК
Модифицировано Петром Лущеком, Лаборатория инновационных вычислений, UTK
Модифицировано Жюльеном Лангу, Университет Колорадо Денвер
========================= ================================================== =====
...
Содержание пропущено
...
N: 50000
NB: 192
PMAP: картирование процесса колонки.
PFACT: справа
NBMIN: 2
NDIV: 2
RACT: CROUT
BCAS транспонированная форма
EQUIL : нет
ALIGN : 8 слов двойной точности
---------------------------------- -------------------------------------------------------------
....
Содержание пропущено
....
Кастор: столбец = 029760 Фракция = 0,595 ядра = 301530,44 MFLOPS = 359513.53
4444413 = 03.13. 03.13. 03.13. 03.13. 03.13. 03.13. 03. 03.13. 03.13. 03.13. 03.13. 03.13. 03.13.
castor : Column=031872 Fraction=0.635 Kernel=288518.77 Mflops=357777.99
castor : Column=032832 Fraction=0.655 Kernel=275671.09 Mflops=357173.61
castor : Column=033792 Fraction=0.675 Kernel=261768.88 Mflops=356300.48
castor : Column=034752 Fraction=0.695 Kernel=251046.82 Mflops=355550.94
castor : Column=039936 Fraction=0.795 Kernel=216555.89 Mflops=350960.15
castor : Column=044928 Fraction=0.895 Kernel=142837.25 Mflops=347347.11
castor : Столбец = 049920 Дробь = 0,995 Ядро = 60197,71 Мфлопс = 345636,08
================================== =============================================
Т/ V N NB P Q Время Gflops
------------------------------------------------ --------------------------------
WC00C2R2 50000 192 3 4 249,69 3.33764e+02
Начало HPL_pdgesv() время Сб 14 июля 14:28:08 2018
HPL_pdgesv() время окончания Сб 14 июля 14:32:17 2018
---------------- -------------------------------------------------- --------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)* N)= 0,0033573 ...... ПРОШЕЛ
============================================== ===============================
4. Сравнение результатов тестирования с суперкомпьютером SUMMIT.
(для версии с распределенной памятью)
4.1 LINPACK Benchmark суперкомпьютера SUMMIT, ORNL, США (1-е место в TOP500)
GV100, двухканальный Mellanox EDR Infiniband
- ядер ЦП = 2 282 544
- RMAX = 122,300,0 TFLOP/S
- RPEAK = 187 659,3 TFLOP/S
4.2 Linpack Benchmark of My Intel Xeon Node, Chalawan Head, NARIT, NARIT, NARIT, NARIT, NARIT, NARIT, THAILDARIT,012012012012012012012012. 10001202. nariT, narit, 4.2. V3 CPU Cores [email protected] (HT) ОЗУ память 32GB
Подробности конфигурации LINPACK
- Ядер ЦП = 12
- RMAX = 333,764 GFLOP/S = 0.
334 TFLOP/S 9015 = 0,334 TFLOP/S 9015 9015 9015 = 0,334 TFLOP/S 9015 9015 = 0,334 S./S 9015 = 0,334. = 0,461 терафлоп/с (12 физических ядер ЦП x 2,4 ГГц/ядро x 16 операций/цикл)
4.3 Эффективность
Другим наиболее часто используемым параметром для определения производительности HPC является Эффективность, которая представляет собой отношение Rmax к Rpeak (Rmax/Rpeak). ).
Эффективность саммита составляет (122 300,0,0 / 187 659,3) x 100 = 65,17 %
Эффективность моего Xeon Node составляет (333,764 / 460,8) x 100 = 72,43 %
4.4. Результаты, я настоятельно рекомендую вам прочитать эту статью, чтобы серьезно улучшить тест производительности вашего кластера с помощью MPI.
5.
Используйте LINPACK в ОС Windows
5.1 Инструкция
1. Перезагрузите ПК/ноутбук и закройте все программы перед запуском эталонного теста.
2. Перейдите к несжатой папке LINPACK, например,
C:\Users\rangs\Downloads\w_mklb_p_2018.3.011\benchmarks_2018\windows\mkl\benchmarks\linpack
3. Дважды щелкните bat-файл LINPACK, чтобы запустить его. тест
runme_xeon64.bat
Затем появится окно CMD и дождитесь завершения процесса. Это может занять несколько минут. Результаты будут записаны на файл win_xeon64.txt .
5.2. Спецификации моего ноутбука
Windows 10 Pro 64-разрядная система Процессор Intel Core i7-4750 HQ с тактовой частотой 2,00 ГГц ОЗУ 8 ГБ (доступно 7,89 ГБ)
- Частота процессора: 3,192 ГГц
- Количество процессоров: 1 ядер: 4
- Количество потоков: 4
5.
3 Результаты тестов моего ноутбука
- 0020
Тест LINPACK доступен не только для платформ Linux или Windows, вы также можете проверить производительность своего мобильного телефона с помощью LINPACK.
Загрузите тестовое приложение LINPACK из магазина приложений операционной системы вашего телефона.
Android: Mobile Linpack
- Xiaomi Redmi Note 3
- Android 6,0,1
- Номер ядер составляет 6
- CPU.
7. Ссылки
- https://www.thinkmate.com/inside/articles/intel-xeon-scalable
- https://www.top500.org/project/linpack/
- https: //www.top500.org/lists/2018/06/
- https://software.intel.com/en-us
- https://software.intel.com/en-us/mkl-linux-developer -guide-2019-beta-overview-of-intel-distribution-for-linpack-benchmark
- https://software.




В то время как обычные приложения редко показывают больше 20.
Не, ну а чего спорить, когда ты получаешь сплошные плюсы без каких либо серьезных минусов.
AVX-512 хотя бы умирает (и не факт, что умрет) мучительной смертью, следуя пожеланиям обычно нордически-сдержанного Линуса Торвальдса. В то время как Xeon Phi так и не сумел толком оторваться от взлетной полосы. Он задумывался, как ответ набиравшим силу GPGPU. Концепция была такая – давайте натыкаем кучу слабосильных( в Knights Corner использовалась архитектура Pentium), низкочастотных ядер с “православной” ISA и снабдим их зубодробительной длины SIMD. Все это неплохо работало ровно на одном бенчмарке (угадайте каком). Как только Xeon Phi сталкивался с критическими участками однопоточноно кода (а такими, например, являются огромных размеров “cвитчи” в MPI) – он немедленно шел на дно (кстати, ISA тут не при чем.) Всего этого можно было бы избежать, если б в качестве основного теста был взят не HPL, а хотя бы HPCC. Но увы, случилось так, как случилось….
patch
для реализации высокопроизводительного эталонного теста Linpack для IBM
, системы QS22 с процессорами PowerXCell 8i. Файл является патчем
, для HPL 1.0a.
от IBM
файл IBM_LICENSE.TXT
для IBM Уведомление об авторских правах для QS22 HPL
от IBM
файл IBM_README.txt
для README для IBM QS22 HPL
от IBM
Обновлено: 30 ноября 2008 г.
################################################### #######################
Эта версия представляет собой тест скомпилированного кода, который можно найти в каталоге linpack . Этот тест поддерживает только чистую систему OpenMP. Поэтому, пожалуйста, отключите технологию Intel Hyper-Threading. Подробности можно найти здесь.
3.011.tgz
29
Подождите процесса. завершено. Результаты тестов будут записаны в текстовый файл с именем lin_xeon64.txt
Время (S) GFLOPS Остаток остаточной (норм) Проверка 


..
675 Kernel=261768.88 Mflops=356300.48
..... ПРОШЕЛ
334 TFLOP/S 9015 = 0,334 TFLOP/S 9015 9015 9015 = 0,334 TFLOP/S 9015 9015 = 0,334 S./S 9015 = 0,334. = 0,461 терафлоп/с (12 физических ядер ЦП x 2,4 ГГц/ядро x 16 операций/цикл)