Posts about hpc (old posts, page 1)

High-Performance Computing, or the art of burning money faster than ever

Анализ и оптимизиране на производителността на научни кодове

Производителността е съществена характеристика на компютърните програми, използвани за симулиране и обработка на информация с научно и инженерно значение. Правенето и разбирането на високопроизводителни компютърни кодове е цяла наука, но известна част от нейната фундаментална основа се постарах да събера в 30-минутно представяне за целите на Втората работна среща на проекта IRC-CoSiM. На интересуващите се от тематиката предоставям следния PDF вариант на представянето (на английски език):

Second IRC-CoSiM Workshop presentation (PDF)

С благодарности към договор ДО-02-136/2008 (IRC-CoSiM).

Що е то HPC?

Що е то HPC и има ли то почва у нас? Кои са тези особености на хардуера и софтуера, които правят HPC уникална по рода си област на компютърното познание?

HPC или High Performance Computing е технически термин, с който се обозначава специфичен клас от хардуерни и софтуерни технологии, както и спецификата на тяхното програмиране и използване. Обикновено към класа на HPC отнасят научните и инженерни задачи, изискващи извършването на огромна по обем обработка на данни и използващи за целта мощни (супер-)компютри, които далеч надхвърлят по производителност средностатистическия домашен или бизнес компютър. Към HPC често (и неправилно) причисляват и т. нар. High Throughput Computing (или HTC). Въпреки, че целта и при HPC, и при HTC е да се обработи възможно най-много информация за единица време, при HTC информацията обикновено постъпва под формата на множество работни единици — заявки или транзакции. Типичен пример за HPC е детайлното моделиране на климатичната обстановка с цел добиване на по-точна прогноза за времето, а за HTC — обработването на милиони заявки за търсене в огромна база данни (напр. Google). Тъй като повечето HPC задачи обработват информация под формата на масиви от числа с плаваща запетая, проиводителността при тях обикновено се измерва в милиарди операции с плаваща запетая за секунда, Gflop/s (гигафлопи за секунда или просто гигафлопси), където flop е съкратено от floating-point operation. С развитието на суперкомпютърната техника префиксът на мярката постепенно се измества от гига- към тера-, като най-бързият суперкомпютър в света, Roadrunner на лабораторията в Лос Аламос, има производителност от над 1 Pflop/s (петафлопи за секунда). При HTC производителността обикновено се измерва в транзакции за секунда, tps, със съответните степенни префикси от системата SI.

HPC се различава от обикновената изчислителна техника, както в хардуерен, така и в софтуерен аспект. Суперкомпютрите са бързи. При това, те не са просто бързи, а БЪРЗИ, като бързодействието често пъти се постига с нетрадиционни за масовата техника похвати. Като пример мога да посоча факта, че когато масата персонални компютри в България през 80-те години на миналия век са 8-битови скаларни CISC архитектури, работещи на честоти 1—4 MHz и извършващи едва десетина Kflop/s без допълнителни математически копроцесори (или транспютри), то типичният представител на суперкомпютрите от него време Cray-1 е 64-битова векторна RISC архитектура с тактова честота 80 MHz и пикова производителност от 250 Mflop/s. Въпреки, че последната изглежда смешно на фона на съвременната микропроцесорна техника, за реализиране на подобно устройство през тях години е било необходимо да се използва екзотичната емитерно свързана логика (ECL), осигуряваща висока скорост на превключване за сметка на много ниска степен на интеграция и ОГРОМНА консумирана мощност, изискваща иновативни и скъпи охлаждащи системи. Друг подход за увеличаване на изчислителната мощност, доминиращ HPC пазара и в наши дни, е едновременното използване на множество (до стотици хиляди) процесорни елементи — т. нар. масивно-паралелни архитектури. При това инженерната сложност се пренася от построяването на свръхбърз микропроцесор към измислянето на начин за ефикасно свързване на процесорните елементи. За целта обикновено се използват специализирани превключващи елементи (напр. SeaStar 2 в XT3/XT4 на Cray), осигуряващи предаването на информацията по сложна система от връзки. В зависимост от броя на свързаните процесори, свързващата подсистема може или да бъде от тип “телефонна централа” (crossbar), която осигурява директна комутируема свързаност от тип всеки с всеки (напр. IBM SP2), или информацията да се маршрутизира върху дву-, три- или повече измерна мрежа от изчислителни възли, подобно на силно структурирано и опростено подобие на Интернет. Кросбар мрежите осигуряват огромна пропускателна способност (измервана в GiB/s) по множество от независими канали и ниска латентност (времето между стартиране на операция по пренасяне на информация и нейното физическо завършване), но сложността им нараства експоненциално с броя на свързаните процесори, а разширяването им за включване на допълнителни процесори е практически невъзможно, поради което те почти не намират приложение в съвременната HPC техника. Далеч по разпространени са мрежите с маршрутизиране на трафика. Освен специализираните комуникационни контролери, широко приложение намират и мрежовите преносни среди с общо предназначение InfiniBand и Ethernet, последната главно в съвременната инкарнация с пропускателна способност от 10 Gbps.

Особеният хардуер изисква и особено програмиране. Отличителна черта на HPC софтуера е, че логиката в него е сведена до минимум, а данните са структурирани по възможно най-прост начин, позволяващ тяхната паралелна и/или векторна обработка. Корените на голяма част от програмните кодове датират от времена, когато доминиращ програмен език е бил FORTRAN 77, понятието “структуриран тип данни” е било приемано с недоумение, а на оператора GOTO не се е гледало с отвращение. По традиция известна част от HPC приложенията продължават да се пишат на FORTRAN, понятието “структуриран тип данни” продължава да буди недоумение сред определени кръгове, а операторът GOTO продължава да живее щастливо сред милионите редове програмен код. Смело може да се твърди, че кодът на един съвременен браузър е многократно по-сложен и от най-сложната програма за симулации в областта на твърдотелната физика. И въпреки това, писането на качествен и бърз HPC код е нетривиална инженерна задача и изисква много задълбочено познаване на основите на микропроцесорната и мрежова технология, лежаща в основата на съвременните компютърните архитектури.

Елементарна задчка за размисъл: защо следният код

int bigarray[DIM1][DIM2], i, j;

for (i = 0; i < DIM1; i++)
  for (j = 0; j < DIM2; j++)
    bigarray[i][j] *= 2;

се изпълнява шест пъти по-бързо (при DIM1 = DIM2 = 10000) от напълно аналогичния

int bigarray[DIM1][DIM2], i, j;

for (j = 0; j < DIM2; j++)
  for (i = 0; i < DIM1; i++)
    bigarray[i][j] *= 2;

(жокер: причините са повече от една)

Програмирането на (масивно-)паралелни машини предоставя допълнителни предизвикателства. За целта са развити няколко програмни техники и парадигми, които предлагат различно съотношение между леснотата на тяхното използване и мащабируемостта на резултатните изпълними кодове. В най-простия случай се разчита на компилатора да открие и по възможност паралелизира части от програмния код (т. нар. автоматична паралелизация), с която задача различните компилатори се справят с променлив успех. В най-сложния случай цялата грижа за комуникацията и синхронизацията между отделните изчислителни елементи е оставена на програмиста, като на последния се осигурява само стандартен набор от комуникационни примитиви (MPI, PVM и др.). Обикновено това е методът, използван в най-производителните и мащабируеми кодове. По средата на спектъра са т. нар. “data parallel” парадигми, при които се използват или специални диалекти на известни програми езици, разширени с допълнителни паралелни конструкции, напр. High Performance Fortran (HPF) или Unified Parallel C (UPC), или стандартните диалекти се разширяват с позволените в тях механизми, напр. OpenMP (реализиран като набор от #pragma директиви в C и като специално форматирани коментари във Fortran). За MPI и OpenMP ще стане дума по-нататък в следващите писания по въпроса.

Има ли HPC почва у нас? Учудващо за мнозина, но отговорът е утвърдителен. Компютрите се използват за решаване на инженерни и научни задачи в България още от времената на машините от Единната Система и СМ, “аналози” на популярни за времето си мейнфрейм машини на IBM и миникомпютри на DEC. През 90-те години на миналия век, когато връх на персоналните компютри в родината бяха грешащият при деление Pentium (а само по експота и панаири може да се види мускулестият му братовчед Pentium Pro), в различни изчислителни центрове в страната “мелят” 64-битови RISC машини (една от които кротко залежава като музеен експонат под бюрото ми във ФзФ). А откак преди година България се сдоби и с 8192-ядрен Blue Gene/P, то не остана и капка съмнение, че у нас HPC има почва. Доколко стабилна е тя, бъдещето ще покаже.

Intel Core i7 vs Xeon

Мине се не мине някое време и Intel изважда от голямата си технологична шапка поредния заек. И макар повечето зайци на Intel, както и на другите “иноватори” в информационната индустрия, да са просто преродените души на умрелите динозаври, всички вкупом се втурват да правят тестове и да възхваляват новите продукти. Реших, че нямам причина да изоставам от тази всеобща треска и се захванах да проверя, става ли Core i7 за научни пресмятания, не става ли.

Вместо предисловие

Intel най-накрая осъзна, че съвременните интензивни приложения изискват все по-бърз достъп до все по-големи обеми информация, съхранявана в RAM паметта, чиято пространствена кохерентност в общия случай е недостатъчно голяма и дори 2x6 MB L2 кеш на последните поколения Xeon не са достатъчни за преодоляване на това най-тясно гърло на системата (изключвам дисковата и мрежова входно/изходни подсистеми). AMD отдавна интегрираха контролера на паметта в чипа на процесора, което в комбинация с HyperTransport шината създаде изключително производителния при обща употреба Opteron. Не случайно Cray избраха Opteron като наследник на Alpha в техните суперкомпютри (като частичната съвместимост на шините вероятно също е допринесла за решението). Най-бързият суперкомпютър към настоящия момент, RoadRunner на IBM, също използва Opteron за x86 гръбнака. Opteron се използва и в HECToR, 11328-ядреното чудовище на EPCC, на което имах удоволствието да работя по време на престоя си в Единбург в края на миналата година.

Отговорът на Intel, след години на разработки и лабораторни тестове, беше микроархитектурата Nehalem, наследникът на Core 2, известна под търговското наименование Core i7. При нея контролерът на паметта е интегриран в процесорния чип, а йерархията на кеша е усложнена с добавяне на трето ниво (L3). За разлика от Core 2, където кешът от второ ниво се споделя от две ядра, при Nehalem всяко ядро разполага със собствен кеш от второ ниво, макар и силно редуциран по обем — само 256 KiB/ядро. Следният изход от инструмента cpuinfo на Intel показва организацията на ядрата и кешовете в процесор Core i7 920 (Nehalem):

Processor     : Intel Core i7 920
Architecture  : x86_64
Hyperthreading: disabled
Packages   : 1
Cores      : 4
Processors : 4
=====  Processor identification  =====
Processor       Thread  Core    Package
0               0       0       0
1               0       1       0
2               0       2       0
3               0       3       0
=====  Processor placement  =====
Package Cores           Processors
0       0,1,2,3         0,1,2,3
=====  Cache sharing  =====
Cache   Size            Processors
L1      32 KB           no sharing
L2      256 KB          no sharing
L3      8 MB            (0,1,2,3)

За сравнение, организацията в Xeon E5420 (Core 2) е следната:

Processor     : Intel Xeon E5420
Architecture  : x86_64
Hyperthreading: disabled
Packages   : 1
Cores      : 4
Processors : 4
=====  Processor identification  =====
Processor       Thread  Core    Package
0               0       0       0
1               0       1       0
2               0       2       0
3               0       3       0
=====  Processor placement  =====
Package Cores           Processors
0       0,1,2,3         0,1,2,3
=====  Cache sharing  =====
Cache   Size            Processors
L1      32 KB           no sharing
L2      6 MB            (0,1)(2,3)

Добавянето на кеш от трето ниво ни връща в годините на RISC процесорите от типа на POWER на IBM, където подобна организция беше нещо нормално, налагащо се от факта, че суперкомпютърната индустрия дълго време отказваше да използва по-нови поколения памети, разчитайки на по-бавни, но изпитани с времето технологии.

Системите

Като площадка за тестване на Xeon E5420 е използван един от възлите на клъстера physon, а достъп до машина с Core i7 920 беше любезно предоставен от Васил Колев (a.k.a. ManiaX). Съществените в случая характеристики на системите са както следва:

Система с Xeon E5420

CPU: 2 x Intel Xeon E5420 (2.5 GHz, 1333 MT/s FSB)
MoBo: Supermicro X7DBT-INF
Chipset: Intel 5000P
RAM: 8 x 2 GiB ECC DDR2-667

Система с Core i7 920

CPU: Intel Core i7 920 (2.66 GHz, 4.80 GT/s QPI, спрян HT)
MoBo: Intel DX58SO
Chipset: Intel X58
RAM: 3 x 2 GiB DDR3-1066 (tripple channel)

Тестовете

Науката е или физика, или колекциониране на пощенски марки.”

—Е. Ръдърфорд

Опирайки се на горното твърдение, ограничих тестовете до едно синтетично и две реални приложения за симулиране на физични процеси и свойства на вещества в наноразмерната област.

memset тест

memset тестът е елементарно многонишково приложение, всяка нишка на което многократно запълва динамично заделен блок от 512 MiB (229 байта), използвайки стандартната библиотечна функция memset(3). Приложението е компилирано с Intel C Compiler 11.0.074 с ниво на оптимизация O3 и целево множество от инструкции SSE4.1 за теста на Xeon E5420 и SSE4.2 за теста на Core i7 920, което свързва кода със силно оптимизирана реализация на memset(3).

Изпълнението с една нишка оправдава обещанията на Intel, като i7 920 постига 8863 MB/s в сравнение с 3675 MB/s при Xeon E5420. Двунишковото изпъление изяжда почти цялата налична пропускателна способност на връзката между процесор и памет, достигайки 13172 MB/s при i7 920 и 4188 MB/s при E5420. Изпълнението на 4 нишки показва, че е на лице насищане с 13416 MB/s при i7 920 и 4192 MB/s при E5420.

Чипсетът Intel 5000P предоставя независима шина до всяко процесорно гнездо. И наистина, при двунишково изпъление, когато всяка нишка работи в отделен физически процесор, общата пропускателна способност достига 5440 MB/s, като при 4 нишки (по две на физически процесор) тя е 5768 MB/s. При 8 нишки се наблюдава лек спад до 5728 MB/s.

md тест

Тестът представлява типична компютърна симулация от областта на физиката на кондензираните среди и разглежда еволюцията във времето на положенията и скоростите на атомите на моделна въглеродна нанотръба. За целта се използва методът на молекулната динамика, от където и идва наименованието на теста. Особеното на този тест е, че всички работни променливи се побират напълно в обема на последното ниво от кешовата йерархия и на двата разглеждани процесора.

Без да се впускам в подробности за организацията и работата на програмата ще кажа, че компилаторът на Intel векторизира вътрешните цикли и произвежда векторни SSEx опкодове, което позволява на програмата да използва всичката изчислителна машинария, налична във всяко процесорно ядро. За разлика от следващия тест, тук не се използват никакви външни специализирани библиотеки за математически пресмятания.

Core i7 920 постига производителност от 155.9 стъпки/s, докато при Xeon E5420 тя е 137.3 стъпки/s. Нормирани на тактовата честота на процесора, горните производителности (в единици наностъпки/такт) се редуцират до 58.6 при i7 920 срещу 54.9 при E5420, т.е. за подобен род пресмятания микроархитектурата на Core i7 е с около 7% по-ефективна спрямо Core 2 при една и съща тактова честота.

qe тест

Quantum Espresso представлява тежък код за пресмятане на квантовомеханичните свойства на кондензирани среди с методите на теорията на функционала на електронната плътност в базис от плоски вълнови функции (иначе казано PWDFT). Изисква огромно количество памет за съхранение на работните данни, върху които прилага множество матрични операции и дискретни трансформации на Фурие. Основната изчислителна работа се поема от три специализирани външни библиотеки: BLAS и LAPACK за матричните операции и FFTW за трансформациите на Фурие. Програмата е многонишкова, като всяка нишка е отделен процес, а за обмяна на данни между процесите се използва Open MPI, която среда ще разгледам в по-следващите писания за парадигмите и методите на паралелното програмиране. Използва се оптимизирана реализация на BLAS и LAPACK в Intel Math Kernel Library (IMKL), а FFTW е реализирана под формата на интерфейсен слой над IMKL.

Програмата може да се изпълнява както в еднонишков (сериен), така и в многонишков (паралелен) режим. Времето за изпълнение на симулацията в сериен режим на Core i7 920 е 122 минути (11.80 сим/ден), докато при Xeon E5420 то е 143 минути (10.07 сим/ден). Ефективността, измервана в единици сим/(ден•GHz), е както следва: 4.44 за i7 920 и 4.03 за E5420. Core i7 920 е с 10% по-ефективен от Xeon E5420 при този род пресмятане.

Паралелният режим на работа позволява да се наблюдава влиянието на северния мост при Xeon, както и влиянието на споделянето на L2 кеша между ядрата. С 4 процеса Core i7 920 успява да “смели” задачата за 45.41 минути (31.71 сим/ден), докато при E5420 времето варира от 48.27 мин (29.83 сим/ден) до 60.00 мин (24.00 сим/ден) в зависимост от разпределението на процесите по ядрата на двата микрочипа. Най-лошият случай (24.00 сим/ден) се реализира, когато всички 4 процеса се изпъляват в рамките на един микрочип, а най-добрият (29.83 сим/ден) — когато всеки процес се изпълнява без да споделя L2 кеш с друг процес. Междинният случай, при който два по два процесите споделят общ L2 кеш, но двойките се изпълняват в различни микрочипове, се изпълнява за 54.26 мин (26.54 сим/ден).

Вижда се, че при 4 процеса Core i7 920 извършва пресмятането 2.69 пъти по-бързо, единичен Xeon E5420 — 2.38 пъти по-бързо, а два Xeon E5420 — 2.96 пъти по-бързо или 2.64 пъти по-бързо, в зависимост от постановката.

В страни от явното по-доброто мащабиране на програмата върху Core i7 при еднопроцесорни конфигурации, резултатите от двата Xeon процесора са много поучителни и следва да се имат предвид, както от потребителите на подобни многоядрени системи, така и от техните администратори.

Някои изводи

От направените тестове мога да заключа, че Core i7 е достоен процесор за работната станция на всеки сметач. Дори най-евтиният представител на семейството, Core i7 920, се представя по-добре от по-скъпия Xeon E5420. При многонишкова работа i7 920 се представя по-добре от E5420 в еднопроцесорния случай, като последният разгръща способностите си едва в многопроцесорни конфигурации.

X11 forwarding with “X11UseLocalhost no”

Just a quick tip. If you’ve ever tried to run sshd with the option X11UseLocalhost set to no (e.g. in a cluster environment where interactive jobs running not on the login node should be able to display something), you might have observed that X11 forwarding suddenly stops working. And although the DISPLAY variable is set accordingly and xauth list shows that authentication tokens are present, X clients still can’t connect:

hristo@cn001:~$ echo $DISPLAY
cn001:10.0
hristo@cn001:~$ xauth list
cn001.local:10 MIT-MAGIC-COOKIE-1 0123...
hristo@cn001:~$ xterm
xterm Xt error: Can't open display: cn001:10.0

And it’s even worse:

hristo@cn001:~$ telnet cn001 6010
Trying 10.1.1.1...
telnet: Unable to connect to remote host: Connection refused

The root of the problem stems from the fact that sshd usually binds only to the first address family it finds in the system and if your system has IPv6 enabled (e.g. the default on Ubuntu Server 7.10) it ends up binding only a tcp6 socket (and the X11 client library tries to establish a regular TCP connection):

hristo@cn001:~$ netstat -an | grep 6010
tcp6 0 0 :::6010 :::* LISTEN

In order to fix this you can either disable IPv6 in the kernel or simply add the following option to /etc/ssh/sshd_config:

AddressFamily inet

After you restart the SSH server it will no longer use IPv6 and will start binding its X11 proxy listeners to the usual IPv4 INADDR_ANY of 0.0.0.0.

InfiniBand on Ubuntu Server 7.10

If for some obscure reason you ever want to use Ubuntu Server 7.10 in a HPC scenario where your compute nodes are interconnected through InfiniBand fabric bear this in mind — Ubuntu’s IB support is broken and it has been in such a state for at least an year!

Besides from not providing the full OFED package, Ubuntu also gives us errors in udev’s configuration, namely in /etc/udev/rules.d/20-names.rules. On a pristine system the Infiniband section reads:

...
# Infiniband devices
KERNEL=="umad[0-9]*",         NAME="infiniband/%k"
KERNEL=="issm[0-9]*,          NAME="infiniband/%k"
KERNEL=="uverbs[0-9]*,        NAME="infiniband/%k"
KERNEL=="ucm[0-9]*,           NAME="infiniband/%k"
KERNEL=="rdma_cm",            NAME="infiniband/%k"
...

Noticed it? The closing double quotes on the lines for issm, uverbs, and ucm are missing. Thus udev ignores those lines as errors and puts theirs device nodes in /dev instead of /dev/infiniband/ where most software expects them to be. For example, OpenMPI’s openib BTL fails to run with such a configuration.

Correct the section so that it reads:

# Infiniband devices
KERNEL=="umad[0-9]*",         NAME="infiniband/%k"
KERNEL=="issm[0-9]*",         NAME="infiniband/%k"
KERNEL=="uverbs[0-9]*",       NAME="infiniband/%k"
KERNEL=="ucm[0-9]*",          NAME="infiniband/%k"
KERNEL==“rdma_cm",            NAME="infiniband/%k"

Now reboot and your device nodes will be placed where they are meant to be.