1C объявила начало сборки для Linux в архитектуре Эльбрус

То есть, фактически, весь старый софт и ОС надо было выкидывать и ставить бинарники под новую архитектуру?

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

Строго наоборот — они при каждом переходе по несколько лет выпускали бинарники, пригодные для обеих платформ. Да, это удваивало объём скомпилированного кода. Но это было единственным недостатком.

Нативный?

Вроде, нативный, winelib не упоминался. Но похоже, что-то другое, Компас я сейчас у них не нашёл.

на проприетарном вайне

Именно нативный. Но судя по всему, я спутал Компас с чем-то столь же популярным у бедных студентов.

не останавливало

Похоже, беларусам там не рады, 403 показывают.

А если найду?

Странно, на wiki этот проц 10w, но не суть.

джва года ждал. На самом деле хорошая новость.

Ещё раз повторяю: они придумывали решения, которые обеспечили пользователям удобный переход с платформы на платформу.

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

Более того, правильное использование явного параллелизма в архитектуре VLIW потенциально может дать преимущество именно клиент-серверным информационным системам

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

Хотите преимуществ в вычислениях - не морочьте людям голову и используйте видеокарты.

Частота важна для х86, для некоторых других архитектур частота не так важна для производительности.

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

будто на складах их, напротив, ого-го.

Можете поднять сообщение от декабря 2021 года от Трушкина. А потом по-моему мартовское в соответствующей телеге. Вы удивитесь тому, как их мало.

и, по некоторым сведениям, Alpha.

А вот с этого места по-подробней, пжалста! :)

кстати, а чё там с Байкалом?

Тоже самое, что и с Эльбрусом. TSMC-же :)

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

У Эльбруса безумно дорогое переключение контекста, например. Типа переключаем контекст... И весь разогнанный VLIV-конвейер идет куда? Правильно, превращается во внезапно остановившийся метрошный эскалатор вместе со всей на нем толпой ,) И эта штука от частоты не зависит.

Дома уже много чего, например Sony Play Station, которая нифига не Интел. Эппл уже за жизнь вон пятый процессор использует. И да, я этот коммент c Mac M1 пишу :)

По «непонятным причинам» и PDP-11 до сих пор где-то в Канаде на атомной станции трудится. По крайне мере, туда человека несколько лет назад искали со скиллами PDP-11/RSX-11/MACRO-11. Искали, кстати, по пабликам DECовских пенсионеров и фанатов на линкедине. Если с тех пор задачи не изменились и техника справляется, то чо ее трогать-то?

например Sony Play Station, которая нифига не Интел.

Ну да, там AMD.

Не сразу разобрал, что на картинке компас. Издалека показалось, что там что-то более подходящее ситуации

А что так все возбудились? Объявлено только о «начале сборки», а конца пока не видать.

У Эльбруса безумно дорогое переключение контекста, например. Типа переключаем контекст… И весь разогнанный VLIV-конвейер идет куда? Правильно, превращается во внезапно остановившийся метрошный эскалатор вместе со всей на нем толпой ,) И эта штука от частоты не зависит.

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

Спрос очевидно есть

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

Проблема лишь в том, что в обычном софте очень мало кода, который тупо что-то считает. И VLIW такое не прощает.
Можно написать код так, чтобы было быстро, но весь софт не перепишешь.

Мне казалось, что голыми частотами прекратили меряться еще в прошлом веке…

403 показывают

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

Зачем Вы спрашиваете об этом на публичном ресурсе, чтобы недружественные лица смогли устранить используемые способы решения?

Проц от МЦСТ не жизнеспособный проект, это гибрид sparc с наработками по vliw в ссср, соединили как смогли не привнося ничего своего нового, сростили с западными ip в части работы с памятью и интерфейсами, и получилось черт знает что

Вы удивитесь тому, как их мало.

Зачем удивляться? Много или мало - понятия относительные и во многом зависят от точки зрения и/или целеполагания. Чтобы хватило - и довольно. Короче, поглядим, увидим. Будет интересно.

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

ЛОЛ ЧТО? Это известно было ещё в 70-х годах прошлого века.

никаких преимуществ VLIW для процессоров общего назначения не дает

На это можно посмотреть и иначе: никаких недостатков в целом VLIW не имеет. Поэтому в определённых экономических условиях может быть выгоднее.

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

Спорное утверждение.

Проблема лишь в том, что в обычном софте очень мало кода, который тупо что-то считает. И VLIW такое не прощает.

Но есть и огромное количество расчетного софта, который чаще всего запускают на выделенных машинах или HPC-кластерах. Есть задачи DSP, для которых VLIW отлично подходит.

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

Хм, не думал, что это секрет. Например, интел, амд и нвидиа из России ушли, но процессоры и видеокарты купить можно, следовательно, вопросы доставки решены, секрета не вижу

На это можно посмотреть и иначе: никаких недостатков в целом VLIW не имеет.

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

Кстати, если я не ошибаюсь, коммерческие перспективы Itanium убило, в основном, отсутствие высокопроизводительной JVM, что и сейчас актуально для всяки Сбербанков

Тогда не было x86 процов, на которых популярный софт объективно работал быстрее. Ну вот не было и всё. Атлоны того времени были неплохие (особенно учитывая цены, апгрейдабельность, открытый множитель и тд), в единичных унылых задачах типа архиваторов даже обгоняли топовые пни, но не более того.

Наверное проще выбрать фразы, в которых нет вранья, чем его перечислять. Атлоны рвали П4 любой ревизии. В клочья. И в синтетике и в реальных приложениях. У меня было и то и другое, я сравнивал. И у знакомых были. Мы были молоды, тусили на оверклокерах и любили померяться писюнами процессорами.

тратить кучу времени на компиляцию кода

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

придется написать кучу кода для поддержки архитектуры в опенсорсных проектах

Да, нужно. Именно поэтому выводы о каких-то исследованиях кажутся сомнительными, т.к. в вероятностью 99% там сравнивали тупо «в лоб».

С таким же успехом можно говорить что LISP медленнее С в 3 раза, потому что вот мы написали один и тот же алгоритм и сравнили. А на самом деле компилятор LISPа просто хуже, т.к. им не так активно занимаются. Да, на практике не имеет значения почему получается медленнее, но из этого глупо делать выводы что у отстающего есть какие-то врождённые, неустранимые недостатки.

Зачем нужен 1С, если есть Java?

«Суперкомпилятор» работает с исходным кодом, а JIT транслирует байткод в машкод, который, внезапно, уже оптимизирован

внезапно, уже оптимизирован

Чего-чего? Машкод, который выплюнул JIT, оптимизирован ровно настолько, насколько его смог оптимизировать JIT-компилятор. В случае с VLIW это означает, что JIT-компилятор должен 1) сам делать полный шедулинг (тогда как в x86 и большинстве RISC’ов есть OOoE, на наличие которого все самопальные JIT’ы и рассчитывают); 2) сам разбалансировать нагрузку по всем доступным ALU.

Парсинг исходного кода это вообще копеечная задача по сравнению со всем этим хозяйством.

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

Говоря простым языком, во VLIW на компилятор перекладывается то, что в x86 и RISC делается на уровне железа. В этом его сила и и его слабость.

означает, что JIT-компилятор должен 1) сам делать полный шедулинг (тогда как в x86 и большинстве RISC’ов есть OOoE

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

порядка инструкций, переходов

Там, где есть OOoE, компилятор может делать все это «на отвали», чем активно пользуются в JITах, упрощая архитекутру компиляторов до предела.

распределения регистров

Распределить 32 регистра (у части которых роли строго определены ABI платформы) намного проще, чем сотни

Говоря простым языком, во VLIW на компилятор перекладывается то, что в x86 и RISC делается на уровне железа

Ещё раз, это заблуждение и упрощение ситуации. Во VLIW компилятор имеет максимальный контроль над тем как и что будет исполняться, это позволяет лучше оптимизировать код, чем это возможно в обычных архитектурах. Но в этих обычных архитектурах есть дополнительная возможность оптимизации кода в рантайме. Не очень большая, но есть. И суммарно это может оказаться более эффективно. А может не оказаться.

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

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

Там, где есть OOoE, компилятор может делать все это «на отвали»

Нет, не может. Более того, когда речь заходит о максимальной производительности, то даже на x86 делают компиляцию во много проходов с профайлингом (т.е. рантайм статистикой) и подбором параметров.

JIT’ы этим воспользоваться не смогут

HotSpot передаёт тебе привет. Да и вообще JIT как раз таки очень хорошо может этим воспользоваться т.к. у него имеется именно рантайм статистика что может нивелировать отсутствие шедулера.

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

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

Для сравнения, в линейке процессоров POWER OOoE пристуствовал во всех моделях, кроме POWER 6. И ассемблерный код для POWER 6 приходилось писать отдельно, иначе неправильный шедулинг все губит.

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

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

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

Или если импорт интелов окончательно прикроют (причём прикрыть могут как «здесь», так и «там», но пострадавшей в обоих случаях будет сова, а не пень).