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

А что такое «средняя производительность ядер среди вообще всех ядер»? Как она считается? Я просто не понимаю концепт и смысл высказывания соответственно.

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

У Syntacore были такие намерения как минимум на бумаге. У МЦСТ - непонятно, они вообще заявляют иногда противоречащие друг другу вещи.

и все побежали собирать)

как была пропасть между разработчиком железа и бизнесом, так и осталась.

маргинальщина и патриотизм.

А что такое «средняя производительность ядер среди вообще всех ядер»? Как она считается?

Берём все вообще когда-либо произведённые процессорные ядра, в которых было OoO. Суммируем их производительность с весами, равными числу произведённых ядер. Делим на общее число произведённых ядер. Получаем среднюю производительность.

Пример. Допустим, ядер было всего два вида. Ядро А имело производительность 2 попугая, ядро Б имело производительность 5 попугаев. Ядер вида А за всё время было выпущено 99 штук, а ядер типа Б — одна штука. Средняя производительность ядер составит (99×2 + 1×5)/(99 + 1) = 2,03 попугая.

Берём все вообще когда-либо произведённые процессорные ядра, в которых было OoO

Ээээ… а…. а зачем?

а зачем?

Чтобы посчитать среднее. Ты же решил сравнивать со средним.

Чтобы посчитать среднее. Ты же решил сравнивать со средним.

Где? Я говорил «и все равно не достигнуть средней эффективности суперскаляра с OoO» - ничего про сравнение со средней производительностью не было.

Производительность можно померить. Как ты померишь эффективность, не сведя измерение к измерению производительности?

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

им надо мыло ещё добавить в ассортимент.

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

Однако это понемногу делает даже Интел (не говоря уже о HP, IBM…)

https://habr.com/ru/company/itsumma/news/t/651277/

Производительность можно померить. Как ты померишь эффективность, не сведя измерение к измерению производительности?

Это не является ответом на мой вопрос. Давайте я его повторю:

Чтобы посчитать среднее. Ты же решил сравнивать со средним.

Где? Я говорил «и все равно не достигнуть средней эффективности суперскаляра с OoO» - ничего про сравнение со средней производительностью не было.

и все равно не достигнуть средней эффективности суперскаляра с OoO

Окей, и как ты узнаешь, достигло нечто средней эффективности суперскаляра или нет? Как выглядит функция истинности?

Окей, и как ты узнаешь, достигло нечто средней эффективности суперскаляра или нет? Как выглядит функция истинности?

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

Можно сделать честное сравнение всех моделей и определить нечто среднее.

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

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

И что тогда за результат получится?

Допустим, нужно оценить эффективность работы учителя. Оценивать будем по «среднему» баллу на экзамене. Учитель помог 99 ученикам получить на итоговом экзамене пятёрку, но один ученик получил единицу. «Средний» балл составил 3. Плохой учитель.

И что тогда за результат получится?

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

Допустим, нужно оценить эффективность работы учителя. Оценивать будем по «среднему» баллу на экзамене. Учитель помог 99 ученикам получить на итоговом экзамене пятёрку, но один ученик получил единицу. «Средний» балл составил 3. Плохой учитель.

У тебя ошибка в составлении аналогии.

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

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

То есть если ты хочешь на аналогии объяснить свою идею, должно быть так:

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

Надеюсь так понятнее?

средней эффективности суперскаляра

Куда-то вы с этими обсуждениями не туда забрались.
Выбираете набор ворклоадов, на которых интересно что-то замерять, выбираете метрику(power, ipc и тд), замеряете, делаете выводы. Еще не стоит забывать про потребление, размер кристалла и максимальные частоты, когда производите оценку.

Я думаю, [user]free-e2k[/user] в своем тейке про средний ООО суперскаляр имеет ввиду такой, который условно реально сделать если не на коленке, то на инженерной коленке.

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

У тебя ошибка в составлении аналогии.

И критерий определения ошибочности или правильности состоит в том, что?

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

Надеюсь так понятнее?

Нет. За всё обсуждение я даже не увидел определение термина «эффективность».

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

Достаточно ли существования ядра в виде FPGA-версии для участия в усреднении? Если да, то можно сделать кучу вариаций такого однотактного широкого процессора с автоматически генерированными ISA. Они ведь будут разными? Команды точно разные. Так можно средний IPC архитектур притянуть до 5. Но получится бред.

Так что нет, непонятно, что ты имеешь в виду.

делали такие ядра, которые по ipc обходят решения от интела

Мне бы очень хотелось посмотреть на сравнения производительности ядер Apple, изменённых для поддержки нескольких сменных модулей DDR4, и текущего подхода с приваренной памятью. И ещё было бы интересно глянуть на производительность SoC с приваренной памятью и ядрами от Intel.

Справедливое наблюдение, да. Но по ipc эппл обошел интел еще с телефонными чипами году так в 2018. Может, смогу найти не внутреннюю презенташку.

Можно ли сравнивать IPC на x86 и ARM один к одному?

Вернее, не так. Сравнивать-то можно. Скажем так: одни и те же задачи выполняются на x86 и ARM за одно и то же число инструкций?

Если сделать процессор, который выбирает по пять команд за такт и сразу же их исполняет, всегда по пять штук, у него IPC будет 5. Частоты будут никакими, но зато IPC = 5

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

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

Скажем так: одни и те же задачи выполняются на x86 и ARM за одно и то же число инструкций?

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

И критерий определения ошибочности или правильности состоит в том, что?

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

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

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

Но вообще предполагается, что вы пойдете в поиск, вобьете туда «cpu efficiency» и почитаете, если для вас это не очевидно.

Если непонятно что такое «среднее», я также предполагаю что вы пойдете в поиск и вобьете туда «average value» и почитаете определение.

Так понятно?

Нет. За всё обсуждение я даже не увидел определение термина «эффективность».

С учетом последних двух абзацев прошлого ответа, все еще непонятно?

Кому они могут пригодиться и для чего?

Кому они могут пригодиться и для чего?

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

Но вообще предполагается, что вы пойдете в поиск, вобьете туда «cpu efficiency» и почитаете, если для вас это не очевидно.

How is CPU efficiency calculated?

CPU efficiency is a measure of how well an application utilizes its requests for CPU. Efficiency is calculated with the following formula: efficiency=cpu_time / (run_time x number_of_cpus).

О-о-о-о-ке-е-е-ей…

Если непонятно что такое «среднее», я также предполагаю что вы пойдете в поиск и вобьете туда «average value» и почитаете определение.

Average

In ordinary language, an average is a single number taken as representative of a list of numbers, usually the sum of the numbers divided by how many numbers are in the list (the arithmetic mean). For example, the average of the numbers 2, 3, 4, 7, and 9 (summing to 25) is 5. Depending on the context, an average might be another statistic such as the median, or mode. For example, the average personal income is often given as the median—the number below which are 50% of personal incomes and above which are 50% of personal incomes—because the mean would be misleadingly high by including personal incomes from a few billionaires.

О-о-о-о-ке-е-е-ей…

только уменьшаете вероятность ответа по существу

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

И что за прыжки с «ты» на «вы» и обратно от комментария к комментарию?

С учетом последних двух абзацев прошлого ответа, все еще непонятно?

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

проще же записать человека в неадекватного и начать игнорировать

…

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

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

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

И что за прыжки с «ты» на «вы» и обратно от комментария к комментарию?

Иногда бывает, особенно когда я к собеседнику начал на «вы», а собеседник отвечает используя «ты».

только догадываться из контекста. Здесь было недостаточно контекста.

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

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

Там проблема во времени компиляции jit кода, но мцст в 16с запилили какую то аппаратную хрень которая собирает профили исполнения программ что по идее должно сильно ускорить компиляцию и возможно даже вообще отказаться от отдельных jit компиляторов ( lcc в профили умеет, llvm вроде тоже).

Так что подождем и посмотрим как оно все будет, может это выход из лабиринта.

Там проблема во времени компиляции jit кода, но мцст в 16с запилили какую то аппаратную хрень которая собирает профили исполнения программ что по идее должно сильно ускорить компиляцию и возможно даже вообще отказаться от отдельных jit компиляторов ( lcc в профили умеет, llvm вроде тоже).

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

Или речь о том, что JIT может использовать этот функционал? Ну это может да, только отказаться от отдельных компиляторов это не поможет, только если вы не решите не просто портировать OpenJDK, а переписать его поверх вашего фреймворка для jit-компиляторов (если таковой будет). Что - крайне большая глупость.

При статической компиляции, профили - это полезная опция.

При динамической - это базовая вещь. В противном случае оно бы называлось one/start time compilation, потому что без профиля исполнения программы jit не знает как иначе код скомпилировать и будет выдавать одно и тоже сколько раз его не запускай.
А это значит что например в джаваскрипте на каждую функцию будет висеть все виды типов и ты будешь эти все проверки проходить при каждом исполнении.

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

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

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

Ну так вы перечитайте, что я вам написал. Конкретно вот этот фрагмент, который вы проигнорировали:

Или речь о том, что JIT может использовать этот функционал? Ну это может да, только отказаться от отдельных компиляторов это не поможет, только если вы не решите не просто портировать OpenJDK, а переписать его поверх вашего фреймворка для jit-компиляторов (если таковой будет). Что - крайне большая глупость.

Так что фундаментально проблему не решает, что профиль собирается железом.

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

Потому что Rust решил выбрать llvm как бэкэнд, Go решили сделать свой. С интерпретаторами та же фигня - есть OpenJDK, есть парочка питонячьих, есть lua, есть всякие .NET’ы и так далее и тому подобное. Хотите поддерживать все множество? Извольте портировать все, притом не просто портировать, а в сулчае с Эльбрусом, если не хотите получить ту же фигню что с luajit, перепишите с нуля по факту.

фундаментально проблему не решает

«Фундаментальную проблемму» необходимости портирования ПО не решает ни одна архитектура. Все платформы обрастают мясом постепенно, еще каких то 10 лет назад под арм небыло нихрена, сейчас же aarch это вторая по поддерживаемости платформа (усилиями крупных компаний прежде всего) после ia32. В какой проект не загляни там поддержка интеловских расширений где через интринсики а где и на ассемблере, интел сам к этому шел 20 лет.

Потому что Rust решил выбрать llvm как бэкэнд, Go решили сделать свой.

И что? У LLVM есть входной формат данных, поддержи этот формат в своем компиляторе и будет у тебя раст. Go помоему на gcc базируется, поддержи и формат gcc.

С интерпретаторами та же фигня

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

В случае с эльбрусом с его особенностями работы с памятью, ему еще придется писать свой сборщик мусора (или не писать, если он не обязателен в тойили иной среде), зато вместо местячкового jit-а сомнительного качества можно будет вызывать родной качественный компилятор. В большинстве языков (даже том же самом luajit) jit компилятор опционален. Чуваки которую джаву портировали вместо имеющихся в джаве jit -ов (там их два помоему) взяли сперва какой то проект на llvm и оно работало.

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

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

«Фундаментальную проблемму» необходимости портирования ПО не решает ни одна архитектура

Фундаментальных проблем тут на самом деле две, и это не «необходимость портирования». Первая - в том что подходы VLIW несколько отличаются от подходов RISC/CISC и кодогенератор надо делать соответствующий, иначе работать ничего не будет нормально. Поэтому нужно весь принцип работы кодогенератора пересматривать. И тут что есть сборка профиля, что нет - один черт.

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

И что? У LLVM есть входной формат данных, поддержи этот формат в своем компиляторе и будет у тебя раст.

Ну так Rust на эльбрусе ровно так и сделан. Только вот конвертация IR из LLVM в то что ожидает lcc мягко говоря не очень хорошо работает и не позволяет компилятору накатывать нужный набор оптимизаций (потому что авторы IR LLVM не думали что кому-то такое надо).

Про gcc - официальный родной компилятор вообще самобытный. Есть реализация и поверх llvm и поверх gcc, но они, мягко говоря, уступают (отстают на пару версий, имеют серьезные проблемы со скоростью работы, не реализуют нормально горутины).

И даже во всем этом проблема - чувакам из МЦСТ надо адаптироваться каждый раз как выходит новый rust, ровно поэтому они отсают примерно на 1-2 года, что и для rust и для go - критично.

Интерпритаторы (быстрые) пишут на ассемблере

Не обязательно, с чего вы взяли?

Все это надо писать под каждый процессор отдельно

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

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

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

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

По факту не получится, компилятор слишком долго работает.

В большинстве языков (даже том же самом luajit) jit компилятор опционален. Чуваки которую джаву портировали вместо имеющихся в джаве jit -ов (там их два помоему) взяли сперва какой то проект на llvm и оно работало.

Понимаете в чем дело, никого кроме энтузиастов не интересует это самое «и оно работало», если оно адски тормозит. А Эльбрус такая замечательная платформа, что энтузиастов на ней практически нет.

По факту не получится, компилятор слишком долго работает.

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

Эльбрус не похож на риск процессоры, а система комманд risс-5 не похожа на арм и тем более интел. Rust не похожь на Си, llvm не похож на gcc, V8 не похожь на JVM. Пока вы вместе с единомышленниками рассуждаете нужна нам своя архитектура/языки/компиляторы/библиотеки или не нужна, там просто делают все по фану. Просто захотели питон и сделали, захотели го/раст потом что плюсы перестали устраивать и сделали, захотели риск в очередной раз переизобрести и переизобрели, несмотря на то что в природе куча рискподобных с готовой кодовой базой. Пока вам что-то мешает они делают, поэтому у них есть архитектуры операционные системы, а у нас только нытики похоронщики и распильщики на армах/рискпятых линуксах и спо.

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

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

OpenE2K/binutils-gdb, можешь не благодарить.

OpenE2K/qemu-e2k, а тут можешь посмотреть как эти инструкции работают.

ilyakurdyukov/littlecc-e2k, а тут уже поддержка в LCC.

Ждём «кодогенератор». :)

По факту я и пытаюсь весь тред объяснить что динамическая профилировка сразу же резко ускоряет процесс компиляции с оптимизациями

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

а система комманд risс-5 не похожа на арм

Система команд - не похожа, а вот принципы те же самые. Поэтому сносно работающий на ARM код при прямом портировании 1-в-1 (если мы говорим про асм или кодогенерацию) будет также сносно работать на x86 и на risc-v, а вот на Эльбрусе будет адски тормозить. Догадываетесь почему?

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

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

Пока вам что-то мешает они делают, поэтому у них есть архитектуры операционные системы

И вы правда не замечаете, что живых операционных систем буквально несколько и живых архитектур тоже примерно столько же? Не думали, что это не просто так?

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

а система комманд risс-5 не похожа на арм и тем более интел.

Похожа.

Rust не похожь на Си

Нет. Раст и есть си.

llvm не похож на gcc

Похож. Это примерно как говорить «разные jvm не похожи на себя». Все сишка-вм более-менее похожи.

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

Просто захотели питон и сделали

Питону тысяча лет.

захотели го

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

раст потом что плюсы перестали устраивать

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

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

и сделали

Что сделали? Взяли готовый сишный компилятор на котором любой школьник может сделать свою сишку? И побежали побеждать?

захотели риск в очередной раз переизобрести и переизобрели,

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

несмотря на то что в природе куча рискподобных с готовой кодовой базой.

Какие, ты мне покажи? arm проприетарный? Либо что-то мёртвое? Назови их.

Пока вам что-то мешает они делают, поэтому у них есть архитектуры операционные системы, а у нас только нытики похоронщики и распильщики на армах/рискпятых линуксах и спо.

Что они делают? Всё что ты перечислил(ну за исключением го) - это примитивная нахлабучка на существующей базой. Это просто пиар-проекты, либо проекты по консолидации(как риск5, который сам по себе ничего из себя не представляет).

А ты просто потребитель этого пиар-шлака.

И что? У LLVM есть входной формат данных

Нет.

поддержи этот формат в своем компиляторе и будет у тебя раст.

Никакого раста не существует. Это огрызок фронта для llvm. Никакой «входной формат» ллвм не принимает. Делая что-то на llvm - ты становишься частью ллвм.

Вернее даже не так. llvm - это просто jvm, где j заменена на c. Используя llvm ты просто используешь си как таргет. Со всеми его проблемами.

Go помоему на gcc базируется, поддержи и формат gcc.

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

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

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

О чём ты? Что ты несёшь. Интерпретатор всегда - это сишка. Только у сишки есть переносимая среда исполнения.

Под каждый процессор - это jit. Но jit сам по себе не существует. Это просто малая часть vm, даже в какой-нибудь жаве.

В случае с эльбрусом с его особенностями…

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

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

Плюс в этих функциях много всяких «трапов», никто не пытается их инлайнить(потому что это намного сложнее). Это так же является проблемой для эльбруса.

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

Проблема не в том, чтобы сделать широкую ООО машину.

Проблема в этом. Интел не может сделать широкий фронт до сих пор из-за мусорности х86.

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

Ты где-то услышал про какое-то окно, но ты явно не понимаешь что это такое. Никакая ширина ни от какого окна не зависит. Окна в принципе не существует.

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

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

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

Профиль и JIT это разные вещи, не надо их смешивать.

Одинаковые.

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

Боже, твоё невежество поражает моё воображение.

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

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

Что - крайне большая глупость.

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

Да и почему это глупость? Потому что ты так сказал? Если вдруг это кому-то нужно. Именно потому что jvm переписывали - жава до сих пор жива.

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

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

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

Единственное где суперскаляр работает - это всякая легаси-убогая динамическая лапша. И то здесь всё иначе. Работает это тем лучше - чем тупее суперскаляр.

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

Одинаковые.

Разные. Почитай теорию что ли.

Боже, твоё невежество поражает моё воображение.

Обоснуй?

Никаких паттернов использования нет. Это всё чушь.

И конечно ты готов это доказать? А тебя не смущает, что твое утверждение противоречит архитектуре (и коду) как минимум некоторых JIT’ов?

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

Тоже несколько чушь говоришь. Попробуй в продакшене отключить jit в jvm и посмотри как весело будет.

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

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

Тут два момента - там речь была не совсем про Java а про то что идея реимплементации каждой VM для каждого языка поверх условной общей VM - крайне большая глупость. Читай внимательнее.

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

Да и почему это глупость? Потому что ты так сказал? Если вдруг это кому-то нужно. Именно потому что jvm переписывали - жава до сих пор жива.

А ты серьезно не понимаешь? Хорошо, приведу пример - gcj. Расскажи, что там с ним стало и почему?

Впрочем подскажу ответ: Написание своей альтернативы JVM глупость потому что тебе придется это все дело поддерживать, без поддержки апстрим разработчиков ты обречен иметь свои специфичные косяки, несовместимость и кучу проблем в непонятных местах. Собственно pypy vs cpython тоже отличный пример. И на самом деле gccgo/gollvm vs go - притом что в этом случае первые два пилятся при участии разработчиков оригинального Го (я не знаю, совпадает ли полностью список разработчиков, поэтому не делаю громких заявлений) и все равно gccgo и gollvm отстают катастрофически и не полностью совместимы.

Разные. Почитай теорию что ли.

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

Разница есть - показывай её.

И конечно ты готов это доказать?

Не, доказывать должен ты. А не я. Ты утверждаешь что что-то есть - твоя обязанность доказывать.

А тебя не смущает, что твое утверждение противоречит архитектуре (и коду) как минимум некоторых JIT’ов?

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

Тоже несколько чушь говоришь. Попробуй в продакшене отключить jit в jvm и посмотри как весело будет.

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

Альтернативно - попробуй ради интереса какой-нибудь проект на Питоне перенести на pypy

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

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

Меня то ничего не удивит. Учитывая качество твоих примеров.

Вон гугл недавно вырубил жит в v8. Результаты всех действительно удивили. Ну по крайней мере пропагандистов.

Тут два момента - там речь была не совсем про Java а про то что идея реимплементации каждой VM для каждого языка поверх условной общей VM - крайне большая глупость. Читай внимательнее.

Не. Эта идея как раз таки хороша. В любом случае vm типа жавы нахрен не упали. Обсуждать их не имеет смысла.

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

Мне то что с этого? У меня нет ненависти к жаве. У меня в принципе нет ненависти. Просто я не вижу смысл в том, что люди кому-то навязывают мусор.

А то что на жаве/прочих пхп написано много говнокода - это мало что значит. Даже в мире жавы уже все выкидывают жаву. Конечно там языки с jvm-хостом, но то просто следствие легаси.

А ты серьезно не понимаешь? Хорошо, приведу пример - gcj. Расскажи, что там с ним стало и почему?

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

Впрочем подскажу ответ: Написание своей альтернативы JVM глупость потому что тебе придется это все дело поддерживать, без поддержки апстрим

Апстрим в жаве? окстись. Там 90% говнокода никогда не видели аптрима за последние лет 10 наверное.

разработчиков ты обречен иметь свои специфичные косяки, несовместимость и кучу проблем в непонятных местах. Собственно pypy vs cpython тоже отличный пример. И на самом деле gccgo/gollvm vs go - притом что в этом случае первые два пилятся при участии разработчиков оригинального Го (я не знаю, совпадает ли полностью список разработчиков, поэтому не делаю громких заявлений) и все равно gccgo и gollvm отстают катастрофически и не полностью совместимы.

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

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

Делать там какую-то жаву, поддерживать апрситим, совместимость с ним - это твои фантазии. Это ненужно.

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

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

Не, доказывать должен ты. А не я. Ты утверждаешь что что-то есть - твоя обязанность доказывать.

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

Не, мне ненужны оправдания и ссылки на какие-то мистические маня-архитектуры

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

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

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

Ничего не увижу.

Врешь.

Меня то ничего не удивит. Учитывая качество твоих примеров.

Тогда возьми реальный production на питоне и переведи на pypy, раз не удивит. Посмотри потом на потребление ресурсов и latency по компонентам.

Вон гугл недавно вырубил жит в v8.

Пруф-линк конечно же не приведешь? И вот чтоб именно гугл, именно недавно и не на бенчмарках и без «а вот пример в специально оптимизированном случае», пожалуйста.

Мне то что с этого? У меня нет ненависти к жаве.

Ага, человек без нанависти откровенно нападает на джаву и на VM. Я прям так и поверил в это.

Даже в мире жавы уже все выкидывают жаву

А докажешь, что ВСЕ? Придется перечислить правда все компании использующие джаву и доказать что каждая из них выкидывает, но раз ты так сказал - я верю, ты справишься с доказательством.

Зачем мне что-то рассказывать?

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

Во-вторых то, что я предлагал - это не пилить свою jvm.

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

Делать там какую-то жаву, поддерживать апрситим, совместимость с ним - это твои фантазии. Это ненужно.

Учись в контекст, беспочвенные обвинения тебе не к лицу.

спорно. по какой-такой производительности?

векторные расширения есть и для risc-v

Впрочем я сейчас здорово некропостнул и это всё уже обсудили. :)))

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

Маняврация 0 ака «Не должен»

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

• Маняврист отказывается что-то аргументировать. Любой отказ определяет слив.

• Маняврист пытается оправдать это тем, что «на каждого» - это не так. Аргументация а) должна уже быть, чтобы что-то утверждать. б) она не зависит от каждого.

Как следствие всё что остаётся - написать УНИВЕРСАЛЬНУЮ аргументацию, которая уже ДОЛЖНА быть. Время у манявриста на написание оправданий есть. Как и на написание других манявраций. Значит время на написание есть.

Маняврация 1 - подлог

Тогда возьми реальный production на питоне и переведи на pypy, раз не удивит. Посмотри потом на потребление ресурсов и latency по компонентам.

Опять же, ссылки на фентезийный «production». Примеры не показаны. При том не просто «запусти», а маня-«переведи».

Но подлог не в этом. Ведь выше был дан ответ на тему питона:

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

Данный манявратор проигнорировал это обстоятельство. Т.е. это не сравнение jit и не-jit. А сравнение того, что не имело цели быть производительным с тем, что имело. От наличия/отсутствия жита это не зависит.

Маняврация 2 - подмена контекста и враньё.

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

• отвечающий не может определять контекст.

• происходит подмена с vm на маня-vm. Т.е. манявратор сел в лужу и пытается ограничить оппонента только своими фантазиями о vm, выгодными ему.

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

• Пытается свои фантазии выдать за мои тезисы.

А теперь тотальное уничтожение маняврации.

В сообщении начальном моём было два тезиса:

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

Да и почему это глупость? Потому что ты так сказал? Если вдруг это кому-то нужно. Именно потому что jvm переписывали - жава до сих пор жива.

Ответом на «глупость» является второй тезис. Разберём его. Доказан полностью он был здесь: Исходники ядра Linux для e2k появились в открытом доступе (комментарий) Тезис манявратора был ПОЛНОСТЬЮ уничтожен. После этого манявратор слился и не отвечал на это.

Разберём попытки:

А ты серьезно не понимаешь? Хорошо, приведу пример - gcj. Расскажи, что там с ним стало и почему?

Здесь манявратор попытался защититься типичной логической ошибкой. Разберу её на простом примере:

Какова формула тезиса? «делать что-то бессмысленно» - является ли пример бессмысленности опровержение? Нет. В чём ошибка.

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

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

Пациент утверждает «выходить в окно бессмысленно» - это не требует доказательств. Всё бессмысленно. Попытка это доказать определяет лишь непонимание. Поэтому такие утверждения ломаются контр-примерами.

Как я опроверг этот тезис? Правильно - привёл в пример гугл и андроид. На этом манявратор слился и перестал отвечать.

Всё, несостоятельность заявления доказана. Теперь вернёмся к тезису второму:

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

Здесь я отрицаю жава. Я ломаю контекст. Вспомним реальный контекст, а не враньё.

Или речь о том, что JIT может использовать этот функционал? Ну это может да, только отказаться от отдельных компиляторов это не поможет, только если вы не решите не просто портировать OpenJDK, а переписать его поверх вашего фреймворка для jit-компиляторов (если таковой будет). Что - крайне большая глупость.

Видим тут те самые два тезиса на которые я отвечал.

Что - крайне большая глупость.

Было уничтожено мною выше.

переписать его поверх вашего фреймворка для jit-компиляторов (если таковой будет)

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

Я ответил на это то, что а) жава ненужна. б) Если есть жава-легаси - для него делается совместимая жава. Т.е. я заранее ответил на эти сказки:

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

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

Тема ещё не особо остыла, и её ещё кантуют. К тому же я тогда слишком размыто изъяснился, и никто толком не понял.

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

Правильно, потому как пропаганда не различает isa(что является мусором ничего не стоящим. Ценность которой только в унификации) и реализацию, которая может в эту isa.

В целом схема такая же как с растом. Пропаганде нужно создать у жертв ассоциации вида - «раст - безопасно», «риск5 - круто/быстро». Всё это делается для того, чтобы выбивать гранты/другие преференции по ключевым словам. Потому как во много это определяет общественное мнение. Манипулируя им - они манипулируют финансовыми потоками и того, что можно в них(в бабло) конвертировать.

Я бы в качестве примера предложил рассмотреть эппл, которые купили небольшую фирмешку, которая делала чипы и через разумное время они уже делали такие ядра, которые по ipc обходят решения от интела. Что это доказывает?

ipc мусорная метрика. Как минимум потому, что практически вся производительность дерьмокода зависит от задержек. Т.е. именно от качестве бекенда.

В том же эльбрусе бекенд говно. Судя по всему это какие-то мусорные ip-блоки. Т.е. на частоте в 2-3 раза ниже интела - он имеет задержки на инструкциях в 2-3 раза выше интела.

А задержки не зависят от частоты - они зависят от времени.

Тоже самое с эплом. Ты видел что там у эпла? Что он там реализовывал, а для чего взял готовые блобы? Судя по всему на рынке они есть. У эпла есть и доступ и бабки.

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