Здравствуйте, novitk, Вы писали:

N>Фабрика ортогональна.
N>Эльбрус надо было прибить сто лет назад(мы собственно тогда тут на эту тему дрались). Ибо после Итаниума было понятно, что тупик.
N>Так как про СВО никто не знал, ну может кроме Путина, то разумно было бы перевести все ресурсы(деньги и инженеров) на ARM(Байкал) и/или RISK-V.

Ну, в итоге случилась СВО, Байкал превратился в тыкву и что толку было от вваливания ресурсов в ARM?
Разве что, несколько инженеров поработали с чипами, теперь могут наверно быть полезны в компаниях, работающих с RISC-V.
RISC-V — когда процессоры на этой архитектуре делать начали в принципе? Лет 5-10 назад?
Если бы, например, в 2020 году возник вопрос: начинать разрабатывать Эльбрусы на их VLIW или брать RISC-V, то я бы сказал, что RISC выглядит перспективнее и нечего экспериментировать.
Но когда Эльбрусы уже производились и можно их использовать, а RISC-V будет только когда-нибудь через пару лет может быть,
то уже сделайте возможным использование того, что есть, а потом занимайтесь перспективами.
При наличии тех же Эльбрусов попутно условно через 10 лет делать тот же RISC-V было бы проще.
Специалисты на Эльбрусах выросли, набили шишки, появились компетенции. С производством тоже уже было бы всё понятно.
Вместо этого сейчас все по отдельности ковыряются, непонятная и бессмысленная конкуренция, в итоге на выходе ничего нет.

N>Никто существующие спеки в RISC-V задним числом заблокировать не может. Если нужен форк, делайте.

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

Здравствуйте, karbofos42, Вы писали:

K>Если бы, например, в 2020 году возник вопрос: начинать разрабатывать Эльбрусы на их VLIW или брать RISC-V, то я бы сказал, что RISC выглядит перспективнее и нечего экспериментировать.
То что Эльбрусы г... было понятно и в 2020 и в 2015 и в 2010 и в 2005. Это стало понятно ровно тогда, когда Интел который потратил на VLIW в 20х больше ресурсов, чем РФ закрыл Itanium.

K>Но когда Эльбрусы уже производились и можно их использовать, а RISC-V будет только когда-нибудь через пару лет может быть,
K>то уже сделайте возможным использование того, что есть, а потом занимайтесь перспективами.
Ресурсы конечны и те что были потрачены на адаптацию и дальнейшую разработку Эльбруса для широкой публики это просто сожженные деньги. Это должно было превратиться в русский Itanium, когда результаты у Интела стали понятны.

K>При наличии тех же Эльбрусов попутно условно через 10 лет делать тот же RISC-V было бы проще.
K>Специалисты на Эльбрусах выросли, набили шишки, появились компетенции.
С чего бы это? Если начать 10 лет назад, то компетенции на сегодняшний были бы другие.

K>С производством тоже уже было бы всё понятно.
K>Вместо этого сейчас все по отдельности ковыряются, непонятная и бессмысленная конкуренция, в итоге на выходе ничего нет.
Производство не имеет отношение к разработки логики в 2025. Производство — другая и гораздо более сложная проблема, которую РФ внутренне решить имхо не сможет в принципе. Только встраиваться в тех. цепочки под Китаем или США.

Здравствуйте, Sinclair, Вы писали:

V>>На обычных многопоточных, даже независимых по данным.
S>На "обычных многопоточных" данные и так не пересекаются, безо всяких усилий по разметке. Например, при перемножении матриц каждый из потоков работает со своим сегментом матрицы.
S>При сортировке слиянием каждый из потоков сортирует свой сегмент. И так далее.
S>Чтобы когерентность начала как-то сильно мешать, надо специально писать многопоточный код так, чтобы потоки наступали друг другу на пятки.

Ты не понял, разделение задач по памяти тут не поможет. Ключевые слова — uniform memory access (UMA) и синхронизация кэшей, где работает (в общем смысле) MESI протокол.

Пусть у тебя 1024 ядра (я выбрал цифру пострашнее), каждое со своим кэшом. Ты очень аккуратно разделил память, пересечений нет. Каждое ядро начало читать свои данные. И тут на сцену выходит MESI. Обнаружив отсутствие строки с таким адресом в кэше, ядро посылает запрос "хочу читать" эту строку в слой когерентности, который отрабатывается согласно MESI и на который должны прореагировать все соседние ядра:
— Если строки ни у кого нет, возвращается "ничей бычок, товарищ генерал! можете курить!" и ядро идёт читать напрямую из оперативки. (Заодно лочится у себя доступ к ней, пока нет ответа.)
— Если строка у кого-то в Exclusive (не изменённая), она переходит в Shared и посылается ответ — содержимое строки (все 64 байта) с "тоже поставь себе Shared".
— Если строка у кого-то в Modified, отдаётся содержимое строки с пометкой "ты себе тоже поставь Modified, а я уберу из своего кэша".
— Если строка в состоянии "я с ней что-то делаю", запрос тормозится до разрешения ситуации.

Это самая общая схема. Возможны расширения (всякие MOESI, MEFSI и т.п.), на самом деле там авторы процессоров держат десятки состояний и сотни видов сообщений по этой шине с учётом разных тонкостей, так что я описал только самые базовые тупые случаи... но это всё неважно. Важно то, что на каждое такое чтение из памяти вопрос "а что с этой строкой?" с "вот что я собралось с ней делать" бежит через _все_ ядра. Повторяю, все 1023 ядра на каждый такой доступ к памяти должны обработать сообщение, ответить на него и передать дальше (обычно делается кольцевая шина). И вот это — узкое место.

Разумеется, его пытаются лечить сокращением нагрузки. Например, inclusive cache решает, частично, эту проблему. Если есть сводный L3 кэш на камне... пусть эти 1024 ядра были 16 камней по 64 ядра. На запрос от других камней отвечает только L3 кэш, который всё знает, а внутренние запросы уже бегут по своим ядрам. Это сокращает... в основном не плотность потока, но время: количество инстанций, которые должен пройти каждый элемент. (Иногда везёт и соседнее ядро отвечает, так что запрос не выходит за пределы камня; но мы же начали с варианта, когда у каждого своя часть оперативной памяти?) Но следующий уровень — non-uniform memory access (NUMA), при котором уже есть у каждой группы ядер своя память и есть чужая, и точно так же менеджером кэша для чужих областей выступает граничный мост между доменами. Но это уже требует понимания от ОС, какой нити давать какую память и на каких ядрах её размещать. Если нить будет использовать память не той группы ядер, где исполняется — будет медленнее и дороже в разы, чем на памяти своей группы. Где-то может быть и несколько уровней иерархии доменов NUMA (я не видел, но заранее поверю).

Или вот интересный комментарий про SystemZ. Если верить его автору (я не могу проверить), то там может быть вариант, что такого межъядерного обмена — протокола когерентности — нет вообще! Любая команда синхронизации полностью сбрасывает кэши ядра. Влезть впараллель над одним куском памяти — результаты непредсказуемы, нет никаких гарантий, что в память попадут твои изменения. Но при этом пока ядро работает над своими данными — ему никто не мешает. Всей этой дорогой и прожорливой по трафику трахомудии просто нет, запросы идут напрямую в контроллер памяти. Я честно ХЗ, но даже если этого нет — идея красивая. Только вот x86, ARM и прочие не могут себе такого позволить, они уже заложились на гарантию синхронизации (когерентности) кэшей... а она, как описано выше, дорогая и не масштабируемая.

(Вот если бы в Эльбрусе повторили этот "подвиг" — был бы прикол)

V>>Размечать блоки данных, которые локальные для некоего потока, т.е. чтобы была возможность разметить несколько таких блоков в лейауте объекта.
V>>Дальнейшая автоматизация в компиляторе, потом на реальном железе на уровне загрузчика ОС со стандартной коррекцией адресов в процессе загрузки.
S>Было бы интересно посмотреть на пример кода, в котором нужно делать рукопашный лейаут, с бенчмарком "тупого" случая по сравнению с "умным".
S>Ну, и идеи по поводу того, как могла бы выглядеть такая разметка.

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

Здравствуйте, Философ, Вы писали:

Ф> Всё-таки лучше переупорядочивать на этапе компиляции — мне кажется, что тут больше возможностей — тут легче загрузить конвеер(Ы).

Хрен там:

1) Представим себе, что есть команда, которая выполняется 100 тактов. Ну там, согласно гайдам x86 у них деление 128/64 выполняется 90. А все остальные выполняются ну до 10 тактов самая сложная. Параллельная группа команд будет выполняться по времени самой долгой, пока она не закончится — все ждут. Кем жертвовать будем?

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

А в OoO проблем нет: пока одно АЛУ хрустит рукояткой арифмометра "Феликс", вычитая по делителю и затем сдвигая его, остальные команды пролетают мимо, и есть шанс, что можно сделать, что никто никого ждать не будет (в реале, конечно, почти никогда не получается идеально, но думать непродумываемое не приходится).

2) Ещё хуже с доступом к памяти: напоминаю, если строки кэша нет ни в одном из L1, L2, L3, запрос идёт в DRAM, а DRAM модуль должен менять строку — прощайте, 100-200-300 тактов. И снова: вот в параллельной группе все получили данные из кэша, а одна ждёт... и все ждут отстающую.

Тут немножко поможет prefetch. Потому и бенчмарки для Эльбруса стараются показывать на потоковой обработке через SIMD, где это возможно. А на другом коде результаты сразу будут в разы хуже, чем у конкурентов с честным OoO: вечно что-то пропадает из кэша в самый интересный момент, и когда на OoO одна соответствующая команда тормозит, на EPIC тормозит вся группа.

Ф>А ведь мне сама идея VLIW нравилась — что-то в этом есть интересное: суперскалярные архитектуры очень сложные — даже просто понять как работает переупорядочивание сложно, а переименование регистров умножает эту сложность кратно. Спекулятивное исполнение вкупе с BTB — вообще заумь. Не нужно быть семи пядей во лбу чтобы предсказать существование ошибок в этих системах — слишком сложно. И они потом, само собой, нашлись — BranchScope, Spectre.

Это вообще не ошибки. Это естественные побочные эффекты изменения времени работы от кэширования. Кэширование сокращает время — но это сокращение можно увидеть со стороны. EPIC (VLIW) будет страдать тем же, просто нет процессоров, где бы этот эффект измерили.

Я в который раз уже говорю — я не понимаю, почему Эльбрусы не комплектуются SRAM вместо DRAM. Разница в цене для вояк будет пофиг, а хотя бы от чудовищных задержек на переоткрытие строки можно будет избавиться (и соответственно сократить всю машину кэшей памяти).

N>А в чем польза именно "отечественной архитектуры" кроме гордости? Почему не взять открытую во всех отношениях RISC-V и развивать ее?

блльшую част истории Эльбруса risc-v просто не существовал, не?

N>Эльбрус надо было прибить сто лет назад(мы собственно тогда тут на эту тему дрались). Ибо после Итаниума было понятно, что тупик.
вроде как vliw живет на dsp вполне себе, так что вопрос сферы применения

Здравствуйте, Sinclair, Вы писали:

V>>И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.
S>Там нет никаких 2х и 4х. Иначе бы никто не называл это "гипертредингом" и не было бы понятия "честные ядра".

Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.


V>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
S>Как мы в прошлый раз выяснили, в Эльбрусе этих блоков меньше.

В каком из Эльбрусов и меньше чем где?


S>Независимо от наличия или отсутствия упоров.

Эдак тебя заносит. ))

Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?

А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?


V>>На обычных многопоточных, даже независимых по данным.
S>На "обычных многопоточных" данные и так не пересекаются, безо всяких усилий по разметке.

"Страшно далеки они от народа" (С) А. Герцен.


S>Например, при перемножении матриц каждый из потоков работает со своим сегментом матрицы.

Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Это узкий класс задач.

Гораздо чаще в многопотоке различные "агенты" обмениваются инфой через каналы, очереди, флаги, семафоры, future(s)/task(s) и т.д.


S>При сортировке слиянием каждый из потоков сортирует свой сегмент. И так далее.

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


S>Чтобы когерентность начала как-то сильно мешать, надо специально писать многопоточный код так, чтобы потоки наступали друг другу на пятки.

Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))

Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест именно с т.з. доступа к данным из различных потоков.


V>>В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.
S>Это, КМК, очень специальный случай.

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


V>>И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))
S>Или учитывать это при джите

Да согласен.
Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))


V>>Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
S>Возможно, выбор более удачной структуры данных даст ускорение в 3-10 раз и без ручной подгонки линеек кеша.

Ты иногда как с другой стороны Луны.
Имелись ввиду задачи активного обмена данными м/у потоками.

Это весьма интересная тема и я с удовольствием на эту тему поспорил бы, если бы было о чем спорить с оппонентом.
Блин, "более удачные структуры данных"... ))

Не надо вытягивать из меня инфу, хосподя, надо направлять спор, если есть другие или дополняющие собственные наблюдения — именно так происходят предметные обсуждения.
А с 0-ля мне придётся давать слишком много и толку будет ровно ноль всё равно, т.к. мне заведомо не будет толку от этого, а ты через неделю всё равно забудешь подробности, если не занимаешься этим.


V>>Да нет, они в макетах всё неплохо демонстрировали.
S>Макеты Эльбрус-Б? Да ладно!

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

Здравствуйте, netch80, Вы писали:

N>Пусть у тебя 1024 ядра (я выбрал цифру пострашнее)

Да так и есть, страшно. ))

Технически отрасль давно готова выпускать вычислители с таким кол-вом ядер, но SMP/UMA на таком кол-ве ядер потребуют "надстройку" стоимостью дороже целевых блоков.

Вон как в Cell-процах сделано — каждое ядро имеет локальную внутреннюю память 256 kB и несколько векторных сопроцессоров, работающих с этой памятью и сверху аппаратные инструкции работы с внутренней DMA.

С т.з. грамотного проектирования всё сделано правильно...
Но программировать под гетерогенные архитектуры на современных языках — да это застрелиться. ))
Упражнялся я как-то с шейдерами — там эффективность разработки раз в 5 падает в сравнении с разработкой под моногенную архитектуру.

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

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

Причём, проблема не в неспособности такие компиляторы разрабатывать — например, MS легко показала, как разрабатывает компиляторы то С++/CLI, то С++/CX.
Дело в долбоящерах в международных комитетах, которые ревностно следят исключительно за тем, чтобы ни дай бог кто-нибудь случайно не вырвался вперёд остальных.

В итоге, разработка языков программирования в современном мире, по-сути, саботируется.
И некому вздёрнуть вредителей на столбах. ))

Кстате, из-за таких людей как ты, всячески этих вредителей поддерживающих.
Не знаю как сейчас, но лет 10 назад ты был заражён хлореллой то гнутости, то "открытости". ))
А сейчас как?

Здравствуйте, netch80, Вы писали:

N>Тут немножко поможет prefetch. Потому и бенчмарки для Эльбруса стараются показывать на потоковой обработке через SIMD, где это возможно. А на другом коде результаты сразу будут в разы хуже, чем у конкурентов с честным OoO: вечно что-то пропадает из кэша в самый интересный момент, и когда на OoO одна соответствующая команда тормозит, на EPIC тормозит вся группа.

Была сделана ставка на компилятор, что он сможет анализировать сценарии и грамотно раскидывать команды по VLIW.

Здравствуйте, novitk, Вы писали:

N>У меня возникла идея "как оживить VLIW" из серии "станьте ежиками и я занимаюсь только стратегией, не беспокойте меня деталями" — почему бы вместо АОТ, который очевидно в тупике, не скрестить VLIW с каким-нибудь передовыми JIT технологиями типа Profile Guided Optimization.

Это да, но одно "но" — компилятор должен эмулировать целевую архитектуру унутре, а не полагаться на ту, на которой сам исполняется. ))

Здравствуйте, koenig, Вы писали:

K>блльшую част истории Эльбруса risc-v просто не существовал, не?
Был ARM, MIPS и Sparc. Это проверенные работающие решение с развитым стеком стоимостью миллионы задочасов. Собственно китайцы так и поступили для Loongson(MIPS). Импортозаместись, а потом можно и попродвигать архитектуру.

Здравствуйте, vdimas, Вы писали:

N>>У меня возникла идея "как оживить VLIW" из серии "станьте ежиками и я занимаюсь только стратегией, не беспокойте меня деталями" — почему бы вместо АОТ, который очевидно в тупике, не скрестить VLIW с каким-нибудь передовыми JIT технологиями типа Profile Guided Optimization.
V>Это да, но одно "но" — компилятор должен эмулировать целевую архитектуру унутре, а не полагаться на ту, на которой сам исполняется. ))

Не понял. Кодогенератор в jit-ах всегда исполняется на целевой архитектуре, если исключить NUMA сценарии, типа GPU.

Здравствуйте, koenig, Вы писали:

K>вроде как vliw живет на dsp вполне себе, так что вопрос сферы применения
Это не много-целевой процессор и скорее ближе к SIMD. Подход имеет смысл, если код который нужно выполнять и среда исполнения ограничена. Впрочем насколько я знаю сейчас в этой области больше популярны TPU и FPGA.

K>>блльшую част истории Эльбруса risc-v просто не существовал, не?
N>Был ARM, MIPS и Sparc. Это проверенные работающие решение с развитым стеком стоимостью миллионы задочасов. Собственно китайцы так и поступили для Loongson(MIPS). Импортозаместись, а потом можно и попродвигать архитектуру.

А в какой момент? Поначалу это была попытка прорыва. Не потянули. Потом MIPS и SPARC умирали. ARM не так чтобы сильно давно выбрался из эмбеддед в пампасы.
Все это по лицензии (китайцы хотели на хромой козе объехать — но нет, тоже пришлось лицензировать да еще по судам побегать).
У MIPS и Sparc был еще предсмертный релиз в опенсорс. Ну вот у разработчиков Эльбруса Спарки тоже есть, какие к ним претензии — можно обимпортозамещаться.
По мне так стоило попробовать. Ну не получилось, но дело хорошее.

Здравствуйте, koenig, Вы писали:

N>>Был ARM, MIPS и Sparc. Это проверенные работающие решение с развитым стеком стоимостью миллионы задочасов. Собственно китайцы так и поступили для Loongson(MIPS). Импортозаместись, а потом можно и попродвигать архитектуру.
K>А в какой момент? Поначалу это была попытка прорыва. Не потянули.
Какого прорыва? Все что мы обсуждаем было уже сильно после того как VLIW Intel "не потянул", а не наши кулибины без производственной базы.

K>Потом MIPS и SPARC умирали. ARM не так чтобы сильно давно выбрался из эмбеддед в пампасы.
Они потянули не потому, что архитектура там была плохая, а потому что с конкурировать стало запредельно дорого, так как Intel просто выжигал все вокруг ценой и техпроцессом.

K>Все это по лицензии (китайцы хотели на хромой козе объехать — но нет, тоже пришлось лицензировать да еще по судам побегать).
K>У MIPS и Sparc был еще предсмертный релиз в опенсорс. Ну вот у разработчиков Эльбруса Спарки тоже есть, какие к ним претензии — можно обимпортозамещаться.
Дак и АРМ есть(Baikal). И мы даже теперь знаем, что Apple и Qualcomm смогли на этой архитектуре сделать топчик. Вперед, кулибины, копайте!

K>По мне так стоило попробовать. Ну не получилось, но дело хорошее.
Результат был немного предсказуем.

Здравствуйте, flаt, Вы писали:

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

f> PGO?

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

Здравствуйте, karbofos42, Вы писали:

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

k> Объективная реальность, в которой все выпускают отдельные линейки серверных процессоров, а не одно и то же используют в ноутах, десктопах и серверах?

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

k> R>сколько уже тянется история с эльбрусом и его архитектурой? Если верить директору УниПРО(а не верить ему нет никаких причин) тянется она вот уже 50 лет (на канале Бачило есть интервью и с ним). За пол-века можно как-то пошире взглянуть на проблематику, ящитаю.

k> Претензия в итоге в чём? Архитектура в принципе плохая и стоило её давно похоронить?

Стоило. Если не поняли сами, были еще примеры интела и трансметы.

k> Точно я не так интерпретировал? Или может кто-то переобувается на ходу?
k> По-моему было написано, что VLIW уже сдулся и OoO делают, а теперь уже оказывается может быть сольётся, если...

Так VLIW и сдулся, раз они в восьмой версии намерены отойти от развития архитектуры в "традиционном ключе" (с) Трушкин. На чем ты меня подловить пытаешься, я не пойму

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

Относиться к OoO скептически — означает спорить с реальностью

k> Сколько Intel рассказывала о светлом будущем Itanium? И что в итоге?

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

k> А вот, например, заблуждения Стива Джобса: https://habr.com/ru/articles/395345/
k> ыыыыы. тупые в интелах и эпплах. Вот так ирония. Никто никогда не ошибался.

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

k> Если сразу всё идеально не сделали, значит плохие специалисты или что проблемы не решаются в принципе?

В этой архитектуре не решаются. Неужели все еще не понятно?

k> Внезапно оказалось, что они решали задачи заказчиков, оплачивающих их работу, а не бизнеса, который воротил нос и говорил, что интелы лучше и дешевле.

Ну так интелы и лучше и дешевле. Это факт

k> Ну, теперь и до них очередь дошла. А бизнес внезапно в большинстве своём сидит на всяких Java, C# и интерпретируемых языках, которые не очень хорошо ложатся на Эльбрусы.
k> Будет Эльбрус развиваться — вероятно улучшат слабые места, которые раньше не были так важны и критичны.

Вероятно улучшат. Когда OoO добавят Или, как предлагает Шигорин, пойдут по пути отказа от "скриптов" в пользу компилируемых програм (разумеется нет).

k> Ну, мы имеем факт, что другой отечественной архитектуры сегодня нет.

А нужна именно отечественная?

k> Вот как-то так получилось, что "неэффективная дичь" существует, а эффективное никто не сделал.

Делают на пятом риске. У него, говорят, с производительностью "скриптов" все в порядке.

k> Про субсидии ты как всегда пруфы не приводишь, что-то из головы выдаёшь.

Тут мой косяк, спутал с претензиями минпромторга к ИНЭУМ, у которых не сложилось с поставками серверов на эльбрусах. Виноват.

Здравствуйте, novitk, Вы писали:

N>Не понял. Кодогенератор в jit-ах всегда исполняется на целевой архитектуре, если исключить NUMA сценарии, типа GPU.

Ну а я про кросс-компиляцию.

Здравствуйте, vdimas, Вы писали:
V>Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.
Это бессмысленные цифры. Интересует не количество потоков, а производительность.

V>>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
S>>Как мы в прошлый раз выяснили, в Эльбрусе этих блоков меньше.

V>В каком из Эльбрусов и меньше чем где?
В любом реализованном меньше чем в любом современном Интеле.
Напомню, что Интел ставит 2 FMA модуля на ядро. То есть за 1 такт ядро может выполнить 16 64-разрядных арифметических операций.
На фоне этого 6 АЛУ на ядро как-то не смотрятся.

V>Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?
В любом. Вещественные-то поди 32 бита? Таких операций интел может сделать 32.
И это — про простые гражданские копеешные AVX2. Если мы возьмём топовый пень с AVX512, то сравнение станет совсем нечестным.

V>А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
Размер вектора какой? Кстати, почему-то в руководстве о векторности АЛУ нет ни слова. Сколько и каких значений складывает команда adds?

V>Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Всё верно. Как и на обычном суперскаляре.

V>Опять плохой пример — размер массива должен быть чудовищным, чтобы выбор сортировки слиянием был оправдан.
Надо будет замерить как-нибудь.

V>Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))
Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java. И для этого не пришлось ни ломать JIT, ни переписывать компилятор, ни раскладывать данные по линейкам кеша.

V>Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест именно с т.з. доступа к данным из различных потоков.
Понятно, что можно криво написать софт. Непонятно, что тут может бать Бабаяновское железо.

V>Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками.
Пример LMAX Disruptor показывает, что не всегда.

V>Да согласен.
V>Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))
Ну, так что сдерживает-то? Сказки про комитеты, которые запрещают вам ковыряться в носу, рассказывать не надо. Простой вариант: берём дотнет, изобретаем набор атрибутов для лэйаута, делаем свой компайл-тайм-генератор типов
с выровненными по кэшу данными. Работы на один вечер.
Если не знаем, на чём будет исполняться код — переносим генератор в рантайм. Работы на два вечера.
Или берём clang, llvm, и делаем то же самое прямо в кодогенераторе. Работы на пару недель.

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

V>Имелись ввиду задачи активного обмена данными м/у потоками.
Для начала нужно понять, зачем вообще потребовался активный обмен данными между потоками. Может, там надо по-другому работу распределить?

V>Блин, "более удачные структуры данных"... ))
А то.

V>E2k в макетах сначала показали в 90-е (это все последующие микропроцессорные Эльбрусы которые).
Речь в топике про Эльбрус-Б. Эль-22, напомню, к E2K никакого отношения не имеет.

Здравствуйте, netch80, Вы писали:

Ф>> Всё-таки лучше переупорядочивать на этапе компиляции — мне кажется, что тут больше возможностей — тут легче загрузить конвеер(Ы).

N>Хрен там:

N>1) Представим себе, что есть команда, которая выполняется 100 тактов. Ну там, согласно гайдам x86 у них деление 128/64 выполняется 90. А все остальные выполняются ну до 10 тактов самая сложная. Параллельная группа команд будет выполняться по времени самой долгой, пока она не закончится — все ждут. Кем жертвовать будем?

Не вижу проблемы: любая группа команда, при любом подходе в конечном счёте упрётся в зависимость по регистрам или зависимость по данным — тут не важно, аппаратный это OoO, компиляторные ли перестановки, или ты руками что-то переставлял. Если что, то я, как прилежный ученик, так делал учебные примеры из книжки "Оптимизация для процессора Pentium" — переставлял команды руками, и для того чтобы развязать зависимость по данным и/или регистрам, и для того чтобы одновременно нагрузить u и v конвейеры. Точно говорю — в простых случаях это возможно даже руками. Но если распространить этото подход на действительно обширный участок кода, то а) руками никак — за гранью человеческих возможностей б) всё равно упрёшься в зависимости

N>Тут немножко поможет prefetch. Потому и бенчмарки для Эльбруса стараются показывать на потоковой обработке через SIMD

Префетч помогает (не немножечко), и точно не поэтому стараются: префетч и симд про разное.

N>Это вообще не ошибки. Это естественные побочные эффекты изменения времени работы от кэширования. Кэширование сокращает время — но это сокращение можно увидеть со стороны...

Да, насчёт Spectre ты прав — я проверил. Неправильно представлял, как это работает.