Обновить
1

Пользователь

3
Подписчики
Отправить сообщение

почему после return есть еще вычитание и сложение?

потому что return, после его исполнения, происходит в %ctpr3, тогда как текущий код исполняется в %ctpr0. То есть на эльбрусе в дополнении к основному конвееру дается три дополнительных %ctpr1-3 в которые можно загружать бранчи, вызовы функций, итд что бы на них быстро переключиться. Короче выход запускается асинхронно как корутина, а командой ct %ctpr3 совершается непосредственный await и переход.

До сих пор это был единственный способ вызова и возврата из процедур, в новой системе команд все таки добавили классический
icall fn_name
iret
Из за того что в коде довольно част о происходят подобные ситуации, и асинхронная система становится избыточна:
{ disp fn_name, %ctpr1 }
{
call%ctpr1 }
{
return%ctpr3 }
{
ct%ctpr3 }
мало того что просирает такты, еще и забивает кэш инструкций

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

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

По поводу написание на ассемблере, аллокацию регистров вы врядли вывезете, лучше все таки писать на ассемблернизированном Си используя беззнаковые типы для переменных и заменив сишные операции на вызов макросов вставляющих ассемблерные операции. Компилятору выставить только -O1 чтоб он ничем кроме аллокации регистров и упаковки ШК не заморачивался.
Сама МЦСТ похоже применяет именно такой способ написания на ассемблере (если судить по заголовочным файлам типа e2kintrin.h)

А в каком году купили? До покупки аэродиска аквариусом или после?

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

Риск5 это просто система команд, которая освобождена от роялтей.
И Всё. Это не волшебное заклинание, произнеся которое прилетит фея с vhdl высокопроизводительного ядра в руках. А даже если бы и прилетала от одного ядра толку мало, без обвязки контроллеров это бумажный тигр.

У продавцов электроники на складах полно старых интелов и AMD, под которых просто уже не найти материнских плат, той же МЦСТ стоило бы лучше выделить финансирование на то что бы адаптировать свои контроллеры, материнские платы и ПО под них. Это было бы более полезно чем очередной процессор о котором никто не просил.

Да там даже сайт похоже китайцы делали:

С ним то же самое что с полковником МВД который закупил 10k терминалов "Таволга" для МВД.

Насколько я помню был проведен тендер, требованиям которого ни байкал-Т1 ни эльбрус 1С+ не соответствовали, гаишникам нужен был дотнет и java так как на них написано ПО с экзаменом ПДД. Эльбрус отлетел сразу, а байкал по известным неизвестным причинам тендер выйграл. А когда им предъявили что компы требованиям не соответствуют, байкал электроникс (тогда им руководил еще не Евдокимов, а какой то неприятный дед похожий на Чемезова) включал дурака и заявлял что можно же в гнездо SO-DIMM и 8гб модули вставить, а в PCIe слот какую нибудь видеокарту, и значит они всем требованиям соответствуют. А то что у них там 32битный mips (купленый кстати за деньги РОСНАНО) который больше адресовать не может, нет никаких дров на pcie и дискретные видеокарты не поддерживаются это остапа бендера не волнует, лишь бы впарить и умыть руки.

Во всем мире уже вовсю используются сети 5G

Чукча писатель, а не писатель? В статье речь про планы на разработку своего чипа, а не про развертывание LTE/5G на процессорах Qualcomm как "во всем мире".

позволяет компилировать ядро Linux в промежуточный код WebAssembly для последующего прямого выполнения в веб‑браузере без задействования эмуляторов.

все таки wasm это что-то типа байткода виртуальной машины, и исполняется оно в js-рантайме ( как джава опять таки). Браузер это все таки нативное приложение которое старается безопасно увязать свой контекст где все нативные библиотеки и апи вызовы живут с js-контекстами. А многим раньше еще и пытались примотать сюда на скотч флеш, джава и другие сторонние плагины. А потом появился emscripten который показал что нужно не чужой рантайм пытаться встраивать, а конкретное приложение. Так и пришли к wasm.

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

Глядя на это можно спросить то же самое - какие могут быть перспективы на десктопе у этих блобоколясок на risc-v когда на рынке есть нормальные селероны с amd-apu?

Я еще мог понять когда были аргументы за свободное железо, но тут тот же самый огороженый одноплатник просто вместо aarch64 теперь riscv64

JavaScript Canvas

Мог бы вот этими двумя ограничиться. Пистон то с луа зачем?

А, так это нейросеть писала, тогда понятно.
Ютуб загажен этими нейромусором с новостями из параллельной вселенной, теперь еще и статьи на швабре и дзене. Интернет умер.

Архитектурные инновации:

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

Суперскалярные эльбрус-1/2 делали 2 (две) операции за такт.
Ко всему остальному в статье лучше тоже следует относится настороженно, автор явно не понимает о чем пишет.

Два руководителя из мцст в двух прошлогодних видео сказали что "да, возможно" (про 25й год и Э32)

Я с -O1 что-то не наблюдаю такого:

Обычный mulsd
Обычный mulsd

Продублировал на Compiler Explorer:
matmul C
matmul C++
Оба по времени исполнения выдают практически идентичный результат, правда на C++ куда то целая часть из результата пропадает и нету желания разбираться.

Upd:
с плюсами разобрался забыл что там линии по несколько раз проходятся и надо += (суммировать).
Закономерно производительность упала в 4 раза по сравнению с Си. Только с -O3 код на плюсах становится на ровне с Си, вот вам и двумерные массивы.

На xmm регистрах интел считает плавучку, это не векторизация.

JIT компиляторы так и делают, а сишный компилятор у него нет рантайм-информации он скомпилировал и выдал, какие еще проверки? Я поэтому и говорю что если нет понимания или желания понимать что статик-тайм-компаил и особенно с ручным управлением памятью требует активного участия со стороны программиста в построении оптимального потока данных и кода для их обработки, то лучше отложить си в сторону и идти писать на питоне с jit компилятором или хотя бы на расте где фронтенд и safe-семантика контролируют все еще на этапе написания кода.

В конкретном примере matmul.c предполагается что размер матрицы может быть определен из аргументов командной строки (что в данной реализации приводит к непредсказуемому поведению в случае запуска через time ./matmul):

int main(int argc, char *argv[])
{
	int n = 1500;
	double **a, **b, **c;
	if (argc > 1) n = atoi(argv[1]);
}

То есть двумерный массив никак не оптимизировать, и вместо того что бы написать макрос который вычисляет сдвиг по оси Х подкинули еще цикл который режет массив на куски. Потом какой нибудь студент вася заметит что вконце очищается только mat[0] подумает непорядок и засунет цикл который "все" отрезки чистит, программа сегфолт выкидывает ну и ладно главное результат печатет.

В matmul -е есть, вот этот код:

double **mat_alloc(int n_row, int n_col)
{
	double **mat, *a;
	int i;
	a = (double*)calloc(n_row * n_col, sizeof(double));
	mat = (double**)malloc(n_row * sizeof(void*));
	for (i = 0; i < n_row; ++i)
		mat[i] = &a[i * n_col];
	return mat;
}

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

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

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

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

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

Информация

В рейтинге
6 252-й
Зарегистрирован
Активность