Системное программирование
0,0
рейтинг
19 декабря 2012 в 23:43

Разработка → Баллада о «Мультиклете»

Нет, я не раскрою вам загадку, скрывающуюся в названии MCp0411100101, но постараюсь развёрнуто ответить на комментарий nerudo, записанный в топике Процессоры «Мультиклет» стали доступнее:

Читая описание архитектурных новшевств этого мультиклета, мне хочется воспользоваться фразой из соседнего топика: «Я не понимаю».


Если кратко, то MCp — это потоковый (от dataflow) процессор с оригинальной EPIC-архитектурой. EPIC — это Explicitly Parallel Instruction Computing, вычисления с явным параллелизмом инструкций. Я применяю этот термин здесь именно в этом смысле, как аббревиатуру, а не как ссылку на архитектуру Itanium-ов. Явный параллелизм в MCp совсем другого рода.

О преимуществах MCp


Для затравки я скажу, что EPIC в MCp такой, что наделяет процессор рядом заманчивых (по крайней мере лично для меня) свойств.

  1. Хорошей энергоэффективностью. Которая обеспечивается тем, что MCp может:
    • согласовывать своё архитектурное состояние существенно реже, чем процессоры традицинных архитектур;
    • естественным образом совмещать в параллельном асинхронном исполнении инструкции работы с памятью, арифметические инструкции и предвыборку кода.
  2. Нестандартная организация ветвлений даёт интересные возможности реализации, так называемых, managed runtime, или (в классической терминологии) безопасных языков программирования.
  3. Функциональные языки можно положить на архитектуру MCp «естественней», чем на традиционные машины.
  4. Особенность кодирования программ (подразумевается машинный код) и особенность их исполнения позволяют сделать MCp постепенно деградирующим процессором. То есть, он может не ломаться целиком, при отказе функциональных устройств, а переходить в режим работы с другим распределением вычислений, с меньшей производительностью, естественно. В отличии от традиционных отказоустойчивых процессоров, у которых функциональные устройства (или сами процессоры целиком) просто троированы, MCp в штатном режиме, когда аппаратные ошибки не возникают, может эффективнее использовать свои вычислительные мощности.
  5. Ко всему этому MCp ещё относительно легко можно масштабировать (позволял бы техпроцесс) и запускать в режиме многопоточности (имеется в виду SMT — Simultaneous Multi Threading) да ещё и с динамическим разделением ресурсов между нитями.


Теперь я попробую объяснить, откуда эти свойства берутся, и откуда такое название «мултиклеточный», то есть, что такое «клетка». О загадочных цифрах в маркировке мне ничего не известно. Может быть, это ключ какого-нибудь «MultiClet»-квеста? :) Нет, я серьёзно не знаю.

Клетки


Клетка (такое уж название) — это основный элемент микроархитектуры MCp. Наверное, существует и более простое объяснение того, что это такое, но мне проще начать с описания существующих процессоров.

Любой современный CPU содержит набор неких функциональных устройств. Их можно разделить на несколько типов. Давайте разделим (для пояснения особенностей MCp мне не понадобятся уж очень детальное их описание, поэтому всё поверхностно).

  1. ALU: арифметико-логические устройства, в широком смысле. То есть, устройства, которые выполняют всевозможные преобразования над данными. У них есть входные порты, на которые подаётся код операции и операнды и выходные, на которых формируются результаты.
  2. LSU: устройства доступа в память (Load/Store Unit). Естественно, эта штука данные не преобразовывает, а записывает или считывает из памяти. У неё свои входные и выходные порты.
  3. RF: регистровый файл. Эти устройства сохраняют данные с некоторых шин (не совсем правильное название, но не суть) и выдают их на другие шины, ориентируясь на команды и значения на своих входных портах. Шины эти связаны с портами LSU или ALU. Часто говорят, что регистры — это такая быстрая внутренняя память процессора. Правильнее сказать, что RF — это такая очень эффективная внутренняя память процессора, а семантика регистров — это интерфейсы для доступа к нему. Потому что, существует Его Величество...
  4. CU: устройство контроля. Это устройство, которое управляет множеством ALU, LSU и RF (сейчас модно делать один общий RF на ядро, но не всегда было так; просто уточняю), контролируя передачу сигналов между ними, выполняя программу. В современных традиционных высокопроизводительных процессорах само CU очень сложное, и состоит из других компонент: планировщиков, предсказателей переходов, декодеров, очередей, буферов подтверждения и т.д. Но для целей этого рассказа мне удобнее считать всё это одним устройством. Точно так же я не раскладываю на сумматоры и сдвигатели ALU.


Можно сказать, что CU — это устройство, определяющее тип процессора. Почти во всех современных традиционных процессорах ALU, LSU и RF с функциональной точки зрения устроены примерно одинаково (если не вдаваться в тонкие детали реализации и не делать различий между векторными и скалярными ALU; да, согласен высказывание получилось условным). Всё многообразие моделей CPU, GPU, PPU, SPU и прочих xPU обеспечивается разницей в логике работы разных вариантов CU (и эта разница гораздо существенней, чем разница между векторными и скалярными ALU).

Это может быть логика простого стекового процессора, CU которого должен работать по тривиальному циклу. Прочитать из своего RF, состоящего из двух регистров IP (указатель на текущую инструкци) и SP (вершину цикла), оба регистра. Выставить на входные порты LSU код операции чтения и содержимое IP (скорее всего, CU в этом случае просто скоммутирует выход RF и вход LSU), получить ответ — код инструкции. Если, допустим, это код инструкции перехода, то CU должен выставить на портах LSU запрос на чтение значения из вершины стека, изменить SP на единичку, отправить это значение в RF, а на следующем такте скоммутировать выходной порт LSU с входным портом RF (на другой порт выставив значение, соответствующее записи в IP). Затем, повторить цикл. На самом деле, очень просто. Думается, что зря в наших профильных вузах не разрабатывают стековые процессоры в качестве упражнения.

Это может быть логика навороченного суперскалярного и многонитевого POWER8 с внеочередным исполнением, который за каждый такт выбирает по несколько инструкций, декодирует предыдущую выборку, переименовывает регистры, рулит огромным регистровым файлом (даже у i686 с его видимыми 16-ю регистрами, регистровые файлы могли быть размером в 128x64 битов), предсказывает ветвления и т.д. Такой процессор уже не сделаешь в виде домашнего задания.

Или это может быть тоже достаточно простой RISC-подобный CU, который в GPU раздаёт всем ALU, LSU и RF, упакованным в мультипроцессор, одну и ту же команду.

В современном высокопроизводительном CPU именно CU является самым сложным устройством, которое занимает большую часть чипа. Но это пока не важно. Главное, что во всех перечисленных случаях CU — одно, хоть и может при этом загружать работой и контролировать множество других функциональных устройств. Что можно эквивалентно сформулировать и так: в современных процессорах можно выполнять несколько потоков управления (цепочек инструкций) при помощи одного CU (SMT, например, Hyper Threading); но нельзя выполнять один поток управления при помощи нескольких CU.

Ага! Мой юный падаван (мы же все молоды духом и знаем, что ничего не знаем :) разгадка тайны Мультиклета близка. Естественно, сейчас я скажу, что дизайн мультиклеточного процессора таков, что он содержит в себе несколько CU, работающих по определённому протоколу и формирующих при этом некое распределённое CU, которое может исполнять один поток исполнения (одну нить, то есть, thread) на нескольких ядрах. Но сперва я скажу другое.

Так вот, клетка — это аналог ядра в привычном CPU. Она содержит своё CU, ALU (одно, но достаточно продвинутое даже в ранней версии процессора, способное выполнять операции с float[2] значениями, в том числе и операции комплексной арифметики; разрабатываемая сейчас версия будет поддерживать вычисления с double). Клетки могут иметь доступ к общим RF и LSU, или могут иметь свои собственные, которые могут работать в режиме зеркал или даже RAID-5 (если потребуется; помните, самое важное на данном этапе развития проекта слово — «отказоустойчивость»). И одно из самых приятных мест в архитектуре MCp — то, что хотя в таких режимах RF и будет работать заметно медленней, производительность MCp существенно это не снизит, так как основной обмен данными в ходе вычисления идёт не через RF и шунты (bypass), а через другое не являющееся памятью устройство — коммутатор.

Главной особенностью клеток является то, что их CU могут, работая по особому протоколу и с особым представлением программы, вместе составлять один распределённый CU, который может выполнять одну нить (в смысле, thread, в смысле, поток управления). И выполнять они эту нить могут в параллельном, асинхронном, совмещённом режиме, когда одновременно происходят: выборка инструкций, работа с памятью и RF (это очень няшным способом делается), арифметические преобразования, вычисление цели перехода (а от этого я лично вообще балдею, ибо pattern-matching из высокоуровневых языков на это отлично укладывается). И, что ещё более замечательно, эти CU получились намного более сильно существеннее :) реально проще, чем CU современных суперскалярных процессоров с внеочередным исполнением. Они тоже способны на такое параллельное исполнение программы (уточню: но не за счёт своей простоты и распределённости, а наоборот, за счёт своей сложности и централизованности, которые нужны для формирования особых знаний об исполняемой программе; подробнее в следующей части текста).

По моему мнению (которое может отличаться от мнения самих инженеров, разработавших и совершенствующих MCp), самая важное достижение в процессоре — это именно такие CU, именно они и обеспечивают важные на текущем этапе существования процессора отказоустойчивость и энергоэффективность. А сам предложенный принцип их построения важен не только для микропроцессоров, но и для других высокопроизводительных распределённых вычислительных систем (например, по похожим принципам строится система RiDE).

Энергоэффективность. MCp — параллельный процессор, способный исполнять 4 инструкции за такт, это совсем не плохо. И для этого ему не нужно сложное и большое (по своим размерам) центральное CU, он обходится сравнительно небольшими локальными для каждой клетки устройствами. Маленькие, значит потребляют меньше энергии. Локальные, значит, можно обойтись более короткими проводками для передачи сигналов, значит, меньше энергии будет рассеиваться, и выше частотный потенциал. Это всё +3 к энергоэффективности.

Отказоустойчивость. Если в традицонном процессоре погибает CU, то погибает весь процессор. Если в MCp погибает один из CU, то погибает одна из клеток. Но процесс вычисления может продолжаться на оставшихся клетках, хоть и медленней. Обычные процессоры, традиционно, троируют для обеспечения надёжности. То есть, ставят три процессора, которые выполняют одну и ту же программу. Если один из них начинает сбоить, это обнаруживается и его отключают. Архитектура MCp позволяет процессору работать в таком режиме самому по себе, и это можно контролировать программно: если необходимо, можно считать в высокопроизводительном режиме, когда надо, можно считать в режиме с перекрёстной проверкой результатов, не тратя на это дополнительные аппаратные ресурсы, которые тоже могут отказать. Возможны и другие режимы (пока, насколько мне известно, их не запатентовали, поэтому не буду распространяться).

Рождение нелинейности


Теперь я попытаюсь объяснить, почему такой распределённый CU возможен, что он действительно может быть простым, почему для этого нужен другой способ кодирования программы, и почему этот способ, предложенный авторами MCp, клёвый. Мне снова проще начать с описания традиционных (GPU и VLIW тоже считаются традиционными) архитектур.

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

cat test-habr.c && gcc -S test-habr.c && cat test-habr.s

typedef struct arrst Arrst;

struct arrst
{
	void * p;
	char a[27];
	unsigned x;
};

struct st2
{
	Arrst a[23];
	struct st2 * ptr;
};

struct st2 fn5(unsigned x, char y, int z, char w, double r, Arrst a, Arrst b)
{
	int la[27];
	char lb[27];
	double lc[4];
	struct st2 ld[1];

	return ((struct st2 *)b.p)[a.a[((Arrst *)b.p)->a[13]]].ptr->ptr->ptr[lb[10]];
}

	.file	"test-habr.c"
	.text
	.globl	fn5
	.type	fn5, @function
fn5:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$1016, %rsp
	movq	%rdi, -1112(%rbp)
	movl	%esi, -1116(%rbp)
	movl	%edx, %eax
	movl	%ecx, -1124(%rbp)
	movl	%r8d, %edx
	movsd	%xmm0, -1136(%rbp)
	movb	%al, -1120(%rbp)
	movb	%dl, -1128(%rbp)
	movq	56(%rbp), %rdx
	movq	56(%rbp), %rax
	movzbl	21(%rax), %eax
	movsbl	%al, %eax
	cltq
	movzbl	24(%rbp,%rax), %eax
	movsbq	%al, %rax
	imulq	$928, %rax, %rax
	addq	%rdx, %rax
	movq	920(%rax), %rax
	movq	920(%rax), %rax
	movq	920(%rax), %rdx
	movzbl	-134(%rbp), %eax
	movsbq	%al, %rax
	imulq	$928, %rax, %rax
	leaq	(%rdx,%rax), %rcx
	movq	-1112(%rbp), %rax
	movq	%rax, %rdx
	movq	%rcx, %rsi
	movl	$116, %eax
	movq	%rdx, %rdi
	movq	%rax, %rcx
	rep movsq
	movq	-1112(%rbp), %rax
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	fn5, .-fn5
	.ident	"GCC: (GNU) 4.7.2"
	.section	.note.GNU-stack,"",@progbits


Это традиционный ассемблер для регистровой машины. То, что такой код можно выполнить только при помощи одного CU, очень хорошо демонстрирует вот эта цепочка (напомню, что в ассемблере AT&T запись происходит в правый операнд):
	imulq	$928, %rax, %rax
	addq	%rdx, %rax
	movq	920(%rax), %rax
	movq	920(%rax), %rax
	movq	920(%rax), %rdx
	movzbl	-134(%rbp), %eax


Медитируя над этим кодом, можно сказать, что первые пять инструкций нужно выполнять строго одна за другой, а последнюю, 6-ую, можно было бы запустить и параллельно со всеми предыдущими инструкциями. Но в самих инструкциях непосредственно информации о том, что так выполнить код можно, не содержится. Фактически, в традиционном коде с регистрами привязка инструкции к обрабатываемым данным осуществляется единственным способом: установкой инструкции на определённое место в линейно-упорядоченной цепочке команд.

Каждая инструкция, как бы, является оператором, который действует на некое значение — архитектурное состояние процессора (по идее, конечно, она может действовать и на память, и на внешний мир, и для полной строгости и формальности надо говорить и об этом; но CU процессора может отвечать только за процессор; математикам это жутко не нравится, кстати) — которое сформировалось в результате выполнения предшествующих инструкций (с учётом ветвлений, конечно). Чтобы попробовать исполнять этот код при помощи нескольких независимых CU асинхронно нужно ответить на вопросы:
  • как между этими CU разделить архитектурное состояние?
  • как определить, к какой части архитектурного состояния следует применить очередную (какую именно?) инструкцию, чтобы сохранить семантику кода?
  • как потом собрать всё вместе?
  • нужно ли обмениваться архитектурными состояними?


Для ответа на эти вопросы нужно анализировать код согласно его последовательной семантике, когда следующая инструкция применяется к результатам работы всех предыдущих, и собирать информацию об этом анализе в одном месте. То есть, для этого нужна некая единая точка анализа, один CU. Всеми любимые суперскалярные с внеочередным исполнением Core iX, или AMD FX, или POWER8 умеют проводить такой анализ и планировать исполнение кода на его основе. CU этих процессоров способен на такие «чудеса», то есть, на разбор цепочки последовательного кода в независимые параллельные кусочки, и на сборку его обратно в последовательную цепочку завершения операций. Но ничто не получается само собой. Такие CU — самые затратные как по транзисторному бюджету, так и по энергопотреблению устройства в современных высокопроизводительных CPU. Это очень сложные схемы. Можно даже сказать, шедевральные. Кажется, за изобретение первой такой была присуждена премия Тьюринга.

Наверное, лучше один раз увидеть. Это фотография кристалла VIA Isaiah (не самый сложный процессор) с разметкой функциональных блоков. Всё, что не относится к кэшам, PLL, FP, IU, Load/Store — это схемы управления исполнением.

image

Именно поэтому ARM играет в big.LITTLE, потому что они не могут сделать одновременно и экономный, и производительный процессор, опираясь на традиционную архитектуру с регистрами. И именно поэтому, NVIDIA может стучать себя пяткой в грудь и сообщать, что в одном ядре их процессора в 4 раза больше арифметических устройств, чем в одном ядре Sandy Bridge. У SB остальное место занято схемами анализа и планирования исполнения потока линейно-упорядоченных инструкций.

В VLIW и в варианте EPIC от Intel и HP (Itanium) семантика инструкций точно такая же: они должны исполнятся друг за дружкой, изменяя архитектурное состояние процессора (грубо говоря, значения в регистрах). Да, инструкции у таких процессоров сложные и кодируют выполнение большого числа операций. Но необходимость в линейной упорядоченности этих сложных инструкций сохраняется. Поэтому CU в VLIW-процессорах и Itanium-ах не может быть распределённым. Конечно, в этих процессорах CU существенно проще, чем в процессорах с внеочередным исполнением инструкций. Но и у этих архитектур есть свои недостатки, которых нет в MCp. Например, для поддержания высокого темпа исполнения кода VLIW процессоры должны обладать сложными регистровыми файлами: на каждом такте в них одновременно может записываться аж до 6-ти значений (одна из моделей Itanium) одновременно и вычитываться, соответственно, 12. Есть проблема и при работе с памятью: если инструкция содержит операцию доступа к области памяти, ещё не отображённой в кэш (или другую быструю память), то весь VLIW процессор останавливается и ожидает завершения этой операции. В Itanium эту проблему пытались решить принудительными программными prefetch-ами, но получилось хорошо только для научных вычислений. У них структура доступа в память регулярна, предсказуема и выводится на этапе компиляции. На других же высокопроизводительных рынках царствуют (пока) либо RISC SMT-процессоры, либо процессоры с внеочередным исполнением, которые могут выполнять другую работу при задержках во время доступов к памяти.

Итак. Традиционное кодирование программы в виде линейно-упорядоченной последовательности инструкций, ссылающихся на регистры, требует наличия централизованного CU (очень сложного, если хочется эффективно работать с памятью и несколькими ALU). Который должен управлять всеми прочими устройствами в процессоре (поэтому, чем больше устройств, тем больше этот CU и сложнее). Который потребляет много энергии и является критической точкой отказа всего процессора.

В этом месте инженеры «Мультиклет» делают изящный финт ушами и ставят перед общественностью вопрос: а зачем нам привязываться к линейному порядку при кодировании программы? А потом ещё более изящно и гениально отвечают на него: а не за чем!

Параграфы и переходы


Ура! Вновь compilation time! Посмотрим на ту же самую программу детальками (нет, глаза мы к нему ещё не приделали) MCp.

cat test-habr.c && rcc -target=mcp < test-habr.c

typedef struct arrst Arrst;

struct arrst
{
	void * p;
	char a[27];
	unsigned x;
};

struct st2
{
	Arrst a[23];
	struct st2 * ptr;
};

struct st2 fn5(unsigned x, char y, int z, char w, double r, Arrst a, Arrst b)
{
	int la[27];
	char lb[27];
	double lc[4];
	struct st2 ld[1];

	return ((struct st2 *)b.p)[a.a[((Arrst *)b.p)->a[13]]].ptr->ptr->ptr[lb[10]];
}


Далее немного почищенный ассемблер: я убрал для удобства наши отладочные технические коментарии и директивы .local/.global (они сути не меняют). Директива .alias, играет роль #define. Она используется для повышения читаемости кода. Все неоптимальности и глупости компилятора сохранены. Он у нас ещё некоторое время будет на стадии beta-версии (полезной уже, тем не менее, для работы с процессором и выдающей корректный код). Поэтому не судите уж слишком строго. О различных техниках оптимизации мы знаем и будем их постепенно внедрять. А пока это действительно наивный и неоптимальный код, чего уж скрывать. Но мы же обсуждаем архитектуру самого процессора, а не компилятор.

.alias SP 39	; stack pointer
.alias BP 38	; function frame base pointer
.alias SI 37	; source address
.alias DI 36	; destination address
.alias CX 35	; counter

.text

fn5:
	.alias fn5.2.0C #BP,8
	.alias fn5.x.4C #BP,12
	.alias fn5.y.8C #BP,16
	.alias fn5.z.12C #BP,20
	.alias fn5.w.16C #BP,24
	.alias fn5.r.20C #BP,28
	.alias fn5.a.24C #BP,32
	.alias fn5.b.60C #BP,68

	.alias fn5.2.0A #BP,8
	.alias fn5.x.4A #BP,12
	.alias fn5.y.8A #BP,16
	.alias fn5.z.12A #BP,20
	.alias fn5.w.16A #BP,24
	.alias fn5.r.20A #BP,28
	.alias fn5.a.24A #BP,32
	.alias fn5.b.60A #BP,68

	.alias fn5.lb.27AD #BP,-27
	.alias fn5.1.32RT #BP,-32
	.alias fn5.2.36RT #BP,-36
	.alias fn5.3.40RT #BP,-40
	.alias fn5.4.44RT #BP,-44
	.alias fn5.5.48RT #BP,-48

	jmp	fn5.P0
	getl	#SP
	getl	#BP
	subl	@2, 4
	subl	@3, 56
	wrl	@3, @2
	setl	#SP, @2
	setl	#BP, @4
	complete

fn5.P0:
	jmp	fn5.P1
	rdsl	fn5.y.8C
	wrsb	@1, fn5.y.8A
	complete

fn5.P1:
	jmp	fn5.P2
	rdsl	fn5.w.16C
	wrsb	@1, fn5.w.16A
	complete

fn5.P2:
	jmp	fn5.P3
	getsl	0x340
	wrsl	@1, fn5.1.32RT
	complete

fn5.P3:
	jmp	fn5.P4
	rdsb	fn5.lb.27AD + 10
	rdsl	fn5.1.32RT
	mulsl	@1, @2
	wrsl	@1, fn5.2.36RT
	complete

fn5.P4:
	jmp	fn5.P5
	rdl	fn5.b.60A
	wrl	@1, fn5.3.40RT
	complete

fn5.P5:
	jmp	fn5.P6
	rdl	fn5.3.40RT
	addl	@1, 0x11
	rdsb	@1
	exa	fn5.a.24A + 4
	addl	@2, @1
	rdsb	@1
	rdsl	fn5.1.32RT
	mulsl	@1, @2
	wrsl	@1, fn5.4.44RT
	complete

fn5.P6:
	jmp	fn5.P7
	getsl	0x33c
	wrsl	@1, fn5.5.48RT
	complete

fn5.P7:
	jmp	fn5.P7.blkloop
	rdl	fn5.3.40RT
	rdsl	fn5.4.44RT
	rdsl	fn5.5.48RT
	addl	@2, @3
	addl	@1, @2
	rdsl	fn5.5.48RT
	rdl	@2
	addl	@1, @2
	rdsl	fn5.5.48RT
	rdl	@2
	addl	@1, @2
	rdl	@1
	rdsl	fn5.2.36RT
	addl	@1, @2
	rdl	fn5.2.0A

; Этот ужас - настройка на копирование структуры :)
	getl	0x0000ffff
	patch	@1, @3
	patch	@2, @3
	setq	#SI, @2
	setq	#DI, @2
	getl	0xfcc1ffff
	patch	@1, 0
	setq	#CX, @1

	getl	#MODR
	or	@1, 0x38
	setl	#MODR, @1
	complete

; само копирование, регистры с номерами CX, SI и DI меняются автоматически
fn5.P7.blkloop:
	exa	#CX
	jne	@1, fn5.P7.blkloop
	je	@2, fn5.P7.blkclean
	rdb	#SI
	wrb	@1, #DI
	complete

fn5.P7.blkclean:
	jmp	fn5.PF
	getl	#MODR
	and	@1, 0xffffffc7
	setl	#MODR, @1
	complete

fn5.1L:
fn5.PF:
	rdl	#BP, 4
	jmp	@1
	getl	#BP
	rdl	#BP, 0
	addl	@2, 4
	setl	#BP, @2
	setl	#SP, @2
	complete


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

Каждый параграф содержит некий набор инструкций. Инструкции бывают разными, некоторые из них ссылаются на регистры (отмечены #), но некоторые на значения, полученные в результате выполнения предыдущей инструкции. Ссылка имеет вид @N, где N — это расстояние до некоторой предыдущей по коду параграфа инструкции, на результат которой и ссылается такое выражение. Расстояние указывается в инструкциях и, естественно, отсчитывается назад, то есть снизу вверх по тексту от текущей команды.

То есть, фактически, при помощи @-ссылок в параграфе описывается граф потока данных некоторого участка программы. И инструкции, в основном, являются не операторами, которые действуют на предыдущее архитектурное состояние, а простыми операциями, которые нужно выполнить с одним или двумя значениями. Семантика у большинства инструкций MCp «легче» семантики традиционных инструкций. Архитектурное же состояние меняют только инструкции записи в регистры (setX) или записи в память (wrX).

Мультиклеточный процессор, исполняя параграф, фактически, выполняет редукцию графа потока данных, описанную кодом параграфа. Делает он это следующим образом.

Допустим, в процессоре функционирует N клеток. Тогда клетка с номером n, получив адрес следующего для выполнения параграфа начинает считывать команды, которые находятся в позициях N*k+n (k = 0, 1, ...) параграфа, пока не встретит флаг complete (ассемблер позаботится о том, что она его встретит). И начинает выполнять готовые к исполнению инструкции.

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

И цикл обнаружения готовых к исполнению инструкций и рассылки результатов их выполнения другим клеткам повторяется. Конечно, буферы, которые позволяют отслеживать готовность инструкций — относительно сложные устройства, но они намного-намного проще, чем CU традиционных процессоров с внеочередным исполнением. Если же сравнивать с VLIW и другими EPIC-процессорами, то клетки спокойно переживают задержки при доступе к данным в памяти (или в регистрах), потому что, скорее всего, в буферах их CU будут готовые к исполнению инструкции, которые не зависят от результатов данного конкретного чтения (или записи).

Но это ещё не всё. Клетки по особому работают с памятью и RF. Так как архитектура MCp предполагает, что нет никакой необходимости применять инструкцию к архитектурному состоянию, то при выполнении операций доступа к RF или памяти в рамках одного параграфа никакой порядок не фиксируется. Гарантируется лишь то, что все операции записи будут завершены до первого чтения данных из памяти или RF в следующем параграфе.

Вспомните солидный Load/Store/MOB модуль на диаграмме Isaiah. Так вот, большая его часть — это MOB, то есть Memory Ordering Buffer. Специальное устройство, которое помогает принимать решения о том, а можно ли одну операцию чтения/записи осуществить до (или после) другой. Этот анализ тоже непростой: нужно сравнивать адреса и зависимости. Поэтому схема большая.

Клетка же всегда говорит: ДА! Все выполняющиеся операции с памятью и RF можно в пределах параграфа переставлять как угодно. И это возможно, потому что у программиста и компилятора есть средство выстроить нужный порядок операций явно, при помощи @-ссылок и параграфов. Например, конструкция:
volatile a;
a += a;

транслируется в такой код (немного схематично):
	rdsl	a
	rdsl	a
	addsl	@1, @2
	wrsl	@1, a

запись в котором, выполнится строго после выполнения чтений, даже на не соблюдающих порядок обращения к памяти клетках. Таким образом, необходимый порядок работы с памятью можно задать без помощи сложного MOB, что приносит ещё +1 в копилку энергоэффективности MCp.

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

А в MCp эта проблема решена изящно и просто. Кроме нелинейного порядка между инструкциями внутри параграфа, существует ещё и последовательный линейный (ну, если уж совсем точно, то линейный темпоральный) порядок выполнение самих параграфов. В каждом параграфе может содержаться несколько инструкций перехода: jmp (безусловный переход) и jСС (различные условные переходы), через которые вычисляется адрес параграфа, который необходимо выполнять следующим.

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

Эта особенность MCp уже даёт качественно иные возможности в кодотворчестве. Рассмотрим, например, программу с такой структурой:
	doSomething;
	if(condition)
	{
		doStuff;
	}


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

Пока процессор не выполнит doSomething он не должен выполнять переход. Современные традиционные высокопроизводительные процессоры, благодаря своим сложным CU могут не задерживаться в этом месте, а начинать спекулятивное выполнение перехода, сделав предположение о том, по какой ветви должно идти исполнение. Для этого они пользуются предсказателями переходов, чтобы с большей вероятностью угадать корректное ветвление. Когда же условие перехода оказывается вычисленным они могут сказать сами себе: о, я красава! не ошибся; или: капец, капец! я попал не туда, надо всё переделывать.

В MCp же расчёт цели перехода с вышестоящим кодом можно осуществлять легко, не принуждённо и заранее, в том же параграфе, что и doSomething (конечно, если зависимости по данным это позволяют сделать). Поэтому клетки в MCp могут не голодать (не испытывать недостатка в инструкциях), и обходится при этом без спекулятивного исполнения кода (не тратя на него энергию) и без предсказателя переходов (не тратя на него транзисторы и энергию). Минус предсказатель перехода без потери темпа выборки инструкций +1 к энергоэффективности.

Итак, в MCp действительно есть распределённый CU, который образуют несколько взаимодействующих CU клеток. Действительно эти CU простые, и обеспечивают совмещённую параллельную обработку: выборки инструкций, арифметического счёта и операций доступа к памяти и RF.

Трудности роста клеток


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

Первая проблема — это обработка прерываний. Пока прерывания обрабатываются достаточно грубо по следующему принципу. Если при выполнения параграфа не было записей в память, RF и обращений к периферии, то выполнение параграфа останавливается (он как бы и не выполнялся), и управление передаётся в обработчик прерываний. Если же одна из таких операций уже была выполнена, то процессор дожидается завершения параграфа и только потом передаёт управление обработчику. Понятно, что для систем реального времени это поведение не самое оптимальное (мягко говоря). Но эта проблема имеет решение.

Во-первых, к периферии, чтобы всё работало корректно, в большинстве случаев нужно обращаться в режиме запрета прерываний. Во-вторых, операции записи можно накапливать в специальном WriteBack-буффере, и начинать реальное их выполнение по завершении параграфа. Такая WB-очередь, конечно, ограниченный ресурс, но так как MCp хорошо переносит задержки при работе с памятью и RF (да, да, повторюсь, регистры в MCp могут быть относительно медленными, это, кстати ещё +1 к энергоэффективности), то это не будет большой проблемой. С такой очередью прерывания будут обрабатываться без дополнительных непредсказуемых задержек.

Вторая проблема — это устройство управления виртуальной памятью (MMU). С ним пока вообще ничего не понятно. С одной стороны, существуют традиционные OS, которые хочется: Linux, Plan9 :) С другой, вроде как MMU — это дорогое удовольствие. Считается, что на тестах SPEC на управление MMU тратится 17.5% процессорного времени; а SUN в порыве пропаганды Java на неких нагрузках насчитала аж 40%. С третьей стороны, зачем MMU в управляющих системах и супервычислениях (ближайшие цели для MCp)? Считаем же мы на CUDA без всякой виртуальной памяти. С четвёртой, при созерцании прогресса в области управляемых (безопасных) языков, при росте популярности Java, .Net, JavaScript, Go, возникает вопрос: стоит сосредоточится на поддержке таких языков?

С пятой стороны, из-за особенности обработки прерываний, когда точкой отката может быть только начало параграфа, могут появится проблемы. Допустим, кэш трансляций (TLB) в MMU будет рассчитан на 32 трансляции, а в параграфе будет 33 операции чтения из разных страниц памяти. Такой параграф невозможно будет выполнить. Здесь нужно как-то всё специально согласовывать и ограничивать. И т.д. В общем, процесс мозгового штурма этого куба в самом разгаре.

Обоснование преимуществ MCp


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

Энергоэффективностью я Вам уже надоел, наверное :) Но повторюсь, проистекает она из возможности параллельного исполнения кода с хорошим темпом его выборки при помощи простого распределённого CU. Кроме этого, архитектура позволяет ещё и выбирать сценарии работы. Допустим, например, что система приняла решение о том, что она может поработать в режиме малой производительности и с пониженным энергопотреблением. Тогда она может выбрать одну клетку, сообщить ей, что теперь для эта клетка должна выбирать N*k+n (k = 0, 1, ...) инструкции с N=1 и n=0, а остальные клетки отключить. После этого, всё тот же код будет выполняться одной клеткой. Profit? PROFIT! И никакого big.LITTLE не нужно.

Точно тем же механизмом может быть обеспечена постепенная деградация. Если при выполнении некоторого параграфа обнаружится, что какая-то клетка сломалась, то оставшиеся в живых клетки надо перепрограммировать, сменив у каждой N и n. После чего можно пробовать продолжить вычисление (которое, конечно же, должно начать рассылать всем SMS-ки о том, что беда! беда!).

В управляемых средах (managed runtimes) часто нужно проверять поведение кода по ходу его выполнения. Ибо не всегда можно гарантировать корректность программы одним лишь статическим анализом (теоретически, конечно, возможно, но на практике как компилятору проверить что некая зубодробительная физмат функция обладает определёнными свойствами?). Особенности передачи управления в архитектуре MCp позволяют такие проверки (например, выходов за границы массивов) и программирование передачи управления на обработчик исключительных ситуаций подмешивать в параграфы, выполняющие и полезные вычисления. В традиционных архитектурах так перемешивать код нельзя, потому что инструкция передачи управления должна стоять где-то непосредственно перед кодом, корректность которого проверяется.

Поклонники функционального программирования должны порадоваться тому, что инструкции в MCp являются не операторами с побочными эффектами, а чистыми операциями, с результатом, зависящим только от операндов. Это, например, облегчает верификацию кода, что важно для ответственных (dependable) приложений. Кроме того, благодаря всё той же особенности ветвлений любимый всеми pattern-matching может выполнятся эффективнее. Например, выполняя код (что-нибудь классическое):

fib :: (Integral t) => t -> t
fib 0 = 1
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)


CPU с традиционной архитектурой будет сначала проверять равенство аргумента fib на ноль, и ветвится в соответсвии с этим, потом на 1 и т.д. Навороченный суперскаляр с внеочередным исполнением попробует сделать последующие за первой проверки в спекулятивном режиме, но на это он потратит свои внутренние буферы и энергию. А MCp все три проверки может осуществлять параллельно при выполнении одного параграфа, особо не напрягаясь и экономя Ваше электричество.

Наконец, масштабирование и аппаратные нити. Алгоритм выборки инструкций, распространения результатов расчёта и выбора готовой к выполнению команды жёстко не привязан к количеству клеток. Клеток может быть столько, сколько позволяет технология изготовления процессора (сколько транзисторов влезет, длина проводов и т.д.). Разработчики пробовали моделировать процессор с 16-ю клетками на неком навороченном промышленном софте, который, как считается, достоверно отвечает на вопрос: можно ли такой процессор соорудить в реальности и будет ли он работать на заданной частоте? Ответ оказался положительным (больших подробностей я не знаю). Но понятно, что в самой архитектуре особых ограничений нет. И масштабирование такое, повторюсь, не требует изменения архитектуры клетки.

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

Букв было много, спасибо за внимание!


Надеюсь, этот объёмный (уж простите, короче не вышло) текст поможет мне разделить с кем-нибудь то удовольствие, которое я получаю работая с этим процессором.
Бахтерев Михаил Олегович @mikhanoid
карма
180,6
рейтинг 0,0
Системное программирование
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (180)

  • +6
    А как резервируется и проверяется правильность работы коммутатора? Как он устроен, какие лимиты накладывает? Почему «коммутатор» а не шина, как у Intel'а?
    • +1
      У Intel'a кольцо (ring).
      Хотя меня тоже интересует отказоустойчивость системы заведенной на 1 важный блок.
      • +1
        Он может быть зарезервирован так же. В простом варианте ставятся много обычных коммутаторов, и производится контроль того, чего он выдаёт. И это не сложно, потому что он на все порты должен выдавать одно и то же.
    • +1
      Коммутатор в данном случае — это понятие из архитектуры, а не из реализации. Как реализовано сейчас, и как будет в будущем — это опять надо спрашивать у инженеров. От него требуется только умение шириоковещательно передавать вопросы. Поэтому, наверное, и реализация в виде шины, и в виде кольцевой шины, подошла бы.
      • 0
        Речь о том, что будет, если коммутатор даст сбой. Каким образом будет осуществляться «мягкая деградация» по мере выхода из строя отдельных клеток? Я тут вижу вполне себе единую точку отказа.
        • 0
          Коммутатор может быть зарезервирован. То есть, физически, это может быть несколько устройств, которые дублируют друг друга. Он должен выполнять достаточно простую функцию: выбирать значения со своих входных портов и рассылать на все выходные. Это достаточно дешёвое устройство. Кроме того, можно использовать коды с обнаружением и коррекцией ошибок на его datapath-ах. Поэтому, допустим, не нужно трёх коммутаторов для перекрёстной проверки ошибок.

          В общем, это некая широковещательная сеть внутри чипа, а такие сети устойчивыми к сбоям человечество умеет делать. Можно даже сделать модным (Parallela или Single Chip Cloud от Intel) сейчас методом: вставить в каждую клетку микромаршрутизатор и построить полносвязную сеть между ними.
  • –2
    круто!
  • +6
    Эх, на середине, в час ночи, я сдался. Второй подход завтра.
    Спасибо, очень полезная статья, постараюсь вникнуть.
  • +8
    Хабр торт!
  • 0
    Спасибо, очень интересно, ряд идей в этом процессоре просто замечательный! Напоминает анекдот про то, как американцы изобретали специальную ручку для невесомости, а русские использовали карандаши. Отвергая догмы процессоростроения, но находя другие решения тем же самым проблемам, вы тем самым производите в отрасли революцию!

    Единственная претензия будет к си-программе, которую вы используете в качестве примера. Вы ее случайно не с конкурса Obfuscated code взяли?
    • +13
      анекдот про то, как американцы изобретали специальную ручку для невесомости, а русские использовали карандаши

      Надеюсь, вы знаете продолжение этой истории, а именно что «русские» потом закупили 100 таких ручек и тысячу картриджей с чернилами к ним для использования в дальнейшем вместо карандашей, которые представляли опасность из-за горючести и графитовой пыли?

      За статью же спасибо! Особенно интересна именно dataflow архитектура, мне как интересующемуся визуальными dataflow языками программирования было познавательно прочесть о железной реализации данной парадигмы.
    • 0
      Нет. Этот код возник в результате отладки компилятора. Там всякий разный пересчёт ссылок осуществляется, нам было полезно. Ну… Эмс. Да, может быть, надо было что-нибудь осмысленное брать. Кстати, на процессор этот были потрачено очень много времени. Он историю свою ведёт из нашей космической программы, и эта простота и красота, к которой изобретатель процессора пришёл в итоге далась долгими усилиями, и ресурсы на неё были затрачены приличные.
      • +1
        Было бы очень интересно посмотреть типичные конструкции императивных (и функциональных) ЯП с точки зрения вашей архитектуры. Пример на хаскеле показателен и вполне доходчив. А по поводу С-кода хотелось бы конечно большего.

        Скажем, вложенные условные операторы, циклы, исключения…
  • +6
    Спасибо за статью, вы просто герой, такое написать, но кажется мне вы немножечко заангажированны =)
    А я отношусь к проекту с некоторой долей скептицизма, хотя конечно в душе всё равно болею за разработчиков.

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

    Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
    В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.

    Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.

    Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)

    Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?

    P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.
    • +6
      Спасибо за статью, вы просто герой, такое написать, но кажется мне вы немножечко заангажированны =)

      Гы-гы-гы! :) Надо НЛО предложить: человеку, которого 10 раз назовут героем в письменной форме выдавать соответствующую медальку в профиль :) после всенародного голосования. Кстати, ангажирован я не немножечко, а на целые поставки. То есть, если Вам показалось, что немножечко, значит, архитектура объективно неплохая. Что приятно. Ок. Далее постараюсь быть серьёзным.

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

      Мне об этом ничего не известно. То есть, процессор создавался не как коммерческий проект, он разрабатывался как нечто такое этакое интересное. Оказалось, что эта интересная штука получилась производительной и экономичной (по энергии и транзисторному бюджету). И в 2010 ей заинтересовался бизнес. Те приложения, на которые нацелен процессор перечислены тут: ru.wikipedia.org/wiki/Multiclet

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

      Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
      В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.


      А MCp тоже разрабатывался как процессор общего назначения. Степень его ILP примерно такая же, как у современных процессоров общего назначения с внеочередным исполнением (без учёта векторных блоков, конечно). Особенностью же MCp является то, что если становится понятно, что программе не нужна высокая степень параллелизма, то можно отключать клетки и экономить электричество. Наверное Core от Intel теперь тоже так умеют делать, но в MCp это достигается более простыми средствами.

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

      Кроме того, я же не говорю, что современные массовые архитектуры плохи (я даже назвал их шедевральными). Я говорю, что они требуют много транзисторов для своей реализации и потребляют много энергии в своей работе. MCp по возможностям асинхронного исполнения инструкций этим архитектурам не уступает, но при этом требует гораздо меньше транзисторов на реализацию и потребляет меньше энергии. В этом преимущество. Вот, например, упомянутые Вами предсказатели перехода ему не нужны. Потому что архитектура MCp позволяет сообщить процессору примерно следующее: «знаешь, ты пока начинай выбирать инструкции вооОон по тому адресу, а я тут кое-что ещё досчитаю». В традиционных процессорах такой возможности нет, поэтому им нужно спекулятивное исполнение и предсказание переходов.

      Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.

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

      CUDA, вообще-то, очень даже выстрелила. Сейчас очень много научных вычислений делается на CUDA. И NVIDIA — это один из главных конкурентов Intel за кошельки заказчиков на рынке суперкомпьютеров. А Microsoft даже разработала расширения для компиляторов OpenACC, чтобы потоковые (stream на сей раз) вычисления продвигать в массы. Larrabe тоже пошёл на этот рынок и сейчас поставляется в виде Xeon Phi. В Челябинске даже уже стоит компьютер с ними. Другое дело, что Intel, скорее всего, не победит NVIDIA в этом деле. Потому что они пытаются использовать универсальные традиционные ядра с общими кэшами (которые надо синхронизировать), да ещё и с тяжёлым набором инструкций. По энергоэффективности пресловутой они сильно проигрывают NVIDIA, и по производительности тоже. MCp тоже, вряд ли победит CUDA в stream-вычислениях. А вот x86 или ARM в вычислениях универсальных он вполне уделать может, архитектура позволяет.

      Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)

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

      Техпроцесс же да. Но, например, для военных применений грубый техпроцесс даже лучше, более устойчиво всё к излучениям и температурам. А тут проявляется ещё одно достоинство MCp. Даже на грубом техпроцессе и, соответственно, небольшом числе транзисторов, архитектура позволяет достичь 4-х инструкций за такт при асинхронном их исполнении. Что очень-очень не плохо.

      Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?

      Почему нет? Общей конвейер тут не нужен, но каждая клетка параллельно может выбирать, планировать и исполнять инструкции. То есть, три стадии точно есть. Про детали ALU надо уточнять у инженеров (они его сейчас переделывают, поэтому пока документации нет, к сожалению).

      P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.

      Спасибо за мнение :) PR-отделу будет, чем заняться :)
      • +3
        PR-отдел должен делать бенчмарки. Нужно сравнивать себя с потенциальными конкурентами в разных нишах. С процессорами общего назначения корректно сравнивать себя только после того как запустили linux :)

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

        Ну и хорошо бы выложить симуляторы, особенно архитектурный симулятор с профайлером. Чтобы можно было на своем коде померить производительность.
        Для сравнения, похожая архитектура (бенчмарки и симулятор кстати в наличии):
        cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf
        wavescalar.cs.washington.edu/wavescalar.pdf
        • +1
          Да, должен. Но для этого надо допиливать компилятор. Работа ведётся. Наверное, о результатах бенчмарков тоже будут сообщать. За ссылки большое спасибо!
          • 0
            Думаю печь кремений без софтверной поддержки несколько преждевременно. Такое могут себе позволить только университеты работающие на гранты, и организации занимающиеся распилом госбюджета :( Большинство электронных стартапов backend вообще отдают на аутсорсинг, дешевле чем держать backend команду в штате. Адекватным инвесторам достаточно показать FPGA-прототип.
            Лучше тратить ресурсы именно на энэйблинг разного софта. Если посмотреть на ваших конкурентов, то все они предлагают хард вместе с софтверным стеком: ОС, мультимедиа кодеки, коммуникационные протоколы, криптографические либы и.т.д. Думаю что 80% софременного хардверного IP это софт.
            • +1
              Опять же это зависит от многих факторов. В данном случае, компании нужен контроль над разработкой компилятора. Возможно, это требование военных. Возможно, потому что архитектура новая и просто формально её непонятно как передавать сторонним разработчикам. Я не знаю, конечно, наверняка. Вполне возможно и то, что требованием инвесторов было нечто вроде: а вы вообще сможете свою идею до кристалла довести, с технологиями знакомы? Ну и т.д. Это новое всё, к сожалению, для нашей индустрии дело… Поэтому, наверное, компания и идёт таким путём. Да и потом, ассемблер же уже есть. И Си есть, который стыкуется с ассемблером. То есть, для тех, кому нужно выжимать максимум из процессора любой ценой (а в этом случае вычислительный код всё-равно надо писать на ассемблере), софт уже есть: ассемблер для выжимки производительности, Си для управления вычислением.
              • +1
                Мм, я имел в виду не компиляторный бэкэнд (понятно что ваше IP именно компилятор и архитектура), а электронный: place&route, physical verification, BIST всякий, оживление чипов пришедших с фабрики. Плюс к этому составление документации, создание прототипных плат. Всё это кажется несколько преждевременной работой.

                Вполне возможно и то, что требованием инвесторов было нечто вроде: а вы вообще сможете свою идею до кристалла довести, с технологиями знакомы?

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

                То есть, для тех, кому нужно выжимать максимум из процессора любой ценой (а в этом случае вычислительный код всё-равно надо писать на ассемблере), софт уже есть

                Да нет на свете этих людей. Этому описанию соответсвуют энтузиасты, а их единицы, и денег у них нет.

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

                Какой (в общих чертах) бизнес-план у multiclet? По-моему это больше университетский проект, и на выходе, в идеале, должны быть диссертации и IEEE-шные статьи :)
                • +1
                  Да есть на свете такие люди, отличные от энтузиастов. Они даже готовы на то, чтобы время тратить на разработку функциональных процессоров, а не только на то, чтобы на ассемблере код вылизывать. Называются такие люди: спецслужбы и вооружённые силы. Про бизнес-план не знаю, это надо у директора спрашивать. Но почему-то мне кажется, что этот бизнес-план связан именно с такими потребителями. Тем более, что компания входит в аэрокосмический кластер Сколково.
  • +1
    К слову о Plan9 — не уверен насчёт него, но вот OS Inferno насколько я знаю не требует MMU.
    • +1
      В принципе, есть много систем, которые не требуют MMU. Inferno, JNode, даже ранние Android. У MS ведётся проект Midori (бывшая Singularity). Есть ещё всякие Contiki или Barrelfish. Даже у нас (в смысле, в РАН) есть нечто такое этакое. Вопрос в том: выстрелит ли?
    • +2
      Так и линукс бывает nommu.
    • 0
      MMU там нужен, как помню по сорцам 9pi
  • +1
    Ох, круто. Вечером обязательно почитаю. Наверное это все-таки EDGE архитектура, а не EPIC (VLIW)?
    • 0
      Не знаю. То есть, про EDGE-то я знаю, и даже пытался разобраться с TRIPS-ом. Но вот MCp никак у меня с этим не проассоциировался. А вот с VLIW-ами и EPIC-ами да. Потому что тоже есть некая последовательность инструкций, параллелизм которой задан компилятором или программистом. В EDGE, насколько я помню, всё намного суровее. Хотя, может и EDGE. В общем, пусть начальство определяется :)
  • –5
    Я так понимаю windows/linux не взлетят на этой архитектуре? Как вообще быть с существующим софтом?
    • +2
      Софт же бывает разным. Какой-то уже взлетает, клиенты что-то пытаются запускать. С Windows/Linux не понятно. А Java, например, очень даже неплохо взлететь может.
      • –4
        Офис /1С /почтовый сервер/ сервер БД (MSSQL, mysql, oracle) /php+apache+nginx / браузер + почтовый клиент +… — что из этого списка работает?

        Или может какой-то научный софт, типа mathcad, mathlab, hyperchem?
        • +3
          Из этого списка нет… Но это пока не десктопный процессор же.
          • –8
            Бизнесу значит не подходит, ученым тоже, домой не установишь. Остаются военные и энтузиасты, любящие ковыряться в железе.

            Удачи, но я, мягко говоря, немного скептически отношусь к этой разработке.
            • +1
              Военные — это хороший рынок. И энтузиасты тоже. И ещё есть промышленные контроллеры. А скоро будут и учёные, когда пойдёт тема с суперкомпьютерами. Выйти на рынок десктопов сразу же просто офигительно сложно. Посмотрите на опыт ARM. Адекватные люди не воюют с Wintel, не имея за спиной хорошей поддержки. В МультиКлете работают адекватные люди :)

              Да и вообще. Бизнес тоже бывает разный. Вот подошёл ко мне бизнесмен и спросил: а можно ли при помощи этого процессора перетранслировать на лету один сигнал в другой. Как бы вот он Вам интерес бизнеса :) Не весь же у нас бизнес в стране связан с офисной работой.
              • –1
                >>Вот подошёл ко мне бизнесмен и спросил: а можно ли при помощи этого процессора перетранслировать на лету один сигнал в другой.

                Завтра этот же бизнесмен подойдет к программисту Си-шнику, спросит сможет ли он с помощью процессора intel и линукса/windows перетранслировать тот же сигнал в другой. Потом подойдет к другому железячнику и спросит у него может ли он с помощью китайского микроконтроллера, продающегося по 3 копейки за кило сделать то же самое. Потом сравнит стоимость и доступность на рынке Сишников, железячников знающих китайские микроконтроллеры и спецов знающих вашу архитектуру, а также риски от внедрения новой архитектуры и возможность её интеграции с имеющимися системами.

                В общем путь предстоит нелегкий.
                • +3
                  Фишечка в том, что он уже ходил :) У аналогов по потребляемой мощности не хватает производительности. Вы не думайте, что наш бизнес неадекватный. Естественно, все сначала ищут распространённые решения, и только потом ищут среди новых решений, если существующие не удовлетворяют требованиям.
                  • 0
                    Можно подробнее про алгоритм обработки сигнала, на котором вы рвете конкурентов? И о каких требованиях идет речь?
                    • 0
                      Эмс. Ну, например, MCp рвёт конкурентов на БПФ. А про этот конкретный запрос бизнесмена, я не знаю, рвёт или не рвёт. Надо пробовать. Я же высказывался относительно того, что бизнесу вот тоже интересен этот процессор.
                      • +1
                        БПФ? Какой разрядности, каких конкурентов? Для БПФ существуют десятки реализаций, абстрактного БПФ в вакууме не бывает.

                        Одним словом, ждем Dhrystone, SPEC, Linpack :)
                        • +1
                          Комплексное. 32-битовые float. Конкуренты где-то перечислены, надо поискать. Но у MCp в этом случае 2.4GFlops на 100MHz
                        • 0
                          Присоединяюсь. Жутко хотелось бы сравнить с показателями для Tensilica xtensa.
                  • –2
                    У вас есть сравнительный анализ производительности и энергопотребления для каких-нибудь прикладных задач или хотя бы синтетических тестов?
                • 0
                  Ну об этом собственно и была речь в комментариях к тому топику, что ныне скрыт в черновиках. Правда более более обстоятельно и с конкретными примерами.

                  Ну и ещё вопрос цены, делает эти камушки бессмысленными не только для энтузиастов…
              • 0
                Да — вот, вполне подходящая ниша — преобразование сигналов: слишком «параллельное» для традиционных процессоров и слишком ветвящееся для GPU.
            • +2
              Вам лишьбы LAMPы на все устанавливать, не вокруг них весь мир крутится, ежели он всех будет рвать в отношении производительность/энергопотребление, то займет свою нишу среди устройств, где это критично, какие нибудь там автономные метеостанции, спутники, роботы, воякам полюбэ нужен будет. Я, если что, тоже скептически отношусь к этой разраотке, в первую очередь из-за того, что все предыдущие громкие заявления о всяких там русских ойфонах, читалках, осях окахывались на поверку пшиком, но хотелось бы чтобы тут было не так.
            • 0
              Чего бизнесу не подходит? Бизнес разный бывает. Если на этом мультиклете будет эффективнее выполнять как-то ресурсоемкие операции (от сложной обработки видео, но BI), то софт портируют достаточно быстро. Естественно, Офис и бухлгалтерию пока вряд ли портировать будут, но это далеко не самые требовательные задачи, с ними и текущие решения справляются лучше, чем необходимо.
        • +2
          Ещё один товарищ, который не понимает и не знает что существуют процессоры других архитектур и зачем они существуют.
          • –5
            Еще один товарищ считает уточняющие вопросы чуть ли не личным оскорблением)))
            • 0
              Не путайте уточняющие вопросы при полном понимании сути дела, с проявлением собственной неграмотности.
              • –5
                Интересно в каком месте вы нашли мое утверждение о полном понимании сути дела?
                Я правда не особо понимаю конкретные сферы применения данного мощного микроконтроллера.
                Тут даже их представитель в качестве примера практического применения смог назвать только абстрактное преобразование каких-то сигналов в какие-то другие сигналы, без сравнительного анализа с другими архитектурами по мощности, надежности, энергопотреблению и цене.
                Я тем более не могу за них гадать куда засунуть их процессоры, тем более моя работа никак не связана с железом
                • +1
                  Я утверждаю, что вы просто проявляете свою неграмотность.

                  Ну как минимум вы говорите ересь о запуске винды и виндовских приложений на архитектуре для этого не предназначенной. Винда работает ТОЛЬКО на х86 процессорах.
                  А вам для справки, архитектура процессора не ограничивается только х86. Существуют ARM (их тоже море видов), MIPS (аналогично), PowerPC, туева хуча различных прикладных процессоров и контроллеров. Их такое множество и каждый хорош для своей задачи.

                  Вы знаете только пару задачек, и ими пытаетесь мерять. Вам тонко намекают, что ваш кругозор узок, а вы настойчиво со своей линейкой пытаетесь измерять напряжение. Это глупо
                  • –3
                    Винда работает ТОЛЬКО на х86 процессорах.
                    Вроде есть эмулятор для гиков, можно на армо-андро-офоне запустить 98-ю…
                    • 0
                      image

                      Примерно как-то так.

                      Это эмуляция, в чистом виде работать не будет.
                  • –5
                    >>Я утверждаю, что вы просто проявляете свою неграмотность.
                    У вас очень интересный и оригинальный способ определения грамотности населения. Пожалуй я даже напишу в росстат письмо с просьбой изменения методики измерения уровня грамотности, поскольку неграмотными следует считать тех, кто не разбирается в архитектурах процессора.

                    >>>А вам для справки, архитектура процессора не ограничивается только х86.
                    Вы прям как в анекдоте — выдали абсолютно точный и абсолютно бесполезный ответ. Спасибо, но я и так знал, что бывают процессоры с различной архитектурой. Видимо я слишком непонятно выражаюсь, но попробую переформулировать сказанное. Мне не интересно можно ли на нем запустить какую-либо определенную программу или набор программ, будет ли на нем работать мой любимый калькулятор, и игра крестики нолики 3D. Мне интересно что вообще на нем сейчас может работать, портированно ли хоть что-нибудь из существующего софта, какие прикладные задачи можно решать сейчас, какие через год, какие через 5 лет.

                    >>Винда работает ТОЛЬКО на х86 процессорах.
                    Это не совсем соответствует действительности. Если уж так любите точность, то windows работает на x86 и на x86-64, существует версия на AI-64, WindowsRT работает на ARM.
                    Совсем старые версии есть и для других архитектур.
                    Используя виртуализацию можно поставить её можно и на других платформах запустить, на том же ARM, или PowerPC, например habrahabr.ru/sandbox/48005/
                    • +1
                      Минусы в ваших комментариях как бы намекают…
                      • –4
                        Кармодрочерство самое большое зло, существующее на этом ресурсе
                        • 0
                          Ну, ну. Такое я часто слышу от заминусованных. И на поверку оказывается, что минусуют их за дело. Самое интересное, что в топе сидят наиболее деятельные люди на хабре. Мораль отсюда не сложная.
        • +1
          1С — особенно шикарно… он хотя бы под ARM есть?
          • –3
            >>1С — особенно шикарно
            Почему?

            >>он хотя бы под ARM есть?

            Толстый клиент запустить нельзя. Но на 1С можно писать приложения для андроид и iOs.
            Статья по теме: habrahabr.ru/post/153809/
            Еще можно использовать web клиент для работы с 1С. Для андроида не пробовал, а на айпаде работает.
        • 0
          Вот сделают под него Java — и запустится Mathlab…
          • 0
            Matlab на java? Конец света таки настал сегодня.
            • 0
              В конце 2005 я его себе поставил как-то. Весь «сверкал» стектрейсами явовских исключений.
  • +1
    MMU конечно же нужен, но можно реализовать лишь самый необходимый минимум, тоже и сложность будет не большой и затраты ресурсов.
    Но я вот чего не понял, а если в пределах параграфа будет две операции перехода? И что если оба перехода произойдут (два условных перехода и оба условия выполнятся)?
    • +2
      Это забота компилятора/программиста, чтобы такого не было. Если могут сработать два, то будет взять адрес того, что сработает первым.
      • 0
        Лучше бы исключение выдавали — это явный сбой. Хотя компилятор, конечно не должен такого допускать
        • +2
          В принципе, это легко отслеживается статическим анализом. Даже по бинарной программе (особенность кодирования инструкций). Но, может быть, конечно, имеет смысл и исключение генерировать. Тут опять же вопрос tradeoff-ов. Насколько это будет дорого в железе, и насколько это востребовано. Вряд ли много людей будет писать прямо на ассемблере. А в компиляторе проверки таких условий и так проводятся.
          • +2
            Да, но если говорить о надёжности, то это исключение будет дополнительной гарантией корректности исполняемой программы.
        • 0
          Compiler error, и хватит.
  • 0
    Думаю, на случай прерывания можно сделать «сериализацию» внутреннего состояния CPU в память и потом «десериализацию» оттуда. И сделать возможность расширения на память внутреннего «пула промежуточных результатов».
  • 0
    Я правильно понял, что основная фишка в том, что задачу разбиения кода на паралелизуемые блоки переложили с CU на компилятор? И что все остальные бонусы — следствия этого подхода?
    • +2
      Неа. На самом деле эта задача возлагается на компилятор во всех архитектурах. В RISC надо так инструкции выставить, чтобы они параллельно исполнялись на конвейере. В VLIW, чтобы их можно было выполнить на нескольких устройствах. В OoOE-процессорах нужно назначить регистры так, чтобы не было Write-To-Read зависимостей. В MCp компилятор тоже участвует в распараллеливании кода, но основная фишка в том, что CU удалось сделать распределённым. Нет необходимости весь поток инструкций пропускать через одно место, и остальные бонусы и особенности — следствие этого.
      • +2
        то есть эта задача везде у компилятора есть, здесь она просто до формирования явной разметки доведена, и это даёт на следующем шаге (в CU) микрореволюцию устроить — выкинуть анализатор кода и, положившись на разметку, параллелить не думая?
        • +2
          Да. Точно. Можно и так сказать.
  • –7
    Какую-то вы гермафродитную штуковину делаете между «нормальными» императивными процессорами типа x86|ARM и графическими процессорами для видеокарт… С нормальной многопоточностью/многопроцессностью и MMU нерешаемые проблемы… боюсь, придется к этим платам в итоге делать хотя бы маломощную «plain old» императивную «обвязку»…

    При том, что, я слышал, практика выполнения сложных вычислений на видеокартах уже имеется…
    • +3
      Если Вы так думаете, значит, ничего не поняли. Какие проблемы Вы видите с нормальной многопоточностью и многопроцессорностью? В этом-то как раз проблем нет. Нет и нерешаемых проблем с MMU. Там главный сложный вопрос: стоит ли их вообще решать. К видеокартам эта архитектура вообще никакого отношения не имеет, потому что GPU устроены, можно сказать, диаметрально противоположным образом. И практика использования GPU, конечно есть. И даже положительная. Но алгоритмы, которые требуют ветвлений, на них выполняются крайне плохо.

      А есть очень много методов вычислений, когда на каждом шаге итерационного процесса нужно анализировать кучу условий (if-ов), чтобы оптимальнее выбрать следующий шаг. GPU может «взять» такие вычисления грубой силой, типа: а будем делать всегда однообразно, и не важно, что для алгоритм сойдётся за 1000 шагов, а не за 10. Иногда это даёт выигрыш по времени вычисления, иногда нет. Знаю таких физиков, в расчётах которых GPU крайне неэффективны. То есть, если сравнивать тупой алгоритм на CPU и тупой на GPU, то GPU всех рвёт, как тузик грелку. Но если на CPU запускать «умный» алгоритм, то он сходится в 100 раз быстрее.
      • +1
        А, я понял: каждый параграф — это аналог большшой многооперандной команды (~= подпрограммы на внутреннем языке микропрограмм), и критерием разбиения на параграфы является отсутствие между параграфами «промежуточных» результатов, передаваемых мимо регистров или памяти. Ну, тогда что — получается, в отношении арихитектуры, «растащили уровень между соседними», как это делается при рефакторинге кода с избыточными промежуточными уровнями абстракций. И «атомом» выполнения является не команда, как у нормальных процессоров, а параграф, между параграфами содержимое коммутатора считай что стирается.

        Ну тогда на межпараграфном уровне возможны и многопоточность и многопроцессность, правда цена прерывания будет очевидно высокой, но, если считать с точки зрения уровня микропрограмм, всё равно несколько ниже, чем у традиционных процессоров, просто тут она не скрыта, а очевидна.
        • 0
          Эмс… НууууУу. Насколько я могу судить, такой взгляд ничему не противоречит. Поэтому он тоже верный :)
  • –4
    В общем, в качестве специализированного немногопоточного сопроцессора (для спецустройств) покатит…
    • 0
      Всё оказалось существенно лучше…
  • –1
    CUDA тоже не многопроцессная и не многопоточная ;-)
  • +2
    Спасибо за достаточно развернутый и популярный комментарий начинки этого мультиклета. Осталось непонятным: у него один коммутатор (тогда никакой надежности, увы) или одноранговое кольцо коммутаторов?

    И еще, раз у вас есть компиллятор C, вы уже дошли до стадии, когда можно запустить Atlas и проверить производительность матричных умножений?
    • 0
      Ну. Теоретически дошли. Но практически, надо как-то так собрать этот Atlas, чтобы он влез в небольшую память. Да ещё и умножать придётся матрицы размером в несколько килобайт. Насколько это актуально?
      • +1
        Да, есть класс вычислительных задач (например, методы конечных элементов, у химиков DFT) где плотные матрицы небольшого размера. Для универсальности представьте себе разреженно-блочную матрицу с относительно небольшими плотными блоками. Разреженная матрица будет большая, но очередь умножений ее плотных блоков можно разрезать на куски небольшого размера. Если есть техническая возможность такой кусок данных быстро закачать в память мультиклета, там быстро умножить и быстро же вернуть обратно, то да, может быть актуально. Еще лучше, если мультиклет будет жить в одном адресном пространстве с основной памятью, тогда не придется копировать данные туда-сюда, как в современных GPU.

        А вот пример реального кода, где используют маленькие матрицы, даже специальный аналог атласа написали для очень маленьких матриц:
        www.hector.ac.uk/cse/distributedcse/reports/cp2k03/cp2k03/node9.html
        Фактически этот код — месиво из bash'евских скриптов и фортранного кода. Они автоматически генерят кучу версий фортранных матричных умножателей для всех комбинаций размеров двух матриц с разными способами развернуть циклы — и проверяют, какая версия работает быстрее. В конечном итоге их аналог dgemm'а выглядит так:
        — если надо умножить матрицы [1 x 3] * [3 x 4], вызываем multiply1x3x3x4
        — если надо умножить матрицы [2 x 3] * [3 x 4], вызываем multiply2x3x3x4


        В моем текущем проекте (Nektar++) маленькие матрицы тоже актуальны.
        • 0
          Спасибо за информацию. Сейчас как раз стоит вопрос о тестировании и отладке производительности и нужно понять, на каких алгоритмах это нужно делать. Ваша информация очень полезна.
          • +3
            Ну вот я бы на этот процессор стал бы смотреть, если доступны тесты следующего (в порядке важности):
            — плотные матричные умножения, выполненные в технике Libsmm по ссылке выше (классический Atlas, OpenBLAS etc чхать на малые матрицы хотели, а Libsmm дает до 50-кратного прироста против OpenBLAS). Интересуют матрично-матричные и матрично-векторные.
            — разреженные матричные умножения (CSR), блочно-разреженные форматы (посмотрите, например OSKI) — последние часто сводят к очереди умножений плотных блоков, а их можно выполнять вызовами к аналогу Libsmm.
            — preconditioned conjugate gradient: достаточно хотя бы диагонального прекондишинера. Интересуют матрицы (в порядке приоритета): плотные, разреженные, блочно-диагональные с плотными и разреженными блоками.
            — Lanczos algorithm
            — факторизация холеского для плотных и разреженных матриц.
            — решение треугольных систем (результат матричной факторизации): плотные, разреженные.
            — очень хорошо, если оказывается, что железяка быстро в железе вычисляет корни, синусы и прочее трансцендентное (будут очень рады спец-функциям). Без хотя бы корня в железе вас сразу классифицируют в общий ряд с arduino. Вот еще типичное обсуждение (http://software.intel.com/en-us/forums/topic/277543).
            — очень хорошо, если понятно как процессор справляется с относительно случайным доступом в память, например когда бежит по графу. Непрямо на это будет указывать производительность в разреженной алгебре, но спецов по графам это не очень устроит. Если у вас получится скомпиллировать Metis, это будет прорыв.
            — ньютоновский градиентный спуск, с разреженной и плотной матрицей. Тот же interior point method формирует блочную матрицу, где есть много нулевых блоков, просто плотной матрицей не обойдетесь.

            Для всего этого зоопарка — шкалируемость производительности с числом клеток, оценка GFLOPS и memory bandwidth как функция размера задачи. Ведь ваша главная продажная ценность — «оно само распараллеливает, программисту на С ничего делать не надо». Никакого OpenMP, MPI… Так же очень хорошо, если доступна статистика внутренних счетчиков по классификации PAPI.

            Разреженный BLAS нельзя тестировать на случайных матрицах, все на этом обжигаются. Разница в производительности (!) простого матрично-векторного умножения может отличаться в разы в зависимости от структуры разреженности. Всегда берите несколько матриц из реальных задач, часто берут из matrixmarket'а.
            • +1
              Предложенные тесты с матричными умножениями постараемся реализовать, ну и остальные посмотрим, корень в железе имеется.
              • +1
                Попробуйте еще Metis, если он компиллируется и дает хотя бы разумную производительность, это вам сильно расширяет класс применений. Это код на C (правда, не интересовался, какой версии С), надеюсь возни минимум.
              • +1
                Ну и дайте знать, как будут результаты
            • 0
              Раз уже вы в теме бенчмарков, то не подскажете что использовать для теста самого разного железа.
              От простеньких risc, до топовых x86-процов и powerX?
              Dhrystone сильно привязан к компиляторам, точнее к оптимизациям.
              Linpack не пойдет — не везде даже есть FPU, не говоря уже у flops'ах с double.
              Памяти в принципе можно подцепить много через прокси, но не все процы могут её полностью адресовать, поэтому тоже разумные лимиты нужны.
              • 0
                Ну дык зависит от того, производительность чего вы хотите узнать. Какая у вас задача?

                Возможно я не умею такие бенчмаркинги готовить (да и никогда не пытался, пока), но доверия им априори никакого. Вот скажет мне Linpack конкретную циферку в гигафлопсах — и как мне ее натягивать на мою задачу? Только если бенчмаркинг указывает на производительность того самого вычислительного фрагмента, на который моя задача села.

                К тому же, железо без компиллятора вы все-равно ж не протестируете? Так что увы, в общем случае мой ответ — магия поиска оптимальных настроек у наилучших компилляторов для каждой платформы для конкретного микробенчмаркинга.
                • 0
                  Просто для информации.
                  Типа вот этот проц настолько крут, а вот этот — крут в 2 раза меньше.
                  Тупо синтетика, поэтому условные «гигафлопсы» вполне интересны.
                  > К тому же, железо без компиллятора вы все-равно ж не протестируете?
                  Ну в принципе да, поэтому Dhrystone пока впереди в моём чарте.
                  • 0
                    Судя по беседе, вам приходится работать с большим зоопарком железа? Значит, скорее всего у вас не расчеты. Скажите хоть ваш класс задач.

                    Дык и крутизна ведь разная в разных задачах. Возьмете задачи, где данные лежат плотно и подряд (плотная линейная алгебра, dgemm-constraint), там нужно чтоб числомолотилка побыстрее. Возьмете задачи, где данные разреженные (разреженная алгебра, графы etc), там доступ к памяти и производительность подсистемы кэша становится важнее.

                    Вот например мой лаптоп на i7 выдает в максимуме на dgemm (OpenBLAS, одна нить) около 20 гигафлоп, но производительность аналога dgemv от Libsmm (выше упоминал) на маленьких матрицах от 2 до 6-7 гигафлоп в зависимости от размера. Отсюда, производительность разреженной алгебры этими 2-7 гигафлопами и ограничена. Мультиклет вон там в каких-то задачах в одинарной точности выдает чуть больше 2 гигафлопов. Получается, мультиклет сравним с i7? Если окажется, что разреженная алгебра на нем считается на полной скорости, то да, сравним (что вряд ли, но кто знает). А учитывая проблемы распараллеливания, OpenMP, false sharing etc на всех нынешних CPU, может быть и круче (что опять же вряд ли, но кто знает).

                    Так что линпак прекрасен, но только для плотной алгебры, а это очень узкая ниша. В Dhrystone не вглядывался, надо будет посмотреть что там.
                    • 0
                      На самом деле всё проще.
                      Если найду одну очень редкую железку, то напишу цикл статей про развитие архитектуры.
                      И собственно для наглядности было бы здорово отслеживать рост производительности со временем. Хотя бы синтетическую.
                      Причём архитектура металась по разным направлениям, в том числе и очень экзотичным (конвейер процессора разделенный физически на 2 чипа, к примеру).
                      Это больше хобби чем работа.
                      • 0
                        А вы SPEC щупали?
                        • 0
                          Да. Есть 2 проблемы.
                          1. Не всегда есть Си-компилятор под платформу! Например, присутствует только Ada, да и то на VAX-машине под каким-нибудь VAX/VMS. Я, наверно, буду год только адаптировать код SPEC'a к ассемблеру целевой машины.
                          2. Время работы CINT2000 (даже не CINT2006) даже у меня на современном железе занимает пару десятков минут. Сколько месяцев я буду ждать на железе 20-летней давности? :)

                          Dhrystone довольно прост, поэтому портировать его можно за 2-3 дня, плюс столько же на архитектурные оптимизации. Выполняется тоже быстро. В общем, пока аналога не вижу.
                          • 0
                            снимаю шляпу перед мастером. И часто вам попадаются машины на VAX? Во время своего студенчества на кафедре теории функций стоял к тому времени уже устаревший сановский спарк, уже не помню какой номер. Все хотелось его попробовать, но не дали доступа. А сейчас его уже наверное и нет там.

                            Несколько десятков минут на современном железе? Это быстро :)

                            Как вы на старом железе решаете проблему тестов, кушающих память не в себя?
                            • 0
                              > И часто вам попадаются машины на VAX?
                              Не особо, VAX меня не очень интересовал, но пару раз доводилось поиграться с ним.
                              > устаревший сановский спарк, уже не помню какой номер.
                              Я помню лет 7 назад у нас в городе распродавали как раз спарки, причём по ценам чуть ли не новых. Потом связывался с человеком, оказалось что никто не купил и они их тупо выбросили.
                              > Как вы на старом железе решаете проблему тестов, кушающих память не в себя?
                              ээ, а куда?
                              Тесты всё равно приходится адаптировать, поэтому часть проблем решается, а-ля доступ к ф/c, чего часто может и не быть.
                              RAM иногда бывает маловато. но минимум 4Kb. (Для Dhrystone хватает, кстати).
                              • 0
                                Спасибо, вы еще подкинули мотивации посмотреть на Dhrystone внимательнее.
                    • 0
                      В своей статье я писал почему мультиклет не сравним с i7.

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

                      А у мультиклета только 32-х битная арифметика (0.4-0.8GLOPS, 2.4 на редкой экзотике), и никакой внешней памяти нет.

                      • 0
                        как раз поэтому я говорил «что вряд ли, но кто знает» :)

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

                        В предыдущем каменте я скорее ставил задачу рассказать, что на разреженной (разреженно-блочной) алгебре и маленьких матрицах пиковая достижимая производительность в разы ниже таковой для плотной алгебры, по крайней мере для i7. Который не может взять и на ходу распараллелить вычисление. Ну и «сравним» для меня это разница в один порядок: 0.4 GFLOPS (multiclet, float32) vs 4 GFLOPS (i7, float64) — ну, по крайней мере есть что сравнивать, особенно учитывая разницу в частотах и несравнимый уровень вылизанности технологии у Intel.
                    • 0
                      Не. Ну как 100MHz процессор может быть сравним с 1.7GHz-овым? Нет, конечно, не будет такого. В лучшем случае можно будет говорить об удельной производительности на MHz, как о показателе эффективности архитектуры, а не конкретной модели процессора.
                      • +1
                        из вот этого комментария: "«сравним» для меня это разница в один порядок: 0.4 GFLOPS (multiclet, float32) vs 4 GFLOPS (i7, float64) — ну, по крайней мере есть что сравнивать, особенно учитывая разницу в частотах и несравнимый уровень вылизанности технологии у Intel."

                        Собственно, ради подобного сравнения, но с реальными чиселками, я исходный вопрос и задавал. Надежду, кроме разницы в частотах, питает то, что у мультиклета (точнее, качества вашего компиллятора) может оказаться лучшая шкалируемость на клетки по сравнению со шкалируемостью на различные x86 ядра. Тут для оценок вообще никаких данных не хватает: что с кэшем, насколько эффективно клетки обращаются к близко расположенным данным и так далее. Так что пока — гадание на кофейной гуще. Пока вы с коллегой тесты не прогоните ну или хотя бы детально модель внутренностей не расскажете, в терминах задержек каждой операции в числе тактов, длинне конвейеров и т.п.
                        • 0
                          С памятью и кэшами в MCp, скорее всего, тоже всё будет необычно. В текущих моделях для встраиваемых применений, вся память на борту, работает за один такт, позволяет, при удачном раскладе, 4 операции одновременно. Собственно и все другие операции однотактовые. Частота позволяет. Но это сейчас. Дальнейшая архитектура обсуждается.
                          • 0
                            а сколько тактов занимает одна операция умножения? Fused multiply-add есть? Как себя ведут клетки, когда пытаются читать/записать в одну ячейку памяти?
                            • 0
                              Тоже один такт (частота-то небольшая и «всего» 32-бита). FMA есть в виде команды madd, которая считает скалярное произведение двух 2-компонентных векторов: madd A, B. Если A = (a1, a2), B = (b1, b2), то выдаётся a1 * b1 + a2 * b2. При помощи команды patch можно достаточно свободно управлять содержимым вторых компонент.
                            • 0
                              ПРо ячейку памяти забыл! Что ж такое-то!? Прошу прощения. Итак. Сама ISA процессора предполагает. что в этой ситуации будет исполнена только одна операция, которой повезёт больше. И так можно поступать, потому что существует способ явно выразить упорядоченность записей в одну и ту же ячейку через разбиение на параграфы.
                              • 0
                                честно говоря, я мало что понял. Не могли бы вы чуть подробнее рассказать, что происходит с разделением доступа к ячейкам памяти одной команды скалярного произведения между параграфами?
                                • 0
                                  Если не ошибаюсь, код там пока что без многопоточности.
                                  Поскольку очередь команд одна, конфликтов доступа нет.

                                  А распараллеливание происходит самим процессором при выполнении, по зависимостям входных данных инструкций.
                                • 0
                                  Эмс… Вопрос не очень понятен. Команда скалярного произведения, она одна. То есть, она целиком выполняется в рамках одного параграфа. И она не работает непосредственно с памятью.

                                  Для инструкций работы с памятью (и регистрами) действует такое правило: внутри параграфа они никак не упорядочиваются, а исполняют по готовности. Если, например, будет две таких команды:

                                  ...
                                  wrf @1, A
                                  wrf @2, A
                                  ...
                                  


                                  То их упорядоченность никак не гарантируется. Сработают обе, но в неизвестном заранее порядке (он известен, конечно, на уровне аппаратуры, но не программисту).

                                  Гарантируется только то, что все операции доступа к памяти и RF в следующем параграфе начнут выполнятся после завершения всех операций с памятью и RF в параграфе предыдущем.
                                  • 0
                                    В описании вроде ещё есть бит RW в регистре управления PSW — он гарантирует выполнение команд записи только после команд чтения. Т. е. очерёдность с зависимыми данными будет соблюдаться.
                                  • +1
                                    В моем предыдущем комментарии я пытался суммировать свое понимание вашего же описания работы с ячейкой памяти и скалярным умножением. Как вы можете увидеть, получилась полная лажа, я ничего не понял. И по прежнему не понимаю. Но вы лучше сейчас не тратьте время в каментах, а напишите еще хотя бы одну статью, взяв некоторый вычислительный алгоритм и разложив процесс его выполнения на мультиклетный ассемблер и пару возможных сценариев выполнения (у вас же не гарантируется определенный порядок выполнения? Значит возможны по крайней мере два).
              • 0
                О, забавно, я тоже исходно из Кр-ска — посмотрел к вам в профиль.
              • 0
                Недавно наткнулся на STREAM benchmark, писан на фортране и С, и подумал, может вы тоже не встречали. Или?
                • 0
                  Насколько я помню, он больше на анализ производительности подсистемы памяти направлен, чем на cpu.
    • 0
      Про коммутатор забыл сказать. Коммутатор может быть тоже дублированный или троированный. Это простая схема без своих внутренних состояний, которая расслылает результаты вычислений. Такие рассылатели могут быть продублированы, собраны в кольцо, или из них можно построить fat-tree сеть. Для самих клеток и для ABI это не важно. Будут лишь разные показатели у этих решений по производительности, надёжности и стоимости.
  • 0
    Непонятно что делать с этим процессором. Памяти мало. Периферия микроконтроллерная.

    Сильно не разпрограммируешься.

    Пока дешевле использовать Atmel.
    • +3
      Непонятно что делать с этим процессором — Изучать! :) Скоро и памяти будет много, и периферия богаче.
    • 0
      На заре атмел был весьма и весьма поганенький…
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Во! Это хороший вопрос :)
    • +1
      У майнинга примерно 1Mhash/s = 2.4GFLOP
      У Мультиклета на не-комплексных операциях — 0.8 GFLOPS (это если логические операции работают с упаковаными данными)

      Значит скорость майнинга 0.32 MHash/sec

      Это в лучшем случае.
  • +3
    Спасибо за шикарный и развёрнутый пост. Он наконец-то расставил все точки над i!

    А то холивар в прошлом посте был просто чудовищный, и самое ужасное что люди спорят и ничего не понимают.
  • –1
    И Firefox OS на него портировать…
  • 0
    Будет здорово, если MCp выйдет на рынок и составит конкуренцию Cortex'у. Может быть, даже имеет смысл не только выпускать свои процессоры самостоятельно, но и лицензировать, чтобы другие могли делать свои процессоры на базе вашей архитектуры.
    Жду вскоре поста про реальные применения, как варианты: контроллер квадрокоптера, умный дом с веб-сервером, контроллер WiFi роутера и т.п.
    Кстати, если говорить о встроенных применениях — как осуществлять дебаг этого устройства, есть какие-то тонкости, учитывая многоклеточность, относительно традиционных микроконтроллеров?
    Всё-таки не хотелось бы, чтобы процессор так и почил в закрытых военных применениях. Удачи вам!
    • +1
      Если в праздники время будет попробую собрать квадрокоптер, но опять же думаю более познавательными будут простые примеры связанные с подключение датчиков и прочих устройств по различным интерфейсам.
  • +2
    Круто!
    Не ожидал от себя, что пойму: ассемблер последний раз видел много лет назад.
    Многоклеточный, говорите? :)
    image
    Вообще распределенные системы меня удивляют очень сильно. Как из набора довольно простых звеньев в результате получается сложнофункциональная система. Очень интересный тренд. И, думаю, многообещающий.
    • +1
      Да, да! Меня тоже удивляют. DHT там всякий или даже часы Лампорта.
      • +1
        Круто, не слышал раньше о таких часах.
  • +3
    На днях я тут был на симпозиуме техническом организованном ARM. Там были практически все представители экосистемы ARM, все основные игроки кто что-то на их основе делает на рынке сейчас.
    Меня интересовали тренды по много-ядерности-процессности, всякие там OpenCL на армовских чипах, энергопотребление и прочее. К тому же, так как я там был по работе, то меня интересовали вопросы секурности. Впрочем, с секурностью как правило у всех всё очень плохо обстоит…

    Так вот, если вы ребята доведёте эту мультиклеточную архитектуру до ума, то будет настоящая революция. Традиционная не-параллельная обработка подошла сейчас к своему пределу, бизнесу нужны параллельные вычисления, причём очень так нехило нужны. Интел вообще похоже не способен изобрести что-то новое, его огонь угасает. У ARM все эти костыли типа neon и пр — скорее маркетинг, но в ARM сидят не дураки и они прекрасно понимают куда дует ветер сейчас. Но вот то что они делают с Mali — конечно очень жаль. Копируют то, что есть на рынке, причём плохо.
    Складывается впечатление что они конечно подняли свою экосистему за счёт мобильных девайсов, но похоже стали её заложниками. Они рассказывали на этом мероприятии о том как им удалось там всё заоптимизировать и понизить энергопотребление, но… чёрт побери, они топчутся на месте на мой взгляд. В своё время я надеялся что у них получится сделать больше чем то что мы видим сейчас.

    Поэтому очень здорово что всё-таки есть люди, не скованные всей этой догматикой, люди способные создать что-то по-настоящему новое. Браво!
    У меня просьба к автору — обязательно пишите новости по этой теме. Мне было необычайно интересно вас читать, у вас это получается. И тема мне близка и весьма интересна…
    Спасибо за хорошую статью :)
    • 0
      Какой GPU, кстати, лучше — Mali или Vivante?
      • 0
        На мой взгляд, Mali посолиднее будет. Но в лидерах сейчас всякие Imagination конечно.
        Mali только в последней линейке T600 вышел на более-менее нормальный уровень, топовый GPU T678 даже говорят догнал PowerVR и только-только стал юзабельным.

        Суть не в этом — все повязаны патентами и догмами, копируют друг у друга, а реально свежих подходов ни у кого толком нет. Эх, вот взять бы да все патенты и отменить! (с)

        На этом фоне мультиклеты — действительно здорово.
    • 0
      Я вот пытаюсь найти какую-то информацию об этом, может у вас понимание есть: у ARM'ов их графпроцессоры в принципе возможно нагрузить GPGPU? Ведь в отличие от Nvidia etc у них графпроцессор живет в том же адресном пространстве, что и сам CPU, за счет чего нет необходимости долго и мучительно копировать данные туда-сюда? Если я что-то путаю, поправьте плиз. Если на этом Mali можно запустить GPGPU счет — это будет нечто.
      • 0
        OpenCL в Mali поддерживается только начиная с T6xx, это подтвердил их разработчик, делавший презентацию. Кстати именно он и руководит разработкой Mali у них, толковый парень.

        Собственно для GPGPU они и продвигают эту линейку — там был стенд где показывали работу десятка специальных карт-числодробилок воткнутых в какую-то материнку. Всё чин чином, энергопотребление небольшое, можно вживую «потрогать руками», а гигафлопсы на графике большущие.
        Был слайд где они хвастались что при том же тепловыделении они вдвое быстрее чем существующие решения от нвидии и ко. Полагаю что там конечто что-то подкручено, но всё равно похоже на правду, да и это только начало.

        На consumer девайсах на андроиде сейчас есть Renderscript — это тот же OpenCL один в один, только на яве. Так что можно запустить счёт и на таблетке…

        Ну а про копировние данных — думаю без этого не обойтись, в OpenCL же юниты, коры и тп. Постоянное прокачивание данных — это та ложка дёгтя, что есть в OpenCL.
        • 0
          Ага, википедия говорит, только в самсунговских Exynos 5 есть Mali T6xx. А эти самсунги вроде как не добры к линуксу.

          То что вы рассказываете звучит здорово, в перспективе. Я сейчас купил андроидную приставку к телевизору на RK3066, с целью погонять на нем линукс и проверить производительность в расчетах. Ну и думал, что может есть способ граф. процессор завести. Похоже, не судьба — там только Mali 400 (OpenVG, OpenGL). А вот ява на таком маленьком устройстве меня совсем не радует.
          • 0
            Да, к сожалению на 400-тых мали посчитать не получится.
            Недавно ко мне тут приезжал коллега, рассказывал что мучается тоже с Exynos 5, хочет сейчас перейти на другой чип посвежее, но пока не определился, ищет.
            Да и нет ничего толкового ещё на 600-тых.

            А самсунги совсем испортились. Мы у них чипы заказывали одно время, а они потом сказали что больше не будут мелочью заниматься и сняли их с производства. Хоть бы предупредили… Я бы вообще сказал, что они стали очень похожи на Apple, сидят там себе за закрытыми дверями. Зато они лидеры рынка. Пока что.

            В свете последних событий вокруг ихнего Exynos отношение к ним стало меняться в худшую сторону.

            От явы на андроиде так просто не уйти, на то он и андроид. Хоть дальвик и заточен хорошо, но и в гиге оперативки иногда бывает ему тесно. Мы на этом добре только пимпочки пишем чтоб юзер пальцами тыкал, а уж крутится всё совсем на другом чипе.
            • 0
              Так зачем андроид, если можно линукс :) Правда, у вас там юзер в экран тыкает, да, увы.
              • 0
                А у нас и линукса нет на самом деле :)
                Только bare metal, только хардкор!
                Зато такая конфетка получается…
                • 0
                  А поделитесь ссылкой на проект, пожалуйста. Так, посмотреть на пример игрищ с чистым железом.
                  • 0
                    Вот тут меня уже спрашивали. Кое-что у нас в железе поменялось, но суть та же.
                    К сожалению больше подробностей раскрыть не могу, на то есть причины…

                    PS Проект у нас очень нетипичный, я вас предупредил :)
                    • +1
                      Отличный у вас проект, по крайней мере не скучно.

                      В тему, недавно сидел на докладе, парень рассказывал о малоточных вычислениях на встроенных устройствах. Утверждение: считать с малой точностью возможно и очевидно быстрее/энергоэффективнее. Но что принципиально, точность (overflow/underflow) в итеративных алгоритмах типа Lanzcos можно контролировать с помощью очень несложного preconditioner'а. В качестве примера он там приводил эффективную производительность расчета, достигнутую на FPGA — она превышала теоретический предел Nvidia Fermi на порядок или два (правда как сравнивать попугаев разной точности тоже вопрос — число итераций ведь от точности небось зависит). Так что если вам актуально — вот.
        • 0
          Ну а про копировние данных — думаю без этого не обойтись, в OpenCL же юниты, коры и тп. Постоянное прокачивание данных — это та ложка дёгтя, что есть в OpenCL.

          Юниты коры и т.п. — это логические сущности, не обязательно им быть реальными в современном железе. АМД, вон, делает OpenCL который может на системах с последними Radeon и IOMMUv2 лазить в системную память с GPU.
          • 0
            Они честно говоря там перемудрили с последними радионами, народ тут у нас пробовал, но говорят что-то не пошло у них. Впрочем, это не совсем моя тема.

            Про логические сущности согласен, но вот нечасто в железе всё получается так красиво, как этого хочется.
        • 0
          И еще, не подскажете, уже есть продаваемые железяки с картами-числодробилками? А то все обещают :)
          • 0
            То что показывали на выставке было какое-то специфичное. Наверняка спецзаказ или своё производство. Но таким зубрам, что там были это нипочём.

            Честно говоря, даже если что-то найдёте сейчас — я бы подождал полгодика ещё.
            Мали 600-ки только вышли, наверняка сырые.
            • 0
              Да мне в ближайшие полгода и не до того. Спасибо за подробности.
  • 0
    Вопрос по ассемблеру этой машины: есть ли в свободном доступе таблицы опкодов и описание упаковки полей, упомянутых в manual_soft.pdf:
    В мультиклеточном процессоре существуют короткие команды, размерностью 32 бита, и
    длинные, размерностью 64 бита. В команде мультиклеточного процессора закодированы:
    • код операции, определяющий действие, которое необходимо выполнить процессору;
    • суффикс операции, определяющий правила формирования операндов операции;
    • тип операции, определяющий размер операндов и интерпретацию их значений;
    • набор данных (значение ссылки на результат команды, значение ссылки на регистр,
    непосредственное значение) необходимый для формирования операндов;
    • прочие данные, необходимые для выполнения операции или действий, связанных с
    данной операцией.
    • 0
      Да. Эти таблицы были в прежней версии руководства. Но почему-то их решили заменить на рисунки. Возможно, это связано с тем, что сейчас набор инструкций пересматривается и кодировка будет изменена. В общем, я передам, что двоичное представление инструкций тоже интересно. Там нет ничего секретного
      • 0
        Клёво, спасибо.
        Кстати, в мануале ошибки, например в коде сложения 64-разрядных чисел какая-то дикая путаница в строках 22 и 23, должно было быть 22: adcl @5, @3 а строки 23 не должно быть вообще. В связи с этим нотация @x для ссылки на результаты предыдущих команд не совсем удобна: при удалении промежуточных команд нужно пересчитывать смещения. Логично было бы иметь возможность ссылаться на метки, а ассемблер бы уже пересчитывал метки в смещения.
        • 0
          Ага. Это верно. Последние версии ассемблера уже позволяют именовать ссылки. Там можно так писать:

          test:                    
          	size1 := getl #0
          	size1 := getl #1
          	newsize := addl @1, @2 ; прежний формат тоже сохранён для коротких выражений           
          	value := getl #2
          	jne @value, start
          	je @value,  stop
          complete
          
        • 0
          Возможно, сам формат описания будет несколько другим, но сама возможность такая останется.
    • 0
      Ну в принципе можем выложить таблицы опкодов, а для чего такие подробности нужны?
      • 0
        — Так проще понять что к чему. Естественные ограничения команд и т.п.
        — К тому же дизассемблера у вас вроде нет, по крайней мере в составе SDK.
        • +1
          ОпКоды можно посмотреть тут rghost.ru/42397209
          • 0
            Спасибо. Непонятны следующие вещи:
            — где кодируется формат команды — aa или av?
            — где кодируется интерпретация F1/F2 — @s либо #ir?
            • +1
              В 24-25 битах, т.е.
              Суффикс:
              ...... 0X — формат AA
              ...... 00 — F2 содержит адрес коммутатора
              ...... 01 — F2 содержит номер регистра
              Формат AV размер 64 бит. Старшая часть имеет такую же структуру как и формата AA, младшие 32 бита — значение поля V
              • 0
                Спасибо.
                Я кажется понял, чего ищу: нет ли у вас списка рассылки для разработчиков/иного места где можно получить ответы на подобные вопросы?
                • +1
                  Планируется форум, а также прорабатывается возможность организации git хранилища для пользователей. А так на данный момент работает почта и вопрос ответ на сайте multiclet.com
                  • 0
                    Я имел в виду список рассылки с архивом. Это и почта и FAQ в одном флаконе. А вопросы в «воросах и ответах» малость другого плана. Но ок, спасибо. Попробую воспользоваться, если припрёт.
                    • 0
                      Возможно создадим архив с рассылкой на subscribe, спасибо за совет.
  • 0
    Т. е. я правильно понял, что результаты команд в пределах отдельного параграфа как бы автоматически сохраняются как «локальные переменные», и за счёт этого пропадает необходимость в регистрах общего назначения?
    А между параграфами передача данных возможна только через стек / память?

    И ещё вопрос, в связи с активной разработкой архитектуры и упоминанием, что набор инструкций пересматривается: последующие версии процессора планируются совместимыми с текущей?
    • 0
      * Извиняюсь, что общие регистры есть, уже нашёл в описании процессора на сайте.
    • +1
      Полной совместимости при выпуске новых версий процессора достичь всё равно не удастся, изменения будут касаться не только системы команд.
      • 0
        Ясно, спасибо. Но в общем, это нормально, учитывая, что для них нет старого софта, который должен работать на новых версиях без перекомпиляции, как с линейкой Intel, например.
        • 0
          Ну даже Intel в случае с Itanium решил от обратной совместимости отойти…
          • 0
            В первую очередь, я об x86 говорил, конечно. Itanium — это, скорее, отдельная линейка процессоров с другой архитектурой, а внутри неё, если не ошибаюсь, потомки тоже совместимы с предыдущими версиями.

            Вообще, если в будущем ориентироваться на массовый рынок, где процессоры поставляются отдельно от программ, то обратная совместимость быть должна, хотя бы начиная с какой-то версии.
            Иначе невозможно будет обновить процессор, не перекомпилируя при этом весь софт — ОС, программы и т. д. — а ведь исходных кодов у пользователя может и не быть.
    • 0
      Параграф, похоже, следует сопоставлять скорее с одной командой традиционного CPU, а, точнее, с микропрограммой, которая внутри этого CPU её реализует. Тут, похоже, говоря в терминах рефакторинга, «заинлайнили» уровень микропрограмм, получив некоторую «деинкапсуляцию» микропрограмм в качестве неизбежного результата.

      Если бы Intel поменял опкоды микропрограмм в новой версии процессора, этого бы никто не заметил — тоже плюс от инкапсуляции. А тут — «кишки наружу». С одной стороны, больше потенциал повышения эффективности, с другой — гимор. Слава Богу, «наследства» для обратной совместимости ещё нет…

      Есть подозрение, что обратную совместимость в итоге низведут до уровня «рекомендация — не догма»… Можно будет весь негатив, исходящий из этого, инкапсулировать на уровне компилятора С (или даже «символьного» ассемблера — программы на ассемблере останутся обратно совместимыми) или каких-нибудь managed runtimes.
      • 0
        Да, похоже, что-то среднее между микропрограммами и традиционными подпрограммами. Необычно, но это-то и интересно. :)

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

    Хорошей энергоэффективностью

    Сколько конкретно мВт на Мгц при максимальной нагрузке? Это стандартный тест для сравнения энергоэффективности.
    Нет цифры — значит это wishful thinking.

    Нестандартная организация ветвлений даёт интересные возможности реализации, так называемых, managed runtime

    Я правильно понимаю, что это гепотетическая возможность?
    Сейчас вы только заканчиваете доведение C компилятора до коммерческого уровня, сколько лет займет реализация компиляторов для этих «безопасных языков программирования»?

    Особенность кодирования программ (подразумевается машинный код) и особенность их исполнения позволяют сделать MCp постепенно деградирующим процессором.

    Сейчас это поддержано в вашем софте и железе, или это гепотетическая возможность?
    Как определять, что одно ядро допустило сбой? А что если сбой в коммуникации ядер? Именно решение этих вопросов и составляет основную сложность устойчивости с сбоям, и даже гепотетического решения я у вас не вижу.

    Ко всему этому MCp ещё относительно легко можно масштабировать (позволял бы техпроцесс)

    Масштабирование MCp до 4-х ядер уже привело к фатальному провалу производительности из-за вашей архитектуры: 180нм и жалкие 100Мгц.

    Процессоры на классических архитектурах на 180нм работают на частотах 800-2000 Мгц.

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

    и запускать в режиме многопоточности (имеется в виду SMT — Simultaneous Multi Threading) да ещё и с динамическим разделением ресурсов между нитями

    Сейчас это есть? да/нет
    Опять же, вспомним, почему существует SMT? Не потому, что кому-то нравится запускать потоки одновременно, а для того, чтобы скрывать латентность доступа к медленной памяти. Вас эта проблема вообще не касается, ввиду отсутствия внешней памяти. Почему тогда упомянут SMT — не ясно.

    По факту, я не вижу ни одного преимущетсва, которое существует сейчас. То что в будущем можно сделать много хорошего — это беспорно. Но интересует, что представляет из себя Мультиклет уже сейчас.
    • +5
      Посмотрел на ваш сайт и, если честно, у меня возникло странное ощущение. Вроде, человек с вашим уровнем осведомлённости. должен знать ответы на почти все эти вопросы. В связи с этим, у меня возникает вопрос: «почему для вас так важно завалить MCp, словно нелюбимого студента, на экзамене?» :) Ладно. Давненько я не был в роли наглого студента, будет приятно вспомнить молодость.

      Пройдемся по вашим преимуществам:

      Они не мои, а процессора. Мои преимущества: весёлый характер, добрый нрав, знание 10+ языков программирования, основ теоретический физики и машинного обучения, членство в AAAI, а также неплохая работоспособность :)

      Сколько конкретно мВт на Мгц при максимальной нагрузке? Это стандартный тест для сравнения энергоэффективности.
      Нет цифры — значит это wishful thinking.


      Всё это есть на сайте. Странно, что вы рассмотрели информацию о 180nm, но не заметили, что максимальная нагрузка (это та, которая при комплексном БПФ) достигается на 100MHz при потреблении 1.08W. И не забывайте при этом, что на такой нагрузке 2.4GFlops — это не абстрактная производительность (просто перемножили число операций на частоту), а производительность на реальном алгоритме.

      Я правильно понимаю, что это гепотетическая возможность?
      Сейчас вы только заканчиваете доведение C компилятора до коммерческого уровня, сколько лет займет реализация компиляторов для этих «безопасных языков программирования»?


      Нет. Это реальная возможность. Причины я достаточно подробно указал: проверки и программирование переходов по их результатам можно совмещать с самими полезными вычислениями. Мы (чтобы вы понимали, что Мультиклет не один воин на этом поле, мы — это: Мультиклет, УрФУ, ИММ УрО РАН и (возможно в будущем, на что я надеюсь) ЮФУ) занимаемся доведением компилятора до коммерческого уровня тоже достаточно необычным способом, который позволит нам фронтенды для других языков реализовать относительно быстро. На самом деле, frontend Си99 для нашей новой системы уже реализован, где-то за 3 недели (работа 1-го сотрудника). Мы рассчитываем, что через год будет поддержка ещё нескольких языков программированя на хорошем уровне. Я надеюсь, что о нашей системе компиляции я поведаю как-нибудь Хабросообществу.

      Хотя, конечно, как мегазлобный препод, вы можете сказать: то, что не выложено на сайте — всего лишь гИпотетическая возможность. Что же, ваше право.

      Сейчас это поддержано в вашем софте и железе, или это гепотетическая возможность?
      Как определять, что одно ядро допустило сбой? А что если сбой в коммуникации ядер? Именно решение этих вопросов и составляет основную сложность устойчивости с сбоям, и даже гепотетического решения я у вас не вижу.


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

      Масштабирование MCp до 4-х ядер уже привело к фатальному провалу производительности из-за вашей архитектуры: 180нм и жалкие 100Мгц.

      Процессоры на классических архитектурах на 180нм работают на частотах 800-2000 Мгц.


      Эх. А вот это уже даже совсем не смешно (если действительно вы работаете над тем, чтобы микроэлектронику сделать своей работой). Ибо такое сравнение — сравнение эллиптических тараканов в сингулярности со сферическими конями в вакууме.

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

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

      А по каким причинам оно должно возникнуть? Даже если коммутатор может распространять только одно значение за такт (а коммутатор — штука компактная, ибо простая, и стоит в центре процессора, вокруг которого развешены клетки, и срабатывает за такт), то падение производительности будет линейным. И при этом, существует много методов распространять не одно значение за такт, а несколько. Та же кольцевая шина, например.

      Вот если бы это был настоящий коммутатор, когда надо обеспечивать передачу значений в режиме точка-точка, тогда да, задержки росли бы существенно. Как, например, в традиционных OoOE или VLIW процессорах, когда значение из RF нужно передать очень быстро определённому функциональному блоку. Но такая коммутация в MCp не нужна. Кстати, в тех же VLIW-ах, даже для встраиваемых решений, успешно решается проблема коммутации 8 значений 8 разным потребителям (к сожалению, забыл, какая именно модель Blackfin) одновременно. В MCp нужно решать более простую проблему.

      Сейчас это есть? да/нет
      Опять же, вспомним, почему существует SMT? Не потому, что кому-то нравится запускать потоки одновременно, а для того, чтобы скрывать латентность доступа к медленной памяти. Вас эта проблема вообще не касается, ввиду отсутствия внешней памяти. Почему тогда упомянут SMT — не ясно.


      Мне кажется, я достаточно раз вставил слово «может» перед каждым глаголом, чтобы создать у читателя ощущение, что это возможность на будущее. SMT, кроме сокрытия задержек доступа к памяти помогает решать и проблему задержек при обработке прерываний. Но это так, к слову. Ибо следующее поколение MCp будет работать и с внешней памятью тоже. И, кажется, уже в этой, следующей модели SMT будет (точно не знаю).

      По факту, я не вижу ни одного преимущетсва, которое существует сейчас. То что в будущем можно сделать много хорошего — это беспорно. Но интересует, что представляет из себя Мультиклет уже сейчас

      Так об этом детально написано на сайте. Я своей целью ставил рассказ именно об особенностях архитектуры. Чтобы заинтересовавшиеся могли лучше понимать информацию на сайте. Ну, и хотелось, конечно, привлечь внимание к проекту рассказом о потенциале процессора.

      Главными же преимуществами, которые существуют уже сейчас являются: (1) 4 инструкции за так с простым распределённым устройством управления; (2) отсутствие необходимости аппаратно упорядочивать доступы к памяти; (3) дружелюбность к безопасным и функциональным языкам программирования; (4) возможность пообсуждать необычную архитектуру с хорошими людьми на Хабре :)
      • 0
        Боюсь «завалить» МСр на хабре невозможно, не стоит переоценивать хабрасилу :-)
        К Мультиклету я дышу не ровно именно из-за его агрессивной рекламы в худших западных традициях (2.4 GFLOP — именно оттуда) с выдачей минимальной технической информации (особенно по-началу).

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

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

        Если говорить о MIPS (миллионах инструкций в секунду), то у вас их 400, 800 если считать что с упакованными данными все операции работают.

        Итак 800 MIPS, это 1080/800 = 1.35 мВт на 1 MIPS.

        У банального Cortex M4 — 0.53 мВт на 1 MIPS, отрыв в 2.5 раза.

        Но было бы честнее сравнивать с DSP — т.к. гонять в тестах вы собираетесь я полагаю DSP-подобные задачи:
        TMS320C6657 — 3.5W, 80'000 MIPS (160 GFLOP операции там MADD), это 0.042 мВт на MIPS, отрыв в 32 раза.
        • +2
          К Миландру например у меня никаких претензий нет, все четко и понятно, максимум технической информации, минимум кукурузы.

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

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

          Если говорить о MIPS (миллионах инструкций в секунду), то у вас их 400, 800 если считать что с упакованными данными все операции работают.

          Итак 800 MIPS, это 1080/800 = 1.35 мВт на 1 MIPS.


          То, что вы не верите в это, не означает, что этого быть не может. В SDK есть код того самого преобразования Фурье. Любой желающий может его прочитать, убедится, что задержки в нём все скрыты. благодаря особенностям архитектуры, и подсчитать, что этот код позволяет выжать пиковые 2.4GFlops. Если денюжек не жаль, можно его запустить на реальном процессоре и так же убедится в том, что реальная производительность на реальной задаче близка к пиковой. Наверное, скоро будет каким-то образом организован удалённый доступ к платам для тестов, и производительность MCp сможет оценить больший круг желающих. То есть, компания ничего не скрывает.

          Вполне можете брать эти 2400 MIPS для рассчётов различных «попугаев». И Cortex M4 уже не выглядит таким героическим. Кроме того, какой именно Cortex M4 подразумевается? На каком техпроцессе, с какими оптимизациями?

          Но было бы честнее сравнивать с DSP — т.к. гонять в тестах вы собираетесь я полагаю DSP-подобные задачи:
          TMS320C6657 — 3.5W, 80'000 MIPS (160 GFLOP операции там MADD), это 0.042 мВт на MIPS, отрыв в 32 раза.


          Это уже конкретнее. Спасибо. Погуглим… Не, ну вы, конечно, молодец. Сравнили MCp с 1.25GHz процессором, у которого к тому же 8 функциональных устройств, и который делается на 40nm. Чего вы ожидали? Очевидно, он будет потреблять много меньше на MIPS. Чтобы сравнивать именно архитектуры, нужно все прочие параметры зафиксировать, хотя бы техпроцесс и максимальную потребляемую мощность. Cтранно, что вы это активно не хотите замечать.

          MADD в MCP тоже есть.
          • 0
            Открыл пример examples20121009.7z\examples\asm\fft\fft_test1\fft_test1.asm
            Давайте для простоты посмотрим в цикл L5:

            1 четверка команд — 5 операций (3 для цикла, 1 — загрузка 2*32)
            2: 8 операций (4 загрузки 2*32)
            3: 24 (4 комплексных умножения)
            4: 8 операций (4 загрузки 2*32)
            5: 8 (4 комплексных сложения)
            6: 8 (4 комплексных сложения)
            7: 16 (2 умножения, 2 загрузки)
            8: 16 (2 умножения, 2 сложения)
            9: 8 (4 комплексных сложения)
            10: 16 (2 умножения, 2 сложения)
            11: 16 (2 умножения, 2 сложения)
            12: 8 (4 комплексных сложения)
            13: 8 (2 сложения 2 записи)
            14: 8 (4 записи)
            15: 4 (2 записи)

            Итак, на этом куске кода за 15 тактов у нас будет выполняется 156 операций (а не 360),
            что дает нам на этом цикле производительность 1040 MFLOPS.

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

            Вы согласны с этой оценкой?

            Насчет Cortex-M4 — www.st.com/internet/mcu/subclass/1521.jsp, 90nm

            О техпроцессе: история как вы знаете любит повторяться. Мултиклет — не первый Российский микроэлектронный проект, обещавший революцию. До него был Эльбрус — но его основатель говорил слова, печально похожие на ваши — «не было денег на ручную оптимизацию топологии, лепили из библиотеки стандартных ячеек» и «техпроцесс слабоват, вот еще чуть-чуть — и мы всех порвем». Чем закончилось — всем известно. Если у вас на текущем техпроцессе не удается рвать конкурентов по энергопотреблению — то не стоит это и заявлять.
            • +5
              1. Конкуретнов-то MCp как раз побеждает. Просто вы пытаетесь сравнить наш процессор не с конкурентами, а с устройствами совершенно другого класса. Сравнение именно с конкурентами, с той же стоимостью, тем же уровнем «приёмки» с возможностью заказа для военных применений и т.д. есть на сайте.

              2. О революции вообще никто не говорил. Говорили о принципиально новой интересной архитектуре. Она действительно принципиально новая (чего у Бабаяна не было) и интересная (чего так же не было у Бабаяна). Тут обмана нет. Кроме того, денег «Мультиклет» у государства не выпрашивает и работает своими силами. Участие в Сколково даёт только налоговые льготы, а не потоки финансирования. Поэтому сравнение с Эльбрусом совершенно некорректно.

              3. С оценкой согласен. Только вы не учитываете одного (я об этом не рассказывал, ибо это всё детали, которые могут поменяться в следующей версии; но в документации это написано). Текущая версия MCp может переключаться в режим, когда выполнение следующего параграфа начинается одновременно с текущим. Когда программист может гарантировать, что параграфы независимы по данным, он может включать такой режим. В этой реализации FFT такой режим включается. Поэтому во внутренние буферы клеток постоянно подкачиваются команды из следующих параграфов, и они тоже исполняются. Эх… К сожалению, я больше не могу уделять много времени нашей дискуссии, ибо и так выбился из планов. Давайте мы в проведём несколько тестов, о которых нам в этой ветке подсказали, за что сообществу огромное спасибо (скорее всего, это будет линейная алгебра и криптография). И тогда уже с этими результатами обсудим архитектуру ещё раз. Мне бы очень хотелось вас переубедить, ибо, если вас получится, то архитектуру, действительно, можно будет считать очень клёвой. Но пока, к сожалению, время не позволяет.

              До новых споров и удачи!
            • 0
              Кстати, а чем таки закончилась история с Эльбрусом? Расскажите пожалуйста. Они таки выпустили новый вариант Е2К? Или плавно и ненавязчиво пересели на спарки?
              • +2
                E2K выпустили (на буржуйской фабрике), но Intel порвать не удалось — пришлось всей командой разработчиков идти в Intel рвать его изнутри. В итоге все засекретили и E2K продают только военным.

                Для около-гражданских применений — спарки. Мне на тест наш спарк не дали. :-)
                • +1
                • 0
                  В итоге все засекретили

                  Великолепный ход! <facepalm/>
        • +2
          Информации, видимо, мало потому, что не всё ещё запатентовали.
          Статья, скорее — взгляд программиста, работающего с процессором, чем техническое описание. Но зато с примерами кода, они уже что-то проясняют.
        • 0
          Ну по сравнению с рекламой Cortex M4, www.arm.com/products/processors/cortex-m/cortex-m4-processor.php см таблицу внизу по поводу динамического потребления, заявления о высокой производительности и низком потреблении с приведением реальных значений на мой взгляд не так агрессивны, как 8 µW/MHz с незаметной пометкой внизу * Base usable configuration includes DSP extensions, 1 IRQ + NMI, excludes ETM, MPU, FPU and debug, которая иногда отсутствует. А у Миландра есть процессор с блоком FPU одинарной или двойной точности? Но на сайте у Миландра да всё красиво оформлено и перевод документации качественный, но и у нас все необходимое постепенно появляется на сайте.
          • 0
            У Миландра нет процессоров с 32-х битным FPU, и возможно на то есть причина — они делают то, что востребовано оборонной промышленностью, и на что организован ОКР заинтересованными сторонами.

            А ARM я думаю вполне честен, они написали конкретную цифру в конкретных условиях — 0.008 мВт/Мгц, и не включили FPU по вполне понятной причине — далеко не во всех встраиваемых/DSP применениях нужен FPU. Да и FPU не даст увеличение энергопотребления даже на порядок (да даже вдвое не даст), так что цифра остается достаточно корректной.

            Кстати интересен вопрос (я вполне серьезно тут), почему не сложилось с финансированием от Сколково?

  • 0
    Сколково грант не выделило, хотя кто знает может когда-нибудь в будущем и выделит, причиной отсутствия гранта вроде был странный анализ процессора экспертами, следствием чего явился документ multiclet.com/docs/PO/multicellular_architecture.doc. За официальными сведениями обращайтесь в коммерческий отдел компании. Хотя странно, что государство не хочет выделить средства на такой перспективный проект для промышленной, оборонной, научной, аэрокосмической и других сфер применения отечественного процессора.

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