Няколко мита за RISC-V процесорите, които е време да забравим – втора част

В първата част се запознахме с основните моменти на RISC-V процесорната архитектура, с размера на програмите при използването на RISC-V процесорните команди, с компресираните инструкции и паралелното декодиране на данните. Сега ще продължим с условните инструкции, ще се спрем върху векторната обработка, целочисленото препълване и други характерни технологии на RISC-V процесорната архитектура.

Да си припомним от миналия път, че при RISC-V не се използват условни инструкции. По този начин значително се затруднява реализацията на Out-of-Order Execution (OoOE), а това е много важно за създаването на високопроизводителни чипове. Всъщност нито един от съвременните 64-битови ARM процесори (ARMv8 и нагоре) нямат условно изпълнение именно поради тази причина. Там присъстват само безусловните инструкции CSEL, CSINC.

От друга страна в ARM лагера липсата на условни инструкции осезателно намалява производителността дори и при по-опростените процесори, произведени по поръчка. Предполага се, че при чиповете с малък брой транзистори е твърде трудно реализирането на необходимата логика за предсказване на условните преходи, благодарение на които се избягва намалението на производителността заради грешките в прогнозирането на точния преход (miss-prediction).

Но при RISC-V процесорната архитектура е използвано интересно решение. Ако се вгледаме в ядрата от процесорната фамилия SiFive 7 ще видим, че в тях на практика е реализирана МОС логиката, за да се избегне спада на производителността. Късите разклонения от една процесорна инструкция могат да бъдат обединени в една обща ARM-подобна инструкция. Нека да разгледаме следния код:

    # RISC-V code
    BEQ x2, x3, done    # jump to done if x2 == x3
    ADD x4, x5, x6      # x4 ← x5 + x6 
done:
    SUB x1, x3, x2

Тъй като условният преход към done е само една процесорна инструкция, чиповете от фамилията SiFive 7 разпознават този шаблон и го обединяват в една обща инструкция. Във формат на псевдокод това изглежда по следния начин:

 # RISC-V code
    # if x2 != x3 then x4 ← x5 + x6 
    ADDNE x2, x3, x4, x5, x6 
    SUB x1, x3, x2

Тази функционалност носи името short-forward-branch-оптимизация. Специално искам да подчертая, че ADDNE инструкцията не съществува – това е просто начин за по-лесно обясняване на случващото се. Преимуществата на този подход е, че се избягва използването на цикли. А това означава, че няма да ни се налага да правим технологични разходи за откриване на грешките при предсказването на условните преходи, които дори изпразват контейнера за процесорни инструкции.

Четвърти мит: RISC-V използва остаряла векторна обработка вместо съвременни SIMD инструкции

Някои специалисти от ARM сферата искат да създадат впечатление, че дизайнерите на RISC-V архитектурата са заседнали в миналото и не са в течение на най-новите достижения в тази област. Причината е, че в RISC-V се използва вектора обработка вместо SIMD (Single Instruction Multiple Data). Преди време това бе много популярно в старите суперкомпютри Cray. По-късно SIMD бяха добавени в х86 процесорите за мултимедийните приложения.

На пръв поглед изглежда, че SIMD е по-нова технология, но това не е така. SIMD за първи път се появяват в компютъра Lincoln TX-2 използван за реализацията на първия графичен интерфейс с име Sketchpad.

Векторната обработка в суперкомпютрите Cray е много по-съвършен начин за обработката на голямо количество разнообразни данни. Причината, заради която тези машини изпаднаха в немилост е, че тези мощни компютри се произвеждаха поединично, а обикновените персонални компютри бяха многократно повече и оказаха съответното влияние.

По принцип SIMD инструкциите бяха добавени в х86 твърде хаотично и без предварително планиране, само и само да се получи неголямо повишение на скоростта при работа с мултимедия.

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

Фактът, че Cray е използвал векторна обработка през 80-те години на миналия век съвсем не означава, че векторната обработка е остаряла технология. Това е все едно да кажем, че колелото е остаряла технология, понеже се е появило много отдавна.

 Днес векторната обработка стана изключително актуална понеже от нея печели машинното обучение, съвременната сложна графика и обработката на изображения. Това са области, в които е необходима висока производителност. RISC-V специалистите не са единствените, които разбраха това. ARM добави свои собствени векторни инструкции за векторна обработка – SVE2 командите. Ако те бяха остарели и ненужни, едва ли щяха да бъдат добавяни в най-съвременните процесори.

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

Пример за това е Esperanto Technologies с чипа SOC-1. Това е едно типично решение базирано на RISC-V процесорни ядра, което успешно се конкурира с графичния процесор Nvidia A100. Разширителната карта A100 е специално разработена за ускоряване на алгоритмите за машинно обучение. Да добавим, че графичният процесор A100 има малко над 100 ядра. В същото време Esperanto Technologies реализира 1092 ядра в своя чип, който консумира едва 20 W. За сравнение A100 консумира от 250 до 300 W. 

Пети мит: Векторната обработка не е необходима – просто използвайте видеокарти

Друг характерен момент срещу векторната обработка е, че за по-дългите вектори изобщо не е необходим CPU. Нека да ги оставим на видеокартите.

Но при този подход възникват няколко проблеми:

• Далеч не винаги RISC-V кодът може да се изпълнява от високопроизводителните работни станции с мощни видеокарти
• Прехвърлянето на данните между CPU и GPU предизвиква сериозни латентности
• Видеокартите всъщност не са проектирани за векторна обработка с всеобщо приложение, въпреки че се използват за подобни цели и се справят доста добре

Но сега започнаха да се появяват компактни контролери с ИИ ускорители за машинно обучение. В тези малки и евтини системи никой няма да добави графична карта на Nvidia, която да обработва векторните данни.

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

Шести мит: съвременният ISA трябва да се справя с целочисленото препълване

RISC-V архитектурата е често критикувана за това, че не генерира хардуерно изключение при възникване на препълване при извършването на целочислени аритметични инструкции. В почти всяка дискусия относно RISC-V могат да се видят изказвания, че нейните дизайнери са заседнали в 1980-те години, когато никой не е проверявал възникването на целочислено препълване.

Темата е сложна и нека да започнем с по-простото. Повечето компилатори за популярните програмни езици по подразбиране не предизвикват и не допускат подобно препълване. Пример за това са:

• C/C++ и Objective-C
• Rust
• Go
• Java/Kotlin
• C# (трябва да се използва checked block)

В Java за изключването на подобно препълване е необходимо да бъдат извикани addExact и subtractExact. А при C# кодът трябва да бъда написан в контекста checked:

try {
    checked {
        int y = 1000000000;
        short x = (short)y;
    }
}
catch (OverflowException ex) {
    MessageBox.Show("Overflow");
}

В Go е необходимо да се използва програмната библиотека overflow с функциите overflow.Add, overflow.Sub или да се използват вариантите, предизвикващи Panic, каквито са overflow.Add, overflow.Sub.

Единственият популярен програмен език, предизвикващ целочислено препълване е Swift. Ако се разровим ще видим, че много хора са недоволни от това. Така че изтъкването на тази особеност при RISC-V изглежда твърде странно.

Седми мит: обработването на целочисленото препълване е твърде раздуто

При обсъждането на целочисленото препълване често се твърди, че RISC-V изисква четири пъти повече код в сравнение с другите процесорни архитектури. Това е валидно само в най-лошия случай. Повечето случаи могат да бъдат решени чрез само една инструкция за условен преход.

Проверка за целочислено препълване при събиране на две числа без знак:

add t0, t1, t2 # t0 ← t1 + t2
bltu t0, t1, overflow # goto overflow if t0 < t1

Цели числа, когато е известен знакът на едното число:

addi t0, t1, 42 # t0 ← t1 + 42
blt t0, t1, overflow # goto overflow if t0 < t1

Общият случай с два операнда, за които знакът е неизвестен:

add t0, t1, t2 # t0 ← t1 + t2
slti t3, t2, 0 # t3 ← t2 < 0
slt t4, t0, t1 # t4 ← t0 < t1
bne t3, t4, overflow # goto overflow if t3 ≠ t4

Осми мит: целочисленото препълване е лесно за реализиране

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

Регистрите на състоянието извеждат споделеното състояние и по този начин създават зависимости между процесорните команди. Ето защо RISC-V архитектурата е специално проектирана да няма каквито и да било регистри на състоянието. Така например, инструкциите за условен преход директно сравняват два регистъра без да се използва страничен регистър на състоянието.

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

Изводи

По-голямата част от критиките към RISC-V процесорната архитектура се дължи на неразбирането на тази технология и липсата на една по-обща картина. Начинът, по който RISC-V дава възможност за създаването на една хетерогенна изчислителна среда с процесорни ядра, които са оптимизирани за извършването на различни типове изчисления, които работят съвместно и паралелно, е съвсем необичайно за хората.

Но така или иначе, това не е нова идея. Playstation 3 имаше аналогична архитектура, която носеше името Cell, в която се използваше едно ядро с общо предназначение Power Processor Element (PPE) плюс няколко векторни процесорни ядра със специално предназначение Synergistic Processing Elements (SPE).

Само че PPE и SPE имаха различни набори процесорни инструкции, което силно усложняваше работата с архитектурата Cell. В сравнение с нея, архитектурата на съвременните RISC-V системи е значително по-добра, понеже има еднакъв базов набор от команди за ядрата и регистрите от всички типове.