Представлен МП21 — одноплатный компьютер на базе процессора «Эльбрус-2С3»

Эльбрус-3 был не на кремнии и Cray был не на кремнии. То, что в итоге быстро переключились на кремний очень и очень хорошо. Это реально хороший опыт и развитие отечественных компетенций.

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

Условные инструкции конвейер не сбрасывают.

В случае VLIW и подготовленные переходы конвейер не сбрасывают. Но сам переход достаточно дорогой в тактах.

И чё? Ограничение даёт железнодорожный габарит.

Расскажете как первая ступень Н1 влезла на ЖД?

Во-первых, не всегда и не так.

На момент разработки Р7 это было так.

Во-вторых, ну увязали четыре камеры в один блок, как это повлияло на облик ракеты? Да никак.

4х камерник вообще то радикально ниже 1но камерника с той же тягой, и это была просьба конструкторов уменьшить верт габарит двигателя, дальше с DDT просто звезды сошлись. Вам не стыдно демонстрировать полное незнание азов истории разработки самого знаменитого РН СССР? И это мы ещё про связь особенностей компоновки и конструкции старта не говорили…

мне как конструктору, абсолютно фиолетово, как устроен двигатель

Если в Ваши обязанности входят только заточка карандашей и заваривание чая то да.

делали и большей тяги и большего размера

Но не на момент проектирования Р7! Тут Вы уже традиционно демонстрируете полное незнание матчасти, неумение следить за ходом дискуссии и вообще неумение логически мыслить, поскольку путаете причинно-следственные связи. Хотя о чем я, все время забываю что Вы циклограмму не асилили:-(

Привет Вам из родных пенатов - корпуса РКК Энергия видны из окна моей кухни, бггг.

Для начала я бы тебе посоветовал не использовать слово «совок».

По существу не хочешь обсудить проблему?

Но ты можешь подумать почему.

Потому что многие бывшие граждане СССР включили режим отрицания и отказываются рефлексировать. Поэтому любое упоминание объективных проблем совка у них вызывает приступ острой боли пониже спины.

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

От человека вроде Вас, не знающего азов космонавтики, про устаревшие наработки по бурану слышать очень забавно. Вы тут позориться ещё не устали?

Что будем делать с твоими кулсторями про аварийность Сатурна, знаток?

Но было принято решение именно по логике liksys: «это совместимый с остальными процессорами камень, поддержка которого обеспечивается не только твоими, но и мировыми усилиями».

Разница в том, что копировали машины целиком и перестали вкладываться в НИОКР. Я предлагаб вообще другое: взять архитектуру, а микроархитектуру разработать свою. Получится НИОКР с совместимостью.

Во вливе вам не нужны переходы и подготовки к ним.

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

Вы все равно считаете обе ветки разом, просто в конце один результат выбрасываете.

Вот для выброса результата и приходится делать условный переход, если нет предикатной операции.

Вкину-ка еще немного занятных ссылок о том, как действительно обстоят дела с перспективами эльбрусов:

• Здесь бывший сотрудник МЦСТ поясняет за проблемы текущего подхода
• Он же - анализирует то, как надо делать - сюрприз, сходится со мной во мнении про RISC-V.
• Здесь разбирается код и ассемблеры с примерами, и поясняется, почему VLIW общего назначения - это с 99% вероятностью тупик. Пример интересный, потому что показывает, что статический анализ кода не в состоянии помочь компилятору оптимизировать даже простейшую сортировку, В комментариях разбирают, как надо специальным образом оптимизировать сишный код, чтобы генерировалось что-то компактное. Буквально закат солнца вручную.
• Разгромное мнение Линуса Торвальдса по поводу VLIW вообще и Itanium в частности.
• А Дональд Кнут говорит о том, что подходящий компилятор для VLIW общего назначения вообще невозможно написать
• Джон Хеннесси и Дэвид Паттерсон тоже пишут, что удел VLIW - это специализированные процессоры, вроде DSP
• И закончить эту замечательную подборку я хочу выдержкой из интервью самого Бабаяна - дедушка тоже считает, что VLIW был ошибкой :)

Мы думали: ну, сделать 32 цуга – и будет у нас настоящий параллелизм! Но я допустил тогда ошибку. Я подумал, что это очень сложно, а ведь есть подход попроще – подход широкой команды. Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…

Собственно, на этом в спорах о перспективности VLIW общего назначения можно ставить точку.

Влив очень хорош, когда не на кремнии, он и начинался в эпоху шкафов. Это не было ошибкой, это было разумным этапом

Влив очень хорош, когда не на кремнии, он и начинался в эпоху шкафов. Это не было ошибкой, это было разумным этапом

Шкафы - это и не общее назначение. Бабаян говорит об ошибке, сразу сравнивая подход с итаниумом, то есть речь шла именно о кремниевом чипе.

Спасибо за ссылку, интересно будет почитать.

История это история. Сослагательное наклонение и всё такое. Это я к тому, что проблем могло быть больше в самых неожиданных местах. А на текущий момент, на мой взгляд, вообще выч. техника обладает совершенно избыточной мощностью. Этакое торжество стимпанка при остром недостатке живительного электричества в организме^W индустрии.

Какую проблему?

Мне трудно говорить за всю ВТ, я могу говорить только за ВТ в контексте численного моделирования. Тут да, подсистема памяти отстаёт от процессоров.

Мне кажется все (как обычно) идёт по пути наименьшего сопротивления - оказалось что повышать производительность железа проще чем писать хороший код, ну и мы оказались там где оказались…

Здесь бывший сотрудник МЦСТ поясняет за проблемы текущего подхода

Он вообще странный. Заявляет, что Эльбрус-8СВ медленнее, чем Эльбрус-R2000 несмотря на реальность.

как действительно обстоят дела

Это не как обстоят, а что думают люди по поводу того, как обстоят дела.

А Дональд Кнут говорит о том, что подходящий компилятор для VLIW общего назначения вообще невозможно написать

Приведи пожалуйста, цитату. Не могу найти по ссылке такого утверждения. Там только про то, что Intel не смогла написать достаточно хороший компилятор.

Ведь мы тогда минусов не знали этой широкой команды…

Так у него единственный заявленный минус:

Мы поработали с этим и поняли, что это тоже не блестяще, потому что используется статическое планирование.

Разгромное мнение Линуса Торвальдса по поводу VLIW вообще и Itanium в частности.

У него два безосновательных утверждения:

The whole damn architecture was entirely based off the basic incorrect premise that OoO is expensive.

because even a small instruction scheduling window would have done a better job than what you can do statically (because of dynamic behavior wrt any control flow what-so-ever, even unconditional branches like function calls).

Чем не общее? Самое что ни на есть, когда другого и нет.

Интел вообще пророчил, что 64 разряда станут итаником, если бы амд не подсуетилось, так бы оно и было. Опплевались бы на влив раньше, раньше пересели бы на арм.

Заявляет, что Эльбрус-8СВ медленнее, чем Эльбрус-R2000

Процитируй.

Это не как обстоят, а что думают люди по поводу того, как обстоят дела.

Факты перечислены, выводы сделаны. Особенно занятно про закат солнца вручную.

Приведи пожалуйста, цитату.

I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the «Itanium» approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.

Мы поработали с этим и поняли, что это тоже не блестяще, потому что используется статическое планирование.

Это буквально краеугольный камень VLIW.

У него два безосновательных утверждения:

Ну разумеется, безосновательных. Ведь опыт существующих VLIW нас ничему не научил. Он констатирует факты, основанные на опыте. Можешь пойти поспорить с ним, если хочется.

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

Чем не общее? Самое что ни на есть, когда другого и нет.

Ну, если на безрыбье… Так или иначе, Бабаян сравнивал там кремний с кремнием, и именно в этом контексте признал ошибочность подхода.

Опплевались бы на влив раньше, раньше пересели бы на арм.

Вряд ли. Я думаю, оно бы само умерло естественным путем, потому что коммерсы не съели бы тормоза и дороговизну адаптации софта под итаниум даже взамен на 64 бита.

ARM взлетел, потому что там сделали заход не с десктопов и серверов, а с мобильников, где CISC не прижился из-за прожорливости. Обкатали архитектуру там, а потом оказалось, что ее можно отмасштабировать и на большие машины.

Процитируй

Вот:

Как видно, VLIW-процессоры на тех же нанометрах, имеют меньшие тактовые частоты, при этом имеют более высокое тепловыделение и больше транзисторов.

В итоге VLIW процессоры проигрывают не только по микроархитектурной скорости в пересчёте на Герцы, но и по самим частотам.

В таблице R2000 на 2ГГц и 8СВ на 1,5ГГц. При этом скорость на ядро у 8СВ вдвое выше.

Это буквально краеугольный камень VLIW.

Это так. Но у МЦСТ достаточно хороший компилятор Си удалось написать. Поэтому не «невозможно», а «Intel не смог» (скорее всего, денег на побочный проект зажал).

Опплевались и умерло бы, только гораздо громче и в масштабе всего мира.

Так или иначе, Бабаян…

Старый человек, у которого несмотря на все свои недостатки, все дома. Он же у нас в ответе за всё, как пионер. Если бы он сказал, что тогда подход был правильным, его бы сейчас со всеми специями съели. Вот и возводит на себя напраслину. Ошибкой был не влив, а то, что его вовремя не закопали. Только альтернативы долго не было. Спарк тоже проблемный по производительности, где-то читал об этом, но не воспроизведу. Риск5 возник только сейчас, своих аналогов не сделали.

Объективно максимум что могли - начинать сползать на риск три года назад. Нормально уходить сейчас, а будет так - лет через десять разведут руки и скажут, что со вливом мы опять обосрамс, но что мы могли поделать, это Бабаян виноват

В случае VLIW и подготовленные переходы конвейер не сбрасывают. Но сам переход достаточно дорогой в тактах.

Я понимаю, но, в данном контексте, это не аргумент, так как frost_ii уже сказал, что предподготовка одновременно нескольких веток перехода, нагружает шину памяти ещё сильнее. В случае же с условными инструкциями, такой проблемы нет.

Вообще, я думаю, если высокую латентность памяти ещё можно победить, например, тем же vectorized instruction pointer, то вот узкую шину, без увеличения кешей, в текущих реалиях непонятно как побеждать (всякие там HBM и пр - это да, но это не сегодняшний день). Соответственно, можно попробовать свести вопрос к тому, что лучше: потратить место на кристалле на аппаратные планировщики, или потратить его же на доп кеши…

В таблице R2000 на 2ГГц и 8СВ на 1,5ГГц. При этом скорость на ядро у 8СВ вдвое выше.

При этом проц целиком жрет в три раза больше и у него всё хуже с параллелизмом, чем у R2000. Наглядно видно, что подход «сделаем больше дешевых RISC-ядер» работает лучше.

Но у МЦСТ достаточно хороший компилятор Си удалось написать. Поэтому не «невозможно», а «Intel не смог» (скорее всего, денег на побочный проект зажал).

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

Очевидно, что если специально городить миллионы костылей не все случаи, то что-то будет работать. Но это, опять же, процесс вечный.

При этом проц целиком жрет в три раза больше

Так мы скоростью или ваттами меряемся. Лучшие чипы это АРМ и Атом?

и у него всё хуже с параллелизмом, чем у R2000

С чего это? На 8 потоках всё то же опережение на распаковке больше чем в два раза при меньшей тактовой частоте.

Вот и возводит на себя напраслину.

Дедушка умеет признавать ошибки :)

Ошибкой был не влив, а то, что его вовремя не закопали.

Вот да.

Только альтернативы долго не было.

Верно, но RISC-V появился еще в 2010. Даже если взять какой-то временной гэп, то МЦСТ продолжал долбиться лбом в стену почти десять лет.

Спарк тоже проблемный по производительности, где-то читал об этом, но не воспроизведу.

Зато я воспроизведу, пушто люблю спарки, у меня дома даже вот такая штука стоит для души. Если кратко, то у них низкая производительность на одно ядро, как в принципе и у многих RISC. А софт в те времена писался в основном однопоточный, и средства параллелизма были не особенно развиты. В итоге их воспринимали как тормозные печки. В современном мире софт пишется иначе: все что можно бьется на потоки, поэтому слабость отдельного RISC-ядра уже не является такой большой проблемой. Пример выше про сравние эльбрусов R2000 и 8СВ наглядно это демонстрирует.

Если бы Sun смог пережить период нулевых, то скорее всего сейчас у нас были бы ноутбуки на спарках. В истории они тоже появлялись, но редко, сейчас восстанавливаю один такой.

Так мы скоростью или ваттами меряемся. Лучшие чипы это АРМ и Атом?

В конечном итоге имеет смысл именно соотношение производительности к потребляемой мощности. Потому что кабель, который приходит в датацентр, может прокачать ограниченное количество ампер. И когда коммерс на те же амперы сможешь получить условные x2 производительности только за счет выбора архитектуры - он выберет ту, которая дает эти x2.

В третьей ссылке это подробно разбирается с пруфами на примере самой обычной сортировки, где компилятор не осилил оптимизировать код.

Вот на актуальной версии:

.L278:

        {
          subs,0,sm     %r9, 0x1, %g16
          stw,2 %dr0, %dr5, %r8 ? ~%pred0
          stw,5 %dr0, %dr2, %r10 ? ~%pred0
          pass  %pred0, @p0
          pass  %pred1, @p1
          landp ~@p0, ~@p1, @p4
          pass  @p4, %pred3
        }

        {
          ldw,0,sm      %dr0, %dr4, %g17
          pass  %pred2, @p0
          pass  %pred3, @p1
          movep @p1, @p0, @p4
          pass  @p4, %pred1
        }

        {
          cmplsb,0,sm   %g16, 0x0, %pred2 ? %pred3
          addd,1,sm     0x0, %dr7, %dr5 ? %pred3
          adds,2,sm     0x0, %g16, %r9 ? %pred3
          addd,3,sm     0x0, %dr4, %dr2 ? %pred3
          addd,4,sm     %dr6, 0x4, %dr7 ? %pred3
          addd,5,sm     0x0, %dr6, %dr4 ? %pred3
        }

        {
          adds,0        %r3, 0x1, %r3 ? ~%pred3
          subd,3,sm     %dr6, 0x4, %dr6 ? %pred3
        }

        {
          cmplesb,0,sm  %g17, %r10, %pred0 ? %pred3
          adds,1,sm     0x0, %g17, %r8 ? %pred3
        }

        {
          ct    %ctpr1 ? %pred3
        }

Уже 6 тактов. А не 13.

Дедушка умеет признавать ошибки :)

А я не считаю это ошибкой. Как говориться - если бы я был такой же умный, как моя жена потом.

Верно, но RISC-V появился еще в 2010.

Были и другие, но выстрелил он. И предвидеть подобное сложно и большие проекты так не работают. Начало в 20м было бы очень хорошим и не сказочным вариантом. Остаются надежды благодаря двум другим отечественным конторам с риском.

Если кратко, то у них низкая производительность на одно ядро

Там какая-то трабла с их фишкой, впрочем, я уже не помню в подробностях. Во времена Ниагары читал

Уже 6 тактов. А не 13.

Это уже не имеет значения. Важен сам подход.

Ты сам видишь, что компилятор требует вмешательства в каждом случае, даже в таком простом, как сортировка, которую они исправили после резонансной статьи на сотни каментов. А код может писаться человеком произвольно, так что число таких случаев будет бесконечным. Отсюда простой вывод: обучения компилятора оптимизировать, используя метод статического анализа, потребует бесконечного времени. Стоимость оценивать не берусь, не знаю, сколько людей работает над софтом в МЦСТ, но полагаю что много, учитывая свою экосистему. В первых двух статьях это разбиралось.

Имеет смысл отношение производительности на транзистор. Кристалл конечен, а электростанцию и построить можно

В конечном итоге имеет смысл именно соотношение производительности к потребляемой мощности. Потому что кабель, который приходит в датацентр, может прокачать ограниченное количество ампер.

Тогда бы вместо ксеонов на серверах стояли бы кластеры из Intel Atom.

Если у тебя задача не параллелится, то тебе неважно сколько ядер простаивают рядом.

А я не считаю это ошибкой.

Будешь спорить с Бабаяном, который сам уже поставил крест на VLIW? :)

Как говориться - если бы я был такой же умный, как моя жена потом.

Анализ в ретроспективе - это очень важно, чтобы не подолжать ходить по граблям.

Были и другие, но выстрелил он. И предвидеть подобное сложно и большие проекты так не работают.

Я не спорю с этим. Просто чем дольше педалируется неудачный подход - тем болезненнее будет с него потом слезать. Товарищ из МЦСТ по ссылкам буквально об этом и пишет - у них есть опыт и возможность развивать другую архитектуру и перераспределить свои ресурсы, но они этого не делают.

Там какая-то трабла с их фишкой, впрочем, я уже не помню в подробностях. Во времена Ниагары читал

Что-то микроархитектурное наверняка.

а электростанцию и построить можно

Я помню, как еще в начале десятых ДЦ-держатели выли в Москве от недостатка электропитания. Не забывай о стоимости всего этого предприятия, и о стоимости железа, а еще плотности упаковки в ДЦ. При сходной производительности может вполне получиться так, что датацентр на RISC будет в два раза меньше, чем на VLIW.

Тогда бы вместо ксеонов на серверах стояли бы кластеры из Intel Atom.

Ты уверен, что твой кластер из атомов будет кушать столько же, сколько ксеон, при схожей производительности? :)

Если у тебя задача не параллелится, то тебе неважно сколько ядер простаивают рядом.

Если задача не параллелится, то тебе нужен как можно более быстрый проц на один поток, а это точно не VLIW.

Зачем спорить? Он хитрый армянин, и я понимаю о чем и почему он говорит.

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

В спарках какая-то беда архитектурного плана. Микроархитектуру в мцст сделали свою, но не особо помогло. Кстати и код у них тоже очень жирный

Ты меня заинтриговал. Можешь попробовать найти историю?

Уже сейчас есть код, для которого статическая оптимизация лучше динамического OoO от интел.

#include <stdio.h>
#define REP 100000
#define N 10000 

void f0(int*p) 
{ 
  *p = (*p)* (*p) + 1; 
} 

void f1(int*p)
{ 
  *p = (*p)/ ((*p) * (*p) + 1); 
} 

void f2(int*p) 
{ 
  *p = (*p)<<((*p) & 31); 
} 

void f3(int*p) 
{ 
  *p = (*p)+ (*p)<<1 + (*p)<<7 +(*p)<<4; 
} 

void f4(int*p)
{ 
  *p = (*p)^ (int)( (*p) * 0.42); 
} 

void f5(int*p) 
{ 
  *p = (*p)% 17; 
} 

int r[N]; 

void sample(int i) 
{ 
  f0(&(r[i])); 
  f1(&(r[i+1])); 
  f2(&(r[i+2])); 
  f3(&(r[i+3])); 
  f4(&(r[i+4])); 
  f5(&(r[i+5])); 
} 

int main() 
{ 
  int i,k; 
  for (i=0; i<N;i++) 
    r[i]=i; 

  for (k=0; k<REP; k++) { 
    for (i=0; i<(N-5); i+=6) { 
      sample(i); 
    } 
  } 
  printf("%10i\n",r[0]);
  return (int)r[0];
}

А код может писаться человеком произвольно, так что число таких случаев будет бесконечным.

Но вариантов синтаксических конструкций не так уж и много.

Уже сейчас есть код, для которого статическая оптимизация лучше динамического OoO от интел.

Этого несложно добиться, если специально разрабатывать такой оптимизированный код с учетом знания особенностей компилятора и архитектуры, а потом еще подпилить под него компилятор. В то время как интеловский OoO хорошо работает в большинстве общих случаев и не требует особых выплясываний.

То есть это буквально подтверждает мои тезисы, и тезисы экс-МЦСТшника по ссылкам.

Сразу видно, вы не участвовали в циклопических проектах. Сделать можно всё, пока не пошатнуться физические принципы. На этом этапе подумать и сделать ещё чуть больше. Деньги это фигня. ДЦ частники

Анрыл. Лучше найти специалиста инженера, который занимается ядрами, благо такие есть и спросить его что не так со спарком.

Его забросили не просто так.

Сразу видно, вы не участвовали в циклопических проектах.

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

Деньги это фигня. ДЦ частники

Для частников как раз деньги - это главное.

Если наша стройка застит солнце, мы будем работать в тени

Главное, чтобы потом вот так не получилось. А то там тоже строили-строили, и достроились до того, что уже сами не знают, как из этого неуправляемого болота вылезти.

А десятый когда будет? Или уже был?

С каждой новой версией компилятора, доля кода, который эффективно компилируется без переписывания вообще, растёт.

Тот же PostgreSQL, который тестировали Сберовцы, был с изначальными исходниками. Работал достаточно эффективно.

С каждой новой версией компилятора, доля кода, который эффективно компилируется без переписывания вообще, растёт.

Как я и говорил, это бесконечный процесс. См. Кнута и остальных.

Как и для любого компилятора. Если так рассуждать, то писать надо на ассемблере.

Нет. Обычные компиляторы не занимаются настолько глубокими оптимизациями, потому что это делает процессор.

А вот еще одна занятная статья:

Спикеры от МЦСТ заявляли, что предсказатель ветвлений планируется к реализации в новых версиях Эльбруса, а аппаратный префетчер чуть ли не уже реализован (правда, никакого упоминания об этом в публичных спецификациях я не нашёл). Ну и не могу не отметить, что озвученные улучшения – это первый шаг к отходу от концепции статического планирования, сделанного «умным» компилятором.

Похоже, до ребят из МЦСТ дошло, что решать проблемы умным компилятором, который невозможно написать - так себе затея. А еще там крайне любопытно написано про динамическую трансляцию.