Строение кристалла микропроцессора Эльбрус 8св

Non> кстати в чём прикол давать сервера
Non> кому это выгодно?)
Igor Molchanov> ну, технически это одна из мер популяризации эльбруса и увеличения количества людей, знакомых с архитектурой
Igor Molchanov> плохо, что это всё делается тупо на энтузиазме, а не силами МЦСТ/ИНЭУМ

https://t.me/elbrus_gensokyo/26124

Строение кристалла микропроцессора Эльбрус 8св

предоставляется удаленный доступ к рабочей станции

Это делается не по велению руководства МЦСТ/ИНЭУМ, а вопреки им на чистом энтузиазме сотрудника/сотрудников.

Руководству на всё наплевать с высокой колокольни.

32 полезных Rust крейта, о которых вы могли не знать

byteorder не упомянули потому что о нём все и так знают?

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Я с ваами сам отупел уже

Мне кажется, что мы тут не при чём.

Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, ...

Нет, вы опять несёте какую-то пургу.

Я бы не хотел ссылаться на авторитетность, но я один из тех кто написал эмулятор для e2k и имею определённое представление о том как он работает.

Давайте вы прекратите распространять нелепицу и вводить в заблуждение тех, кто не согласен с автором?

Можете не утруждать себя ответом, т.к. я на него не отвечу.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Премного уважаемый, не могли бы прекратить нести полную околесицу?

подготовка перехода происходит ДО входа в цикл

После вызова процедуры значения в регистрах подготовленных переходов нельзя использовать, т.к. будет выброшено исключение. В этой ситуации необходимо будет делать подготовку на начало цикла в самом цикле (+5 тактов), после вызова другой процедуры.

А вызовы он не может делать только в конвейризованных циклах (loop mode) - это специальный аппаратный режим необходимый прежде всего что бы вращаемые регистры по базе автоматически сдвигалить, ну и плюс там счетчики автоинкриментировались и прочее.

В таком цикле можно сделать вызов, но надо будет самостоятельно сохранить/восстановить всё нужное состояние не переживающее вызовы.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Это всё из разряда: "Если бы у бабушки были...".

Я не хочу быть адвокатом ни для Intel, ни для МЦСТ, и топлю за объективную оценку ситуации. Но позволю обратить внимание на то, что у всех архитектур разные стартовые позиции, что может сильно сказаться на их успешности. Микроахитектура спокойно может быть OoOE, даже для того же IA-64. То есть вопрос не столько в том, что это RISC/CISC/VLIW/etc, а в самом дизайне ISA и насколько он удачен. Но не достаточно просто быть лучше. Рынок обчыно инертен и не любит сильных потрясений. Лучше всего когда появляется новая ниша и её удаётся быстро занять, но это происходит не часто. Itanium свою нишу не нашёл, а и IA-64 была не такой уж хорошей. Это камень в огород плотности кода у этой архитектуры.

Не надо делать поспешных выводов и экстраполировать опыт Х на все Y.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Но потом вы сделали ошибку упомянув Itanium в статье. ;)

Все эти архитектурные споры вечны. Как говорит один умный человек: "It depends". Ну а через какое-то время потомкам приходится жить с тем, что было важно тогда в прошлом, вне зависимости о какой бы архитектуре мы сейчас не говорили. :)

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

1. Многопоточность — это в первую очередь T*S, где T кол-во потоков и S размер архитектурного состояния. Когда у вас 16/32 GPR/VFPR это может и не проблема, но вот когда 128/128 в IA-64 или 256 в e2k (и это ещё не всё архитектурное состояние), то дело уже не настолько просто. Опять таки больше транзисторов, но в статье вы этот аспект Itanium'a не упоминаете в контексте простого VLIW процессора, а он не такой уж и простой.

2. Тактовая частота — это комплексная проблема поиска оптимального соотношения производительности, энергопотребления, стоимости разработки и тд. Я думаю не надо напоминать какие затраты идут на R&D в Intel и МЦСТ. Да и Itanium на этот момент фактически уже был похоронен. Упомянутый в статье 9760 из 2017 года, это освежённый Poulson из далёкого уже 2012 года. Мне очень сложно представить Э8С с тактовой частотой около 3ГГц, не только потому, что он на ней банально не заработает, а потому что он переплюнет всех остальных по энергопотреблению. Это к вопросу об энергоэффективности. Что-то мне подсказывает, что оба этих производителя не делали на этом слишком большой акцент в этих микроархитектурах.

3. Предсказатель ветвлений из упомянутой статьи разрабатывался для сокращения энергопотребления в мобильном Э1С+. Процессоры из статьи явно не из этой категории.

4. Смотря какая политика в планировании используется. Если планировать для ситуаций когда ядро всегда получает данные из L1d, то это имеет смысл. Насколько мне известно по умолчанию (без PGO) в lcc именно такая политика для неспекулятивных обращений.

5. FMA ­— это обычно комплексная комбинаторная логика, что означает больше транзисторов. В приведённом Э8С это ещё не реализованно, а Э16С ещё даже нет в серийном производстве. В Poulson это 2 FMAC на ядро, а в Э16С будет 6 векторных FMAC на ядро.

6. Я вам скажу больше, вы путаете такие понятия как VLIW и ISA заточенная под статическое планирование (не обязательно VLIW). IA-64 (изначально) и e2k заточены под статическое планирование. Но VLIW в IA-64 используется потому, что размер инструкции ~43 бита. Согласитесь, 43 бита не умещаются в 32, а в 64 будет слишком много неиспользованных. Если же абстрагироваться от кодирования, то сама идея EPIC очень плохо ложится не только на статическое, но и на динамическое планирование, это что-то среднее. Банально в OoOE не нужны стоп биты, то есть в Poulson эта информация рудимент прошлого (хотя и может упрощать переименование регистров), а для статического планирования это не подходит при изменении конфигурации микроархитектуры. E2k в этом плане более последователен, но со своими крайностями. Если же вернутся к OoOE в Itanium, то это не про dataflow как обычно принято, а про перемещение инструкций в конец очереди если её операнды не готовы в момент запуска. Грубо говоря, пока процессор ждёт 200 тактов данных из памяти, он всё это время "теребонькает" очереди. Опять таки, это лишнее энергопотребление, не говоря уже про необходимость переименования регистров. Опять таки, нужно больше золота транзисторов.

Если же подвести итоги, то на этом фоне микроархитектуры Эльбрусов выглядят очень очень плохо. Например в 9760 32 Мб L3, а в Э8С всего 16 Мб. Хотя то что физдизайн у Эльбрусов оставляет желать лучшего отнюдь не новость. Делать из этого далекоидущие выводы как минимум глупо на мой взгляд. Лучше было бы сравнивать Itanium'у с x86 тех годов, но опять таки с учётом специфичности IA-64.

Но в одном я с вами полностью согласен, что e2k слишком переусложнён, что и тянет его на дно из-за невозможности адекватно реализовать всё в аппаратуре.

На мой взгляд, наиболее разумное применение VLIW для in-order CPU в Denver от Nvidia. Скажем так, это современных взгляд на in-order VLIW без классических недостатков и развитие идей заложенных в Crusoe от Transmeta.

Надеюсь мой пост не получился слишком перегруженным.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Часть я уже упомянул выше, но повторюсь для полноты картины.

• Многопоточность.

• Тактовая частота.

• Предсказатель ветвлений.

• Аппаратный префетчер.

• Наличие FMA.

• Ну и вишенка на торте, своеобразное OoOE.

В Эльбрусах что-то отсутствует или сделано иначе (в основном в сторону статического/программного решения), а это сказывается на транзисторном бюджете и TDP. И это не говоря уже о технических возможностях реализовать это в аппаратуре.

Определённо e2k и IA-64 имеют много общего, но в то же время они очень разные. Что-то из этого списка можно реализовать в e2k, что-то уже реализовано, а реализация чего-то ещё превратит в рудимент добрую часть ISA. :)

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Но на общие выводы это не влияет.

На мой взгляд влияет. IA-64 как-то можно сравнивать с e2k только до появления Poulson, но только если код собирается с -march=nativeдля IA-64. Как минимум не стоило подгребать их под одну гребёнку в сравнении с OoOE x86.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

LLVM ничего не знает про e2k. В LLVM просто трансляция из LLVM IR в EIR, а дальше работает lccrt.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Было бы неплохо поправить немного таблицу с процессорами. У Itanium​ 9760 всего 8/16 ядер/потоков, предсказатель ветвления и своеобразное OoOE. Он довольно сильно отличается от Эльбрусов.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Там используется бекенд компилятора lcc (того самого, что компилирует C/C++), так что в идеале должен получится такой же эффективный код, но на данный момент это не совсем так. Как я уже написал выше, есть что улучшать.

Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU

Аналогичная ситуация с компилирующими языками типа rust и go — никто не будет создавать для этих языков оптимизирующий компилятор для всей линейки микропроцессоров Эльбрус.

Rust уже есть на e2k. Хотя ещё есть что улучшать.

https://ce.mentality.rip/z/KTWsvd

Архитектура процессора Эльбрус: стоит ли все это своих денег?

Например: есть 32 логических предиката (то есть, переменных, содержащих true или false). Чтобы закодировать их, нужно 5 бит. Но зачем нам нужно одновременно 32 булевых переменных? Когда такое понадобится?

Много предикатов может потребоваться в программно конвейеризированном цикле с условным исполнением длинной цепочки зависимостей. Тем более, предикаты не занимают место в ШК, пока они действительно не понадобятся. Кодирование позволяет указать 2 предиката для каждого кластера (ALC 0-2 и ALC 3-5) с возможной инверсией в 1 слоге предикатов (32-бита). Всего может быть до 3 таких слогов, что даёт возможность указать для каждого ALC свой предикат.

Или константы, которые всегда занимают 32 бита. А если мне нужна константа 1? 31 бит уйдет зазря? А если 64-битная константа?

Константы, не занимают место в ШК пока они не понадобятся. В общем случае инструкция имеет такой вид:

mnemonic src1, src2, src3, dst

Где:
src1 — регистр, u5.
src2 — регистр, u4, i16, i32, u64.
src3 — регистр.
dst — регистр.

Только в src2 может быть константа из слогов с литералами. Если литералы не использовать, то инструкция занимает 32-бита или 48-бит, в зависимости от полуслога расширения.

Архитектура процессора Эльбрус: стоит ли все это своих денег?

Подготовленные переходы требуют 4 конвейеров (1 текущий и 3 дополнительных) для начальных ±5 стадий конвейера. Учитывая размер и сложность кодирования ШК в e2k, это вполне возможно.

Небольшая история о команде `yes` в Unix

Хватило бы такого варианта, не понимаю, зачем они всё так усложнили.

use std::borrow::Cow;
use std::io::{self, Write};

fn main() {
    const BUFFER_CAPACITY: usize = 32 * 1024;

    let expletive = std::env::args().nth(1)
        .map(|s| Cow::Owned(s + "\n"))
        .unwrap_or(Cow::Borrowed("y\n"));

    let buffer = expletive.repeat(BUFFER_CAPACITY / expletive.len());
    let stdout = io::stdout();
    let mut handle = stdout.lock();

    loop {
        handle.write(buffer.as_bytes()).unwrap();
    }
}

К тому же, этот вариант, на моей машине, быстрее на 7% быстрее.