Rust для Эльбруса?

Если через двоичную трансляцию, то там обычный x86.

Если без, то llvm для этой архитектуры не работает пока.

С другой стороны, Firefox же как-то собрали.

А у двоичной трансляции какая потеря в скорости от идеала? Хотя бы грубую оценку.

так пока только старый firefox собрали: https://imgur.com/a/Dpwg1vP он без раста

Rust became a requirement for building Gecko in February 2017 with Firefox 54

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

Причём там проблема в том, как измерять эту производительность. Разные архитектуры по разному справляются с разными задачами. Поэтому некоторые задачи Эльбрус решает быстрее аналогичной задачи под x86, некоторые сильно медленнее, и с чем сравнивать?

А, вот оно что.

Ну, ладно! С этим более-менее понятно. А стандарт С++ какой там поддерживается в родном lcc? Слышал про C++11 с элементами С++14/С++17. Более предметно, decltype есть? Выводить тип результата метода или функции через ключевое слово auto умеет?

Тут тебе лучше поговорить с Шигориным на форуме Альта, в рассылке или на опеннете. Я не разработчик, я преподаватель.

Спасибо за ответы!

Так у тебя есть ещё доступ к нему? Если есть желание, можно было бы Hello World собрать

Ну и нафиг тогда это проприетарное поделие. Или есть сферы, где их заставляют использовать? Если госсектор, то прямо говорить: «Производитель процессора запрещает запускать данную программу на нём» и слать лесом.

Сейчас уже нет, но даже если будет ещё проект - я там работу работаю, а не балуюсь 😊

Эльбрус-801 есть в музее Яндекса, попробуй, если в Москве.

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

https://m.youtube.com/channel/UC6pnRoVljXKpo5bgkVyQMJg

На этом канале есть видео с ответами на многие подобные вопросы.
Смотри «Yandex day».

Как я понимаю, llvm не рассчитан на такую архитектуру.

LLVM туда как раз адаптируют. Но вообще да, LLVM плохо подходит для VLIW. Хотя какие-то подвижки в сторону VLIW были https://stackoverflow.com/questions/4166176/llvm-compiler-infrastructure-for-...

Раз уж упомянули VLIW, почему помер Itanium? У этого подхода проблемы? Я если что не шарю в нюансах

Itanium Хотел усидеть на двух стульях + легси. Ты же адепт говнораста и должен верить в легаси и его силу.

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

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

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

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

По поводу проблем. Из таких более-менее понятных - это непредсказуемость задержек при работе с памятью(и не только) и как следствие невозможно всё это зашедулить статически. Это решается и решения вполне доступны. Но это проблема не уникальна для влива - она есть везде просто проявляется не так явно.

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

почему помер Itanium? У этого подхода проблемы? ИМХО без разницы какая там была архитектура, он помер потому что корпорации были не готовы мигрировать на не совместимую с x86 архитектуру. Исполнение x86 на Itanium было фиговым по производительности, а еще это времена проприетарных юниксов, и crud написаных на сях.

Мне однажды довелось портировать сишную программу (процессинг данных в бд) на жабу в подобной «корпорации», доков нету, тестов тоже, тот кто писал давно ушел, написано все на СИ с классами, а сишников не осталось. Вопрос портирования поднялся из-за переезда с ia32 Solaris на x86-64 Linux, пришлось пересобрать под x86-64, вроде работает, но тестов нету! Гарантий того что математика из-за перекомпиляции с ia32 на x86-64 считает как раньше нету, потому тестировал все вручную, а потом все переписали на жабу. Конечно переезд много времени не занял так как 95% всего уже было на жабе, а теперь представь что у тебя на серверах 50% всего написано на сях, никаких gcc/clang а сплошь проприетарные компиляторы, причем для каждой архитекутры свой комплиятор и каждый со своими заморочками.

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

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

И эти потоки/пути независимы. Таким образом, когда у тебя есть десяток потоков - один из них можно стопнуть, а другие исполнять. Тут ты можешь попытаться осознать фундаментальную проблему. Все эти пути нужно где-то хранить. А значит, если у тебя есть 10 потоков/путей 5 из которых исполняются, а пять ждут - у тебя проблемы. У тебя кончатся инструкции в этих 5 потоках/путей, но их нужно откуда-то взять, но взять ты их не сможешь(почти всегда).

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

Что такое влив? Это явный параллелизм. Но тут проблема - у тебя все эти потоки/пути исполнения находятся в рамках одного потока инструкций. А значит они зависимы, в отличии от суперскаляра - где эти потоки независимы(пусть и в рамках некоего узкого окна).

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

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

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

Но дело в том, что интел - говно. х86 - говно. Для SMT и загрузки суперскаялра - нужно как можно быстрее читать все эти потоки инструкций. Но что мы имеем в мусорном х86? Мусорный слабый фронтенд, который имеет адскую летенси и производительность. Именно поэтому в нормальных суперскалярах(которые должны быть обязательно рисками) фронт может читать десятки потоков и десятки инструкций в такт.

Интел там уже 10 лет пердит над фронтом обещая его улучшить. Но он как был говном так и остался и это никак не исправить.

Таким образом всё, что даёт суперскаляр говнокоду - это некое окно, которое может спасти это говно. Во всём остальном - это мусор.

Раз уж упомянули VLIW, почему помер Itanium?

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

Про особенности VLIW подхода думаю alexanius лучше меня может рассказать.

На мой взгляд, основная причина в том, что он не был обратно совместим с x86 софтом. Да, но не только. Интел пытался сделать итаник совместимым и понятным, но именно это его и погубило. Совместимости быть не может полноценной, но дело даже не в этом. Они не пытались объяснить людям и ЦА того, что даст смена шила на мыло. Совместимость и примитивность - не дали производительность, а попытка поехать в сторону фп-вычислений обломилась об видяшки, которые были и дешевле и обладали нормальной архитектурой. И так же нвидия каждую секунду занимается тем, что рассказывает и показывает то, зачем вам нужно купить очередную теслу. Интел такого не показал.

Да и эльбрус этим не занимается. Хотя они есть какие-то попытки похайпить на безопасности.

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

Проблема в том - где именно взять эту параллельность. Путей исполнения в рядовом говнокоде мало. И решений несколько. Развивать SMT, либо развивать говнокод. Ни того ни другого не делается.

Я, если честно, не очень понял на какой именно вопрос отвечать. Если про Itanium, то я глубоко в эту тему не копал, но у них там масса проблем было, причём далеко не технического характера.

На сколько я знаю, они сильно продолбались со сроками, не обеспечили нормального маркетинга, а там ещё и амд подогнал amd64.

Вопрос про особенности VLIW архитектур. Вот например в VLIW простейшие инструкции образуют некие блоки, и компилятор в этот блок должен напихать инструкций, чтобы они не конфликтовали между собой, и чтобы все АЛУ задействовать без конфликтов, учитывая зависимости по данным. Я слышал мнение, что под VLIW намного сложней делать компиляторы, чем под обычные CISC, RISC архитектуры, где просто пачки инструкций идут.

Информация по системе команд Эльбрусов отсутствует в свободном доступе, поэтому далее будут допущения. Допустим, есть 4 АЛУ и в ШК можно за условный такт обработать 4 инструкции, разбросав их по АЛУ. Попробуем например сложить регистры от R0 до R7:

{

//---
R0 = R0 + R1  // АЛУ1 делает это
R2 = R2 + R3  // АЛУ2 делает это
R4 = R4 + R5  // АЛУ3 делает это
R6 = R6 + R7  // АЛУ4 делает это
//---
 
//---
R0 = R0 + R2  // АЛУ1 делает это
R4 = R4 + R6  // АЛУ2 делает это
NOP           // АЛУ3 простаивает
NOP           // АЛУ4 простаивает
//---

//---
R0 = R0 + R4
NOP
NOP
NOP
//---
}

Вопрос про особенности VLIW архитектуру. Вот например в VLIW простейшие инструкции образуют некие блоки, и компилятор в этот блок должен напихать инструкций, чтобы они не конфликтовали между собой, и чтобы все АЛУ задействовать без конфликтов, учитывая зависимости по данным. Я слышал мнение, что под VLIW намного сложней делать компиляторы, чем под обычные CISC, RISC архитектуры, где просто пачки инструкций идут.

Да

Например, общие ли регистры для всех АЛУ в процессе исполнения?

Да, общие

Сложно ли это все планировать (ощутимо ли дольше компиляция в сравнении более привычными архитектурами)?

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

Что насчет JIT, где время компиляции критично?

Тут всё сложно. Строго говоря, какие-то JIT'ы реализованы (например Java, JS), но их эффективность далека от идеала. Там ещё поле непаханное работы.

Да

Не совсем. Всё это так же актуально и для суперскаляров.

Очень.

Нет.

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

Проблема в малой параллельности говнокода - всё остальные проблемы - не проблемы. Ковейеризация/векторизация циклов - это именно что проблема поиска параллельности в говнокоде, ведь даже если она там есть - она скрытая. Эта проблема так же актуальна и для суперскаляров - они так же конвейеризированы. Хотя упомянутое выше алу у штеуда итак обладает минимальной летенси и конвейеризация ему ненужна.

В любом случае всё это актуально для любого процессора и является задачей поиска параллельности в говнокоде. Это не задача планирования.

Тут всё сложно. Строго говоря, какие-то JIT’ы реализованы (например Java, JS), но их эффективность далека от идеала. Там ещё поле непаханное работы.

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

Главное что аноним лучше всё знает

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

Ты лучше попытайся что-то ответить. Почему вы так яро отрицаете всё, что вам неудобно и не соотносится с вашей методичкой? Хотя я сомневаюсь, что какой-либо мой тезис отрицает базовую методичку.

Ты мне лучше вот что скажи. У вас, союзников, какая-либо коммуникация/источник ваших познаний есть?

Очень.

Нет.

Очевидно, что знаю.

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

Не совсем. Всё это так же актуально и для суперскаляров.

Актуально - да. Тем не менее из-за OoO в компиляторах планирование/перестановка не так развиты.

Проблема в малой параллельности говнокода - всё остальные проблемы - не проблемы.

Все остальные проблемы - такие же проблемы. Как кривой C/C++/Java/подставить_абсолютно_любой_язык, так и говнокод, выраженный далеко не только отсутствием параллельности.

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

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

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

Хотя упомянутое выше алу у штеуда итак обладает минимальной летенси и конвейеризация ему ненужна.

Не очень понял что здесь имелось ввиду.

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

Я сейчас говорю про программную конвейеризацию (softpipe), и они её применяют реже и по-другому.

Да и называть меня анонимом.

Я где-то ошибся?

Ты лучше попытайся что-то ответить. Почему вы так яро отрицаете всё, что вам неудобно и не соотносится с вашей методичкой? Хотя я сомневаюсь, что какой-либо мой тезис отрицает базовую методичку.

Ох, как запущено то всё

да и производительности от недоязычков никто не ждёт.

Пользователи firefox и Java на Эльбрусах с интересом выслушают почему

Ты мне лучше вот что скажи. У вас, союзников, какая-либо коммуникация/источник ваших познаний есть?

Я не знаю про каких союзников и какие коммуникации идёт речь. Когда меня спрашивают - я рассказываю. Есть книга по Эльбрусам, можно отслеживать публикации МЦСТ'шные, можно искать публикации организаций, связанных с ними. Из последнего - видео с Яндекс дней опубликовали, там много интересного

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

Нет. Это не так.

Актуально - да. Тем не менее из-за OoO в компиляторах планирование/перестановка не так развиты.

Это всё не так сложно. Попросту нету спроса, да и нету источника. Основная проблема в источнике - что ты там собрался платнировать, если у тебя в коде 1-2 пути? Рассовывание по таймингам? Это так не не проблема.

Все остальные проблемы - такие же проблемы. Как кривой C/C++/Java/подставить_абсолютно_любой_язык, так и говнокод, выраженный далеко не только отсутствием параллельности.

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

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

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

Это я ещё не говорю про то как работу компилятора усложняют предикатные регистры и if-conversion.

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

И опять же - if - это именно говнокод в 90% случаях. Это относится к тем двум проблемам, что я назвал. Хотя проблема одна - это нулевая культура программирования.

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

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

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

Не очень понял что здесь имелось ввиду.

Алу штеуда обладает минимальной летенси. Т.е. цикл вида inc %r;mov %r, mem у штеуда не почти не нуждается в конвейризации. Если же летенси интеркмента больше минимальной, то конвейриризация вида mov %r, %r1; add $1, %r1; add $2, %r; mod %r1, mem; mov %r, mem; уже нужна.

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

Я сейчас говорю про программную конвейеризацию (softpipe), и они её применяют реже и по-другому.

Они её применяют так же и по этой же причине. К тому же, софтварная конвейеризация нужна именно потому, что есть хардварная/параллелизм.

Я где-то ошибся?

Да.

Ох, как запущено то всё

Очередная нелепая потуга.

firefox

Нелепый мусор.

Java

Ещё один мусор.

на Эльбрусах с интересом выслушают почему

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

Я не знаю про каких союзников и какие коммуникации идёт речь. Когда меня спрашивают - я рассказываю. Есть книга по Эльбрусам, можно отслеживать публикации МЦСТ’шные, можно искать публикации организаций, связанных с ними. Из последнего - видео с Яндекс дней опубликовали, там много интересного

Ну ты же не один. Есть другие твои союзники. Кто-то этим занимается, кто-то что-то должен понимать? Где они все? Кто занимает компилятором, теорией, софтом? Не на галерных позициях. Или с этим всё плохо?

Вообщем, почитал я это книгу. Она совсем для птушников, но что можно выяснить.

Это некая вариация циска, т.е. та же древняя мотивация на которую купились многие и которая погубила многих. Теперь понятно почему и с чем у них там проблемы. Они наделали всяких хардварных реализация всякого говна, которые не работают и работать не будут. И получилось то, что получилось с х86. Миллионы реализация, на которые забили все компиляторы, а даже если бы не забили - они обречены.

И теперь они пытаются всё это впихнуть в этих рудименты древности, но ничего не получается, очевидно. И не получится.

Но некоторые фичи мне нравятся, допустим: Функции могут и имеют отдельный набор регистров. Таким образом стек вызовов организуется путём переименования регистров. Если проще, то у нас есть 100 регистров. Функции доступно, допустим, 10. Первой функции достанется r0 … r9, который замапируются на r0 … r9, второй r0… r9, которые замапируются на r10 .. r19 и так далее. В целом похожи принцип используется для кешей в видяшках. Так же, насколько я понял - оно может дампить предыдущие регистры в память, если файл закончился. И далее при выхода и вызова их прозрачно подгружать.

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

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

И тут опять мы выходим на фундаментальную проблему, которая и погубила итаник. Когда ты ни рыба ни мясо - толку с тебя? Показать преимущество влива оно не может - оно слишком слабо. Соревноваться с суперскаляром в исполнении динамического дерьма - оно так же не может. Он слишком слабо.

И не могу понять мотивацию людей. Ведь вижу я только один путь. Работать над культурой программирования и показать путь решения проблем, который всё равно необходим. Рано или поздно суперскалярное дерьмо упрётся в потолок, хотя оно уже во много упёрлось. Особенно в ситуации, когда можно организовать производство полного цикла.

Уровень параллелизма - там никакующий судя по докам. Все эти маня-25 инструкций - это с учётом симдов. Хотя, вроде как, мы это обсуждали. Т.е. реальный уровень параллелизма - там десяток. Как у бека интела.

К чему и зачем всё это идёт? Может ты мне сможешь объяснить? Хотя вроде я уже задавал этот вопрос.

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

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

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

Нет. Это не так.

Ну нет - так нет.

Актуально - да. Тем не менее из-за OoO в компиляторах планирование/перестановка не так развиты.

Это всё не так сложно. Попросту нету спроса, да и нету источника. Основная проблема в источнике - что ты там собрался платнировать, если у тебя в коде 1-2 пути? Рассовывание по таймингам? Это так не не проблема.

А сложность не только в путях. Во-первых правила планирования сложны сами по себе. Нужно выдерживать задержки, учитывать вычислительные кластеры АЛУ, понимать где и как расставлять работу с памятью, оптимально делать spill/fill. Это так, на вершине айсберга. Внутри - это функциональность, разнесённая в несколько фаз, между которыми ещё сотня оптимизационыых фаз пройти может.

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

Ну ок

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

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

Я не знаю что на это ответить. Но мне всё же интересно где и сколько ты работал с компиляторами, что конкретно делал

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

В этом случае как раз нет. Тупо выносишь инварианты. Либо ставишь предикаты. Есть ещё несколько более хитрых вещей в зависимости от конкретной ситуации

И опять же - if - это именно говнокод в 90% случаях. Это относится к тем двум проблемам, что я назвал. Хотя проблема одна - это нулевая культура программирования.

Это объективная реальность, в которой мы живём. Надо с этим как-то работать

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

В суперскаларях нет 32 предикатных регистров и такой активной работы по слиянию кода

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

А мне, вот рыдать хочется. Но «поиск параллельности» - это большое семейство очень разных алгоритмов. Даже inline в каком-то смысле на это влияет (на самом деле одна из основных оптимизаций вообще).

Алу штеуда обладает минимальной летенси. Т.е. цикл вида inc %r;mov %r, mem у штеуда не почти не нуждается в конвейризации. Если же летенси интеркмента больше минимальной, то конвейриризация вида mov %r, %r1; add $1, %r1; add $2, %r; mod %r1, mem; mov %r, mem; уже нужна.

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

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

Я про компилятор и говорю

Они её применяют так же и по этой же причине. К тому же, софтварная конвейеризация нужна именно потому, что есть хардварная/параллелизм.

Я где-то ошибся?

Да.

Ну да, мог бы и сразу догадаться.

firefox

Нелепый мусор.

Java

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

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

Ну ты же не один. Есть другие твои союзники. Кто-то этим занимается, кто-то что-то должен понимать? Где они все? Кто занимает компилятором, теорией, софтом? Не на галерных позициях. Или с этим всё плохо?

Нет, у нас все с галеры (хотя я в интернетах не так много гребцов знаю), так что да, всё плохо. Те кто не с галеры - я хз что там и как, думаю все сами по себе

Все эти маня-25 инструкций - это с учётом симдов.

Нет, тут объяснение https://youtu.be/ZTxOSGBCRec?t=1265.

А сложность не только в путях. Во-первых правила планирования сложны сами по себе. Нужно выдерживать задержки, учитывать вычислительные кластеры АЛУ, понимать где и как расставлять работу с памятью, оптимально делать spill/fill. Это так, на вершине айсберга. Внутри - это функциональность, разнесённая в несколько фаз, между которыми ещё сотня оптимизационыых фаз пройти может.

Эти правила примитивные. Хотя полистав книгу - я теперь, частично, понимаю с чем там у вас проблемы. У вас проблемы не с планированием, а с использованием собственных фич. Косвенно ты это сам подтвердил.

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

Я не знаю что на это ответить. Но мне всё же интересно где и сколько ты работал с компиляторами, что конкретно делал

Что за нелепые попытки съехать с темы?

В этом случае как раз нет. Тупо выносишь инварианты. Либо ставишь предикаты. Есть ещё несколько более хитрых вещей в зависимости от конкретной ситуации

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

Банальный кейс. if(mem[x]) it += 2; else it += 1; Очевидно, что нормальный человек напишет it += (1 + !!mem[x]);, но дело не в этом. Воспринимай это просто за it += mem[x], либо просто it += x, если x вычисляется произвольно.

Это уже итеративный алгоритм - который ставит всё раком. Но даже если о не итеративный, то любой сплит в вычислении it - уже ломается твою конвейериризацию. И никакое параллельное исполнение веток и прочее - тебе не помогут.

Это объективная реальность, в которой мы живём. Надо с этим как-то работать

Ты не сможешь с этим работать, но что-то попытаться исправить ты можешь. Эльбрус и вся эта тема аффилирована с запартой. Учи. Демонстрируй людям профит.

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

Как минимум ты будешь иметь хорошее академическое применение.

В суперскаларях нет 32 предикатных регистров и такой активной работы по слиянию кода

Сколько их там - это мало о чём говорит. Работы современные компиляторы делают не мало. Хотя почему «компиляторы» - он существует только один.

К чему и зачем всё это идёт? Может ты мне сможешь объяснить? Хотя вроде я уже задавал этот вопрос.

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

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

А мне, вот рыдать хочется. Но «поиск параллельности» - это большое семейство очень разных алгоритмов. Даже inline в каком-то смысле на это влияет (на самом деле одна из основных оптимизаций вообще).

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

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

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

Я не понял ответа. Я отвечал на вопрос про штеуд.

Я про компилятор и говорю

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

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

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

Нет, у нас все с галеры (хотя я в интернетах не так много гребцов знаю), так что да, всё плохо. Те кто не с галеры - я хз что там и как, думаю все сами по себе

Ну это плохо.

Ну да, 4 + двойные аргументы какие-то. Я не совсем понял что имеет ввиду, но судя по всему - симды. Далее для fp он уже заговорил про 8 операций - 8fma это максимум 4 инструкции. Опять же, есть ли там симды? Потому как это могут быть 2 инструкции.

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

А далее он там ещё с каких-то левых бекграунд процессов набрал операции.

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

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

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

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

Я всем говорю: если душа так болит за своё родное, и хочется сделать максимально хорошо - приходи на галеру, бери весло, греби.

Толку мне идти на галеру и делать хорошо, если это никому ненужно? Что я там буду делать? Заниматься тупиковой хернёй?

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

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

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

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

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

Купить - сейчас нет. Доступ - если есть доступ к Яндекс музею, то можно там. Можно удалёнку через МЦСТ, но тут мороки много - вплоть до письма с печатью организации и целями исследования.

Ещё машины есть в нескольких ВУЗах, возможно там удастся договориться.

92 страница книги

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

В 4С и более старых, 4 канала могут выполнять fma + 2 канала свободны, 10 операций (из них 8 fp) + все остальные, итого 23.

В 8С/1С+ все каналы могут выполнять fma, 12 операций + все остальные, итого 25.

В 8СВ расширили регистры до 128 бит, 24 fp64 fma операции + все остальные, итого 37 операций.

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

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

«Производитель процессора запрещает запускать данную программу на нём» и слать лесом.

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

В 4С и более старых, 4 канала могут выполнять fma + 2 канала свободны, 10 операций (из них 8 fp) + все остальные, итого 23.

Это полная херня. нахрена ты считаешь какие-то мусорные нелепые операции. Их считать ненужно - считаются инструкции, либо отдельные операции. Таким образом реально у тебя, получается, 6 инструкций?

В 8С/1С+ все каналы могут выполнять fma, 12 операций + все остальные, итого 25.

Все это какие? Судя по всему «все» - это 6. И того 6 инструкций за такт.

В 8СВ расширили регистры до 128 бит, 24 fp64 fma операции + все остальные, итого 37 операций.

Зачем вы несёте эту херню нелепую? Я не понимаю. Штеуд - 2 fma, ширина вектора 512 бит, либо 32 fp64 операции. Плюс к тому же, ещё 32 операции загрузки, 16 записи, 8 операций над 64 битными интами. И того почти сотня операций за такт. Бек пятилетней давности пол сотни.

Зачем считать как идиотам? Это ведь не в твою пользу. Считай как человек. Твоё преимущество архитектурное - это возможная независимость отдельных операций. У штеуда вся производительность fpешная в fma и симдах. Зачем ты начинаешь идти туда, где дыра?

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

Вот и выросло поколение, которое считает, что процессоры должны делать для программ…

Для «поколения x86» это комплимент.

а есть какие-нибудь обоснования реально использовать rust для разработки firefox? ну кроме того, что это чисто их поделие

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

Вот интересно, что они боятся? Ну понимаю, nvidia закрывает спецификации, чтобы не склонировали. А Эльбрус ведь в роли догоняющего. Что там копировать?

Это полная херня. нахрена ты считаешь какие-то мусорные нелепые операции. Их считать ненужно - считаются инструкции, либо отдельные операции. Таким образом реально у тебя, получается, 6 инструкций?

Считают операции, иначе в CISC/VLIW/SIMD нельзя нормально оценить производительность. Я не знаю откуда ты взял 25 инструкций, но это неверная информация, всегда говорят за операции.

Все это какие? Судя по всему «все» - это 6. И того 6 инструкций за такт.

На видео же всё объяснили.

Эльбрус-8С.

• 6 a * b + c, 12 операций
• 4 адресной арифметики
• 4 чтения/записи из AAU
• 3 операции над предикатами
• 1 обработка счётчика цикла
• 1 передача управления
• итого 25 операций.

Coffee Lake.

• 3 a * b + c, 6 операций
• 1 целочисленная операций
• 2 адресной арифметики
• 2 чтения
• 2 записи
• 1 передача управления
• итого 14 операций.

Всё вышеперечисленное справедливо для циклов с скалярными вычислениями. Если же замерять с SIMD, то тут всё зависит от ширины вектора, разумеется у Intel тут огромное преимущество с AVX512.

Зачем вы несёте эту херню нелепую? Я не понимаю. Штеуд - 2 fma, ширина вектора 512 бит, либо 32 fp64 операции. Плюс к тому же, ещё 32 операции загрузки, 16 записи, 8 операций над 64 битными интами. И того почти сотня операций за такт. Бек пятилетней давности пол сотни.

Я это написал как демонстрацию, что бы было если бы считал операции с векторами, т.к. ты не можешь понять разницу между FMA и SIMD.

В частности, для разработчиков.

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

А Эльбрус ведь в роли догоняющего.

Вообще-то совсем нет.

Что там копировать?

lcc. Именно у него внутри то, что у x86 в камне.

Coffee Lake.

Я ошибся это для будущих Sunny Cove.