Кто-нить тестил, насколько Эльбрусы медленнее обращаются по невыровненным адресам?

Если у тебя есть железка то просто проведи эксперименты. jump jpegqs

У amd64 он исчезающе мал

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

То, что обращение в принципе возможно, я нагуглил.

http://www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdf

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

кто нибудь тестил

нет конечно… ты видел сколько оно стоит?

всего 400 тыс руб, а если без корпуса, то и дешевле. А что?

это загранью экономических возможномстей 99.9% пользователей

У тебя неправильная методичка. Спроси у vaddd как унылить нужно на данную тему! 😜

Когда-то предлагали доступ по ssh

UPDATE: но есть нюанс

не может публиковать результаты без предварительного согласования

Железки нет. Вопрос на будущее.

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

На больших объёмах и экономия от упаковки данных тоже пропорционально бОльшая.

http://www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdf

Вот как раз это и нагуглил.

Зависит от версии архитектуры, до v5 было медленнее, в v5 ускорили. (Причём даже в v5 не совсем идеально, в v6 стало еще лучше.)

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

Лучше ходить по этой ссылке: http://mcst.ru/elbrus_prog

Потому что есть обновление материала до 1.1, да и там есть что улучшать, так что я жду дальнейших обновлений.

Жаль, что компилятор подозрительно долго не обновляли. Правда и до этого обычный режим релизов был ближе к «раз в два года». Надеюсь, поближе к возможностям gcc9 подтянут lcc и lfortran в новом выпуске.

Большинство платформ, всяких DSP и прочих, не поощряют невыровненные адреса, есть и еще более крупные единицы выравнивания, типа cache line и так далее

это цена за какую модель? пытался найти, сколько стоит «Эльбрус 101-miniPC». Везде только цена по запросу…Как-то не ориентировано на покупателей…

На сколько дешевле?

ЕМНИП чуть больше года назад голая плата с 1С+ выходила примерно в 160к рублей, что-то поинтереснее было уже ближе к 200.

Я интересовался был момент, даже почти жабу удавил, но стало не до того.

На стоимость корпуса, очевидно.

Раз уж заговорили о корпусе, он российского производства или китайского?

это цена за какую модель? пытался найти, сколько стоит «Эльбрус 101-miniPC». Везде только цена по запросу…Как-то не ориентировано на покупателей…

245 тысяч. В сентябре 2022 было. Но покупать всё равно по запросу придётся и оплачивать на банковский счёт (то есть нужно юрлицо или ИП).

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

оплачивать на банковский счёт (то есть нужно юрлицо или ИП)

Недопонял: физик что, на счёт оплатить не может?

Так расчётного счёта же у физика нет. Думаю, у них ККТ нет, чтобы чеки от перечисления через СберБанк пробивать.

На нём написано, что российского. Также как и материнская плата.

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

Станет ли в обозримом будущем мем «как оптимизировать javascript под эльбрус» популярнее мема «как пропатчить kde под freebsd»?

Конечно. Про freebsd к какому-то моменту забудут, а про javascript ещё нет.

Да…за такую цену поддержка должна быть дружелюбной ))

Железки нет. Вопрос на будущее.

У Эльбруса нет будущего.

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

Неверно.

В v4 нельзя использовать APB с невыровненными адресами. Простой пример, без выравнивания 0.75 такта на итерация, с выравниванием 0.5 такта на итерацию.

В v5 APB может работать по невыровненным адресам, но не для 128-битной записи через AAU. Тот же пример, без выравнивания 0.5 такта на итерацию, с выравниванием 0.25 такта на итерацию.

В v6 эти проблемы должны были окончательно поправить, но это не точно.

Для обычных обращений в память (не через AAU) lcc не видит разницы и генерирует одинаковый код. Хотя на уровне аппаратуры могут быть штрафы если обращение на границе страниц или кеш-линий, а может и всегда, этого я не проверял.

Коммутатор HP стоит примерно столько же. Поддержка сводится к «приезжайте к нам на курсы, за месяц и много тысяч долларов что-нибудь расскажем».

Сейчас под крыло РосАтома ушли (https://www.kommersant.ru/doc/5813229). Техническая возможность развивать есть, посмотрим.

Твои примеры не открываются, они не в общем доступе.

Не только мои.

Oh and I accidentally lost old links.

#define N (1 << 20)

void test(long *x) {
    for (int i = 0; i < N; ++i) {
        x[i] += 1;
    }
}

v4

{ ! unaligned
  loop_mode
  ! чтение через L1
  ldd,0,sm      %dr0, %db[4], %db[1] ? %pcnt1
  addd,1,sm     %dg17, 0x1, %db[6]
  ldd,2,sm      %dr3, %db[4], %dg17 ? %pcnt1
  ldd,3,sm      %dr2, %db[4], %db[5] ? %pcnt1
  addd,4,sm     %dg16, 0x1, %db[4]
  ldd,5,sm      %dr4, %db[4], %dg16 ? %pcnt1
}
{
  loop_mode
  ! запись через AAU (сквозь L1)
  staad,2       %db[6], %aad0[ %aasti1 + _f32s,_lts1 0x10 ]
  addd,3,sm     %db[3], 0x1, %db[4]
  addd,4,sm     %db[7], 0x1, %db[6]
  staad,5       %db[4], %aad0[ %aasti1 + _f32s,_lts0 0x18 ]
}
{
  loop_mode
  alc   alcf=1, alct=1
  abn   abnf=1, abnt=1
  ct    %ctpr1 ? %NOT_LOOP_END
  staad,2       %db[4], %aad0[ %aasti1 ]
  addd,4,sm     %db[2], %dr5, %db[0]
  staad,5       %db[6], %aad0[ %aasti1 + _f32s,_lts0 0x8 ]
  incr,5        %aaincr1
}

{ ! aligned
  loop_mode
  alc   alcf=1, alct=1
  abn   abnf=1, abnt=1
  ct    %ctpr1 ? %NOT_LOOP_END
  staad,2       %dg17, %aad1[ %aasti1 ]
  addd,3,sm     %db[10], 0x1, %dg17
  addd,4,sm     %db[11], 0x1, %dg16
  staad,5       %dg16, %aad1[ %aasti1 + _f32s,_lts0 0x8 ]
  incr,5        %aaincr2
  ! чтение из APB (AAU, сквозь L1)
  movad,0       area=0, ind=0, am=0, be=0, %db[0]
  movad,1       area=0, ind=8, am=1, be=0, %db[1]
}

v5

{ ! unaligned
  loop_mode
  alc   alcf=1, alct=1
  abn   abnf=1, abnt=1
  ct    %ctpr1 ? %NOT_LOOP_END
  staad,2       %db[7], %aad1[ %aasti1 ]
  qpaddd,3,sm   %xb[10], %xr2, %xb[1]
  ! извлечение верхних 64 бит (поменять местами половинки)
  qpswitchd,4,sm        %xb[5], %xg16
  staad,5       %dg16, %aad1[ %aasti1 + _f32s,_lts0 0x8 ]
  incr,5        %aaincr1
  movaqp,1      area=0, ind=0, am=1, be=0, %xb[0]
}

{ ! aligned
  loop_mode
  alc   alcf=1, alct=1
  abn   abnf=1, abnt=1
  ct    %ctpr1 ? %NOT_LOOP_END
  qpaddd,0,sm   %xb[11], %xr3, %xg17
  staaqp,2      %xg17, %aad1[ %aasti1 ]
  qpaddd,3,sm   %xb[10], %xr3, %xg16
  staaqp,5      %xg16, %aad1[ %aasti1 + _f32s,_lts0 0x10 ]
  incr,5        %aaincr2
  movaqp,0      area=0, ind=0, am=0, be=0, %xb[1]
  movaqp,1      area=0, ind=16, am=1, be=0, %xb[0]
}

У Эльбруса нет будущего.

«В долгосрочной перспективе все мы мертвы.»(c) =)

Ну Эльбрус не в сильно долгосрочной.

а как сказать компилятору что данные неровные?
почему вообще long *x неровные, тут же подразумевается числа 64бит по порядку расположенные.

Я всегда думал что невыровненные данные это типа:

typedef unsigned short uint16_t;
struct MyObject {
  uint16_t x, y;
  void *ptr;
  bool visible;
};

void test(struct MyObject **o, uint16_t mx, uint16_t my) {
    for (int i = 0; i < N; i++) {
        if (o[i]->visible)
            o[i]->x += mx,
            o[i]->y += my;
    }
}

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

А так можно и буфер кастовать в указатель на какой-нибудь тип и пытаться считать оттуда данные. Особенно хорошо если компилятор вставит инструкцию которая не учитывает невыровненные адреса.

а как сказать компилятору что данные неровные?

По умолчанию подразумевается, что данные невыровненны.

Я всегда думал что невыровненные данные это типа:

Нет. Выровненные, это когда 64-битное значение лежит по адресу с нулями в первых трёх битах (0, 8, 16, 24, 32. и тд.).

yukari$ cat a.c
#include <stdio.h>
#include <stdlib.h>

#define N (1 << 20)
void test(long *x) {
        for (int i = 0; i < N; ++i) {
                x[i] += 1;
        }
}

int main() {
        char *p = calloc(N + 1, 8); // aligned
        test((long *) (p + 1 /* unaligned */));
        return 0;
}
yukari$ lcc -O3 -faligned a.c
yukari$ ./a.out
Недопустимая инструкция
yukari$ lcc -O3 a.c
yukari$ ./a.out
yukari$ 

Что неверно? Не используешь -faligned - весь код тормозит, даже если выровнен. А если используешь, то надо всё выравнивать, иначе могут быть падения. В v5 штрафы стали меньше. На v6 еще меньше. Им оказалось проще доработать железо, чем компилятор.

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

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

Это после моего замечания стало понятно? :)

Это после моего замечания стало понятно? :)

Это из того, что я писал до вас было понятно, без ваших подробностей.

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

Можете продемонстрировать на примере? :)

У меня есть примеры в баге для МЦСТ, где для v3 разница в 10 раз, при обработке выровненных данных, но в одном случае компилятор понял, что они выровнены, а в другом нет. Для v5 всегда получается быстро. Так что в новых версиях архитектуры они проблему выравнивания решили.

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

так что примеров не будет.

Ожидаемо. :)

Если что, я экспериментировал как совмещать код что обрабатывает выровненные данные, вместе с кодом с невыровненными, без включения -faligned для всего кода. Некоторыми способами это получается, некоторыми нет.

Вы хоть понимаете зачем AAU в E2k? Особенно какая может быть разница в производительности если его не задействовать? Код без AAU — ваши мифические «задержки» и «разница в 10 раз». :)

А можно не вести себя так вызывающе? Я не собираюсь вам ничего доказывать, вы ведете себя как выскочка.

Просто меня раздражают фанатики… Если вы не собираетесь ничего доказывать, зачем тогда начали это делать? Правда надолго вас не хватило. :)

Хорошо не иметь прямых связей с МЦСТ, чтобы ситуации как с чертежами не было. :)