Как стать автором
Обновить

Комментарии 53

Увы пока я не понял что же новое появляется.
VLIW тоже уже лет 20-25, MIC — это просто увеличение параллелизма, что давно используется. Хотя бы в тех же видеокартах.
НЛО прилетело и опубликовало эту надпись здесь
Колеса от велосипеда?
Ну хз.
НЛО прилетело и опубликовало эту надпись здесь
Коллега, не знаю где вы взяли фотографию «Эльбруса», но на столе там навскидку стоит классическая ДВК-2. Кробочка справа — два пятидюймовых дисковода, под монохромным монитором — блок процессора с тремя белыми кнопочками (они так забавно снизу вверх включались). Первая включение, вторая — запуск процессора, третья — таймер. Клавиатура тоже характерная. Возможно, что это переделка под эльбрусовский терминал, но что-то мне сомнительно. Я именно в такой монитор три года подряд пялился:

image

По сути топика — не все языки «последовательны». Современные функциональные языки (да взять хотя бы тот же LabVIEW) — уже вполне себе параллельны. Ну то есть, если участки кода не связаны между собой потоками данных (принцип DataFlow), то они исполняются параллельно. Если я, скажем, в коде имею пару циклов (While или For), то они исполняются на двух процессорах, мне не надо прилагать вообще никаких дополнительных усилий к распараллеливанию. Конечно, это происходит не на низком уровне суперскалярного процессора, а на уровне компилятора — он автоматом создаёт два (или больше, если надо) потока, исполняющихся параллельно. Иногда даже приходится прилагать усилия, чтобы запретить параллельное исполнение участков кода, где это не нужно. Ну и стандартные средства для работы с паралельным кодом (очереди, семафоры, рандеву и т.п.) уже встроены в язык. Так что не всё так плохо.
Коллега, не знаю где вы взяли фотографию «Эльбруса», но на столе там навскидку стоит классическая ДВК-2. Кробочка справа — два пятидюймовых дисковода, под монохромным монитором — блок процессора с тремя белыми кнопочками (они так забавно снизу вверх включались). Первая включение, вторая — запуск процессора, третья — таймер. Клавиатура тоже характерная. Возможно, что это переделка под эльбрусовский терминал, но что-то мне сомнительно. Я именно в такой монитор три года подряд пялился:

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

image

Тут, пожалуй больше похоже на правду (впрочем, точно сказать может лишь тот, кто видел это чудо живьём).
Вообще жаль, конечно, что фотографий Эльбруса не так много существует.
НЛО прилетело и опубликовало эту надпись здесь
Да мы не спорим, мы просто ностальгируем. :)

В качестве терминала, конечно её можно было использовать — там по-моему ещё пара пустых слотов в корзине оставалась, так что можно было сделать и вставить терминальную плату. Но тут у меня есть сомнения — ДВК2 с дискет порой грузилась через раз, вряд ли столь ненадёжное решение использовали в составе Эльбруса. Скорее всего это просто часть интерьера НИИ, в котором и сделали фотографию.
НЛО прилетело и опубликовало эту надпись здесь
А какие перспективы у итаника?
Itanium — живой. (Я не говорю «живее всех живых» :). К выходу совсем скоро готовится ноый Itanium Poulson с такой спецификацией: 32nm process, 8 cores, 32 MB of last level cache, Hyper-Threading technology support. The CPUs will add Instruction Replay Technology, and new instructions, and will be compatible with existing Itanium 9300 series.
Понятно, что выходит. У ноклы, вон, тоже выходит. Фигня какая-то выходит.

Вопрос в том, какие у этого «выходит» перспективы? Сколько вендоров с ним живут? Сколько софта пишется в рассчёте на него?
Вопрос о перспективах вообще любой штуки — дело очень тонкое, даже прогноз погоды на завтра сбывается далеко не всегда.
Но, исходя из здравого смысла, подумайте, зачем компании вкладывать деньги в разработку и производство заведомо провального железа, которое никто не берет и никто под него не пишет?
Ходят слухи, что это последний Итаниум.
И то он выход из-за обязательств перед вендорами.
Intel никогда не комментирует слухи.
Но мне просто интересно — а как вы себе это представляете — «из-за обязательств перед вендорами»?
Ну в частности HP очень много средств вложила в Итаниумы, и я полагаю что без долгосрочных договоренностей с Интел этих вложений не было бы.
Насколько я помню, HP обещает чуть ли не десятилетнюю поддержку своих платформ на этих процессорах.
Любой ОЕМ берет процессоры не для себя, а для продажи. Поэтому вы описвываете такую ситуацию — ОЕМ берет неходовые системы и впаривает их несчастным пользователям со словами «берите, потому что производитель обещает вскоре выпустить новую версию той же системы, которую мы вам снова продадим и обслужим». Что-то не совсем сходится, да.

А вообще Itanium — нишевое решение. На вашем домашнем компьютере оно точно не появится, но в НРС области оно вполне живое.
> но в НРС области оно вполне живое.
Ок, живое, сколько в top500 итаниумов?
Ровно 1 штука.
> Поэтому вы описвываете такую ситуацию…
Ну а насчет каких-то предпологаемых слов OEM-щиков — покупателю абсолютно пофиг, в общем случае, какой процессор используется в высокопроизводительных решениях. Это дело OEM-производителя и производителя комплектующих. А там уже играет роль договоренности топ-менеджмента. Главное для покупателя, чтобы весь покупаемый комплекс (а марка процессора там даже не самое главное), отвечал его задачам.
PS: как ни странно, «нишевое» решение на первом итаниуме, валяется у меня дома, и даже было в рабочем состоянии, когда последний раз запускал.
Про MIC уже 2 года слышу «щас-щас», и где оно?
Intel MIC в очередной раз сменил имя, но теперь-таки вышел в продакшен. Про это уже сейчас можно нагуглить, а мы скоро напишем отдельным постом.
А где можно узнать ТТХ и цены конкретных моделей?
Когда человек, пишущий от имени компании, посылает «по-гуглить» выглядит ну как минимум странно…
Человек не посылает, а просит немного подождать, когда будет готова полноценная статья, чтобы не писать обрубков мыслей в каментах. Кстати, несколькими постами ниже пресловутый MIC упоминается по имени — Xeon Phi. Так что никаких загадок :)
схема предсказаний (в отношении условных переходов) была, к сожалению, далеко не у всех скалярных процессоров :)
Распараллеливание в любом случае упрётся в закон Амдала, так что хорошо бы всё-таки частоты суметь повысить, ведь большинство прикладных программ последовательны.
> ведь большинство прикладных программ последовательны.

Большинство алгоритмов, используемых в прикладных программах, могут быть эффективно распараллелены.
Действительно, но, к сожалению, в обычных прикладных программах есть множество зависимостей по данным (конфликты информационной зависимости будут проявляться при параллелизме). В этой связи, удобнее всего работать с большими циклами, как во многих научно-технических задачах с большими сетками. Иногда вместо схемы предсказаний в таких случаях, используют схему насыщения для более точного предсказания перехода.
Параллельность на языка или компилятора пытались делать давно, по крайней мере еще в 90е это было на слуху. Но видимо специализация так и не позволила выйти в тренд. Как тут верно заметили может быть функциональные языки, которые могут описывать множество потоков, смогут вытащить ситуацию. но боюсь что придется грандам что-то делать с совместимостью с x86.

Осмелятся ли они вытащить на рынок, хотя бы серверный ( потому что там функциональные языки приобретают вес ), процы и соответственно системы с новой архитектурой, готовой к большему параллелизму? Как скоро появятся ОС и прочее в экосистеме серверного ПО? Или мы еще лет 10 будем иметь x86 только что бы поднять линукс и веб сервер, который будет уже грузить специфичное окружение? Или появятся erlang серверы имеющие только необходимый минимум?
Лет 10-то уж практически точно.

Машина без совместимости с развитой софтварной экосистемой очень мало пригодна для реальной жизни, даже на сервере. Но эта совместимость может быть обеспечена бинарной трансляцией, например.

Если же нужна именно большая параллельность для большого количества потоков, то здесь должен сыграть неплохо MIC (Xeon Phi). Если не в текущей своей инкарнации, то в будущих уж точно. Потому что там как раз идея большого количества относительно слабых x86 ядер.
>>Но компилятор не знает в точности, как работает машина.
Не обобщайте. Во многих случаях оптимизация и компиляция происходит под конкретную микро-архитектуру. Либо семейство архитектур. И никакого «шаманства» не происходит.

>>процессор Itanium, использующий архитектуру VLIW
Странно видеть такое в блоге Интел.
EPIC это не VLIW. Хотя идея похожа.
Основное различие в том, что классический VLIW имеет фиксированную длину инструкции и поток инструкций статически переупорядочен в зависимости от конкретной микроархитектуры чипа.
От того VLIW чипы невозможно менять без потери совместимости.
А вот EPIC имеет гибкий формат команд, который позволяет сохранить совместимость и убрать зависимость от конкретной конфигурации вычислительных блоков и их количества.
Я бы не был так категоричен на счёт терминологии. Википедия, например, в статье про Итаниум утверждает следующее: EPIC implements a form of very long instruction word (VLIW) architecture, in which a single instruction word contains multiple instructions.

>>Основное различие в том, что классический VLIW имеет фиксированную длину инструкции и поток инструкций статически переупорядочен в зависимости от конкретной микроархитектуры чипа.

В Итаниуме всё именно так.

>>От того VLIW чипы невозможно менять без потери совместимости.

Без потери производительности, а не совместимости.

>>А вот EPIC имеет гибкий формат команд, который позволяет сохранить совместимость и убрать зависимость от конкретной конфигурации вычислительных блоков и их количества.

Это вы откуда взяли? Вообще какая-то очень абстрактная формулировка, к которой можно притянуть совсем уж разные вещи.
>>В Итаниуме всё именно так.
Не так.
Каждый слот во VLIW инструкции связан с конкретным функциональным блоком.
В итаниуме бандл не имеет таких ограничений.
У бандла есть темплейт, который определяет состав бандла и зависимости.
Бандлы обьединяются в группы, которые могут быть исполнены параллельно.
Если железо позволяет, оно запустит несколько бандлов.
Программа оптимизированная под более «широкий» чип будет работать и на более «узком», только разумеется медленнее.

>>Без потери производительности, а не совместимости
Именно совместимости. Необходима перекомпиляция под каждое поколение. Особенно если нет аппаратных блокировок конвеера (при различных зависимостях). Как например в TMS320C6000 AFAIR
В EPIC же ожидается наличие аппаратных interlock-ов.

>>Это вы откуда взяли?
Когда-то просматривал ISA
Вы почему-то полагаете, что VLIW подразумевает явное соответствие слота с исполняющим устройством. Это не так, VLIW всего лишь требует того, чтобы ISA содержала явный параллелизм (ILP), который выражался средствами этого самого длинного слова.

Но, насколько я знаю, тут чётко устоявшейся терминологии нет и разные производители могут приписывать разные свойства одному и тому же термину. Когда речь о каких-то специализированных процессорах, то, конечно, там нет совместимости — ибо никому не нужно попусту тратить лишние транзистры на то, что может сделать софт. Когда речь о более general purpose чипах, то совместимость есть. К VLIWу в моём понимании это отношения никакого не имеет.
>>Вы почему-то полагаете, что VLIW подразумевает явное соответствие слота с исполняющим устройством.
Почитайте что ли пейперы.
Классический/Идеальный VLIW он такой, и никаких interlock-ов и контроля зависимостей! Scoreboard — лишнее железо, которое для VLIW пожирнее будет чем для обычных CPU.

>>Когда речь о более general purpose чипах, то совместимость есть
Давайте на конкретных примерах.
В том понимании VLIWа, к которому я привык (и которое согласуется в Вики), свойство прямого соответствия слота с исполняющим устройством — это не часть определения VLIWа, а именно свойство различных реализаций.

В Итаниуме, кстати, это тоже в какой-то форме есть — бандл имеет поле, которое описывает тип каждой инструкции в бандле (т.е. не конкретное физическое устройство, а только его тип). Например:

{ .mii // < — тип инструкций: memory unit, integer unit, integer unit
ld4 r18=[r32]
mov gp=r36
mov r38=r37
}

Т.е. соответствие прописано не жёстко в ISA в виде номер слота — юнит, а закодировано в бандле.

>>Когда речь о более general purpose чипах, то совместимость есть
>Давайте на конкретных примерах.
Да как-то с большим зоопарком general purpose VLIWов иметь дело не приходится, не взлетели. Вроде это только Итаниум и Эльбрус2К.

И опять же EPIC — это VLIW, но с блекджеком и пианистками, а не что-то отдельное. Поэтому говорить что Итан — это VLIW корректно, хотя EPIC точнее.
>>и которое согласуется в Вики
Советую поискать другие источники, например всякие академические пейперы и лекции по теории процессоров.
google: VLIW [vs.] EPIC

>>бандл имеет поле, которое описывает тип каждой инструкции в бандле

про темплейт я написал в посте выше

>>general purpose VLIWов иметь дело не приходится, не взлетели
Именно так, по причинам которые я описал

примеры навскидку:
TI C6000, Trimedia: DSP
MAJC, Crusoe, Effecion: только бинарная трансляция

Бабаяновский Эльбрус: бинарная трансляция + нативный код
насколько совместимы программы под разные Эльбрусы я не в курсе,
т.к. не читал ни одного вменяемого описания архитектуры

С6000/MAJC/Crusoe не имеют scoreboard. Рассчитаны на конкретную конфигурацию фукциональных блоков (количество / тип), хотя фиксированное распределение слотов только в crusoe.
При изменении даже латентности исполнительных блоков всё сразу ломается. Какая тут совместимость?

www.cs.ucf.edu/~lboloni/Teaching/EEL5708_2004/slides/paper_aklaiber_19jan00.pdf
All atoms within a molecule are executed in parallel, and the molecule format directly determines how atoms get routed to functional units;
FADD | ADD | LD | BRCC

archive.arstechnica.com/cpu/4q99/majc/majc-3.html

All MAJC processor units will be 4-wide, with four execution slots per cycle. IA-64, on the other hand, allows an arbitrary number of functional units in an implementation

Since the MAJC compiler has to know all the instruction latencies before it can schedule, this means that the compiler, and hence the binary it produces, will be tied to a specific MAJC implementation. So a binary compiled on one MAJC implementation wouldn't run on another, because the instruction latencies might differ.

www.ti.com/lit/ug/sprufe8b/sprufe8b.pdf
в TI VLIW Fetch Packet достаточно гибкий и может кодировать несколько последовательных инструкций (вместо того чтобы забивать оставшиеся слоты нопами)

On the CPU, the execute packet can cross fetch packet boundaries, but will be limited to no more than eight instructions in a fetch packet.
The last instruction in an execute packet will be marked with its p-bit
cleared to zero. There are three types of p-bit patterns for fetch packets. These three p-bit patterns result
in the following execution sequences for the eight instructions:
• Fully serial
• Fully parallel
• Partially serial

Но опять же фиксированная латентность и
«All instructions executing in parallel constitute an execute packet. An execute packet can contain up to eight instructions. Each instruction in an execute packet must use a different functional unit» убивает совместимость на корню. Невозможно на старом чипе запускать новые программы оптимизированные на более (новый) «широкий» чип, либо старые программы на (новом) чипе с большими латентностями исполнительных блоков (например, рассчитанных на бОльшую частоту)
То, что во многих реализация VLIWа это так — я не спорю, я лишь говорю, что это не является частью определения VLIWа как такового.

В простых реализациях это оправдано. Crusoe/Effecion — там закрытая ISA, поэтому смысла в совместимости просто нет.

Более того, есть разные определения понятия VLIW. В широком смысле называть Итаниум VLIWом корректно. Хотя некоторые товарищи из академических кругов могут давать более строгие определения.

Пусть это останется лишь моим скромным мнением, чтобы не развивать холивар :)
>>В простых реализациях это оправдано
Дык весь замысел VLIW в том, чтобы поднять IPC дешевыми методами.
И ядро Power7 и TMS320C64x запускают 8 команд за такт.
Только вот какой ценой?

>>чтобы не развивать холивар
Собственно никакого холивара и нет =)

>>Дык весь замысел VLIW в том, чтобы поднять IPC дешевыми методами.
Не совсем. Он *позволяет* поднять IPC дешёвыми методами. В Итаниуме как раз задача была иная — достигнуть максимальной производительности не жалея сил и средств. Но опыт показал, что явный параллелизм не так хорош для general purpose в силу ограниченных возможностей компиляторов по выявлению параллелизма. Да и в силу того, что этот параллелизм зачастую носит «слишком динамический характер». И тут уж Out of Order наносит ответный удар.

А для многих узкоспециализированных (и особенно простых архитектур), VLIW — это то что доктор прописал. Экономит энергию, транзисторы и даёт скорость.
>>В Итаниуме как раз задача была иная — достигнуть максимальной производительности не жалея сил и средств

Дык Itanium это EPIC а не VLIW =)
Невозможно на старом чипе запускать новые программы оптимизированные на более (новый) «широкий» чип, либо старые программы на (новом) чипе с большими латентностями исполнительных блоков (например, рассчитанных на бОльшую частоту)


Ну, на уровне C62/C64/C64+ у них нет более широких или узких чипов — всегда ровно 8 устройств. Но, конечно, программа с 64+ не пойдет на 62 — так же, как 80286 не пойдет на 8086. Расширяются они теперь через многоядерность (у C66 может быть до 8 ядер), и там, теоретически, можно писать программы, знающие размер процессора.
Про латентность — это как? Сделать процессор, у которого конвеер работает на 2 ГГц, а умножение ускорить не удалось, и оно вместо 4 тактов занимает 7? Да, это либо поломает программы, либо придется на время выполнения команд умножения вводить «stall cycles» (искусственно понижать частоту). Ну, к этому им не привыкать.
>>Ну, на уровне C62/C64/C64+ у них нет более широких или узких чипов
Да. C64 это по-идее тот же C62 но с FPU.
А вот у itanium разное железо поддерживает различное количество одновременно исполняемых бандлов.
Хотя у C6000 довольно гибкая система команд и даже имеются маркеры конца параллельно исполняемого «слова» внутри одного fetch packet.

>>80286 не пойдет на 8086
Можно использовать совместимый код, но оптимизмрованный под более современные CPU.
Это как при компиляции прог под винду. Если не использовать CMOV/SSEx, проги будут работать и на первом пентиуме
но оптимизировать их следует под совеменные 4111/4444 декодеры.

>>а умножение ускорить не удалось, и оно вместо 4 тактов занимает 7

Именно так.

>>либо придется на время выполнения команд умножения вводить «stall cycles»

А это уже много лишнего железа, scoreboard для 8 параллельных операций.
FCU не у C64, а у C67. C64 — это более продвинутая целочисленная арифметика и более высокая тактовая частота. А С64+ — вообще шаг в непонятную сторону (с 16-битными командами и загадочными возможностями организации коротких циклов). Зато у С64+ есть умножение 32*32

> А это уже много лишнего железа, scoreboard для 8 параллельных операций.
Скорее всего, все механизмы уже существуют и реализованы. Есть несколько ситуаций, когда им приходится незаметно притормаживать процессор, так что если еще некоторые будут вызваны неторопливым мультипликатором, то они и это реализуют. Но я сомневаюсь, что оно им понадобится. Хотя кто знает.
В С6000 совместимость на уровне кодов (односторонняя) поддерживается: код, написанный на С62, будет идти и на С64, и на С64+, и на С67. Никакой перекомпиляции не требуется (разве что из-за изменившихся адресов чего-нибудь в новом железе). Насчет С66 не знаю, еще не изучал. Аппаратные блокировки конвеера (если я правильно понимаю, что имеется в виду) тоже есть. Например, при обращении к памяти, которая не лежит в L1 кеше: весь процессор останавливается и ждет, пока нужный блок будет прочитан. Изредка возникают блокировки на 1 такт и без обращений к памяти, и программы этого не замечают — для них этого такта просто нет.
>>Например, при обращении к памяти, которая не лежит в L1 кеше: весь процессор останавливается и ждет
Это не та блокировка. Тут не отслеживаются зависимости инструкций по причине отсутствия железа для этого.
Весь execution packet тормозится в случае кеш-промаха. Для программы не существует этих тактов задержки.
Современные in-order процессоры поддерживают неблокирующие LD, когда программа выполняется дальше и в случае кеш-промаха.

>>Изредка возникают блокировки на 1 такт и без обращений к памяти, и программы этого не замечают — для них этого такта просто нет.
А в каких ситуациях это происходит?
> А в каких ситуациях это происходит?

Например, если инструкция пытается взять регистр из «чужого» банка (cross-path), а этот регистр был модифицирован только что выполненной командой (кроме случая, когда он — результат LD*):

ADD .L1 A2,A3,A2
ADD .L1X B3,A2,B3

Вторая команда (и все параллельные с ней) начнет выполняться с задержкой на 1 такт.

В С64+ пакеты параллельных команд могут пересекать границы fetch-пакетов. При прыжке на такой пакет перед его исполнением произойдет задержка на 1 такт.

Некоторые ситуации работы с управляющими регистрами.

Ну, и кеш-промах — как для программы, так и для данных. Возможности запросить загрузку памяти в L1 без остановки процессора (чтобы использовать потом) я пока не нашел.
(во второй команде опечатка — ADD .L2X B3,A2,B3)
А что там насчет квантовых компьютеров? Интел это направление не развивает?
По поводу компиляторов, поделюсь гордостью за соотечественников. В Институте системного программирования РАН после выхода Itanium оптимизировали GCC под него. В т.ч. оптимизировали планировщик команд, который по сути ключ к оптимальному использованию 6-ти команд за такт. Так вот умные люди подшаманили его так, что прирост производительности на тестах был в разы (!). Дипломы защищались, диссертации. В общем, Win был у института)
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий