LINUX.ORG.RU

Создание экосистемы свободного ПО для процессоров «Эльбрус»

 


3

6

В ТАСС состоится пресс-конференция, посвященная развитию экосистемы свободно-распространяемого ПО для платформы «Эльбрус».

О текущей ситуации на рынке аппаратных технологий и влиянии публикации исходного кода системного ПО для процессоров «Эльбрус» на дальнейшее развитие IT-сферы России расскажут директор департамента цифровых технологий Минпромторга России Владимир Дождев, заместитель генерального директора по маркетингу АО «МЦСТ» Константин Трушкин, исполнительный директор Ассоциации разработчиков программных продуктов «Отечественный софт» Ренат Лашин и глава Ассоциации российских разработчиков и производителей электроники Иван Покровский.

АО «МЦСТ» объявляет о раскрытии исходных кодов ядра linux, системных библиотек, патчей совместимости для ПО с открытым исходным кодом, обеспечивающих работу с архитектурой данной платформы. Этот шаг делается для развития открытого ПО для процессоров «Эльбрус».

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 3)
Ответ на: комментарий от anonmyous

Большинство из этих ссылок - краткие, не аргументированные измышления.

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

детерминированный алгоритм статического планирования для вливов, китайцы придумали лишь в 2024

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

Так и зачем нам ссылки от 2008, да ещё и не открывающиеся без ВПН?

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

Итог: читайте статьи целиком, а не по диагонали.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

Нет, это не ложь, и те, кто реально прочитал эти ссылки, понимают их безосновательность. Если бы это было не так, вы бы давно скопи/пастили из них хотя бы парочку хорошо обоснованных тезисов. Но там таких просто нет, и вся ваша аргументация сведётся к «ну, это ж сотрудники МЦСТ так думаю».

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

Да вы чего-то бредите. :) Кнут вообще говорит, что и мультиядерность нафиг не нужна, так как она не ускорит его ТеХ. И, кстати, в начале 200х, откуда эта ссылка и пришла, так думало большинство программистов. Все хотели халявы, чтобы новые чипы продолжили бы ускорять их 40летней давности код. А халяву не дали. В результате, за 20 лет, люди научились писать мультитридовый код, и переписали имеющийся, так как старый код новые камни уже не ускоряли. А в случае с вливом - ещё и замедлят. И снова придётся всё переписывать. И программеры, в конечном итоге, снова прогнутся, хотя сейчас огворят «да нахрена нам этот ILP». Как и 20 лет назад Кнут говорил «да нахрена мне эта многоядерность».

anonmyous ★★
()
Ответ на: комментарий от liksys

Аргументы и пруфы расписаны в каждой статье.

Все эти «аргументы» строятся на выдуманном предположении, что архитектура Эльбрусов – это нечто неизменное и неподдающееся улучшению, что является очевидным заблуждением, если не сказать больше. И это прекрасно видно даже по тем моделям, что уже выпущены. Даже 6-е поколение уже вполне применимо для использования на десктопе, а в 7-м Эльбрусы помимо прочего обзаведутся аппаратным префетчером и предсказателем ветвлений, о чём ты сам упомянул. Что это если не прогресс? А 8-е поколение по слухам претерпит ещё более кардинальные изменения.

Second_Variety
()
Ответ на: комментарий от Second_Variety

Что это если не прогресс? А 8-е поколение по слухам претерпит ещё более кардинальные изменения.

+1, а какие конкретно изменения нужны Эльбрусу - уже и так видно из ссылки про пульсона. Лично у меня она практически все вопросы сняла. А ведь ещё про киттсона даже не накидали ссылок…

anonmyous ★★
()
Ответ на: комментарий от anonmyous

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

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

Если бы это было не так, вы бы давно скопи/пастили из них хотя бы парочку хорошо обоснованных тезисов.

Если бы тебе было что возразить по существу - ты мог бы не начинать невнятные разговоры о ВПН. Тем временем, я написал саммари. Этого более чем достаточно. Кому надо - прочитают и изучат.

Но там таких просто нет

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

Да вы чего-то бредите.

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

liksys ★★★★
()
Ответ на: комментарий от Second_Variety

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

Нет. Все эти аргументы строятся на том факте, что VLIW всегда будет хуже суперскалярных архитектур с Out-of-Order Execution. Соответственно, если бы МЦСТ пилили чипы на тех же ARM, прогресс был бы больше, производительность – выше, а проблем с софтом – меньше.

hateyoufeel ★★★★★
()
Ответ на: комментарий от liksys

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

Мож не всех, но некоторые уже тут отписались ровно с таким же мнением. Да и что делать со статьёй, где все тезисы идут вот в таком ключе:

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

Ну ок, мы верим. Дальше-то что? Сказано уже было, что проблему решит аппаратный префетчер и предсказатель переходов, которые будут в эльбрус добавлены (если не уже). И так по всем пунктам. Если нет - покажите хоть 1 стоящий пункт.

Если бы тебе было что возразить по существу - ты мог бы не начинать невнятные разговоры о ВПН. Тем временем, я написал саммари. Этого более чем достаточно. Кому надо - прочитают и изучат.

Пфф, нет, это я написал саммари, а вы написали бред. :) По вашей ссылке Кнут говорит, что ему не нужны ни ILP, ни мультитредовость. Как мы увидели за 20 лет, как минимум в 1 из этих пунктов он уже ошибся. Ошибётся и во 2м.

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

Как и все тамошние аргументы, он сводится к конкретной реализации эльбруса и компилятора. Можно было бы сказать «ну ок, эльбрус тогда закопаем», но нет, МЦСТ уже сказал, что эти проблемы будут пофикшены. И что теперь?

Рассуждения о VLIW и техе идут отдельными тезисами.

Покажите хоть 1, достойный обсуждения вне контекста конкретных (старых) версий эльбруса.

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

Фанаты VLIW непробиваемы. Они либо читают критику через слово, либо не читают вообще. Сюда уже вон высадился десант из прошлого треда, одни и те же лица. По существу им нечего возразить - остается только рассказывать про субъективность, жаловаться на впн да клоунов ставить.

Ну хорошо, вот видишь ты - статья на хабре надуманная. Иди напиши ответную, да разбери ее по кирпичикам. Что, не хочется? Боишься, что съедят за несостоятельностью? А съедят. Вот и остается, что спорить на лоре со мной.

liksys ★★★★
()
Ответ на: комментарий от Second_Variety

Даже 6-е поколение уже вполне применимо для использования на десктопе, а в 7-м Эльбрусы помимо прочего обзаведутся аппаратным префетчером и предсказателем ветвлений, о чём ты сам упомянул. Что это если не прогресс? А 8-е поколение по слухам претерпит ещё более кардинальные изменения.

А зачем тогда было брать за основу VLIW? Чтобы потом допиливанием напильником долго и мучительно превращать его в некое подобие архитектуры которую можно было взять изначально? Ведь весь этот твой «прогресс» не более чем исправление первоначальной ошибки в выборе архитектуры.

mbivanyuk ★★★★★
()
Ответ на: комментарий от liksys

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

Так ведь это же ты мне клоуна поставил, клоун! А я ничего такого не делал, значит, ты ещё и врун?

anonmyous ★★
()
Ответ на: комментарий от mbivanyuk

А зачем тогда было брать за основу VLIW? Чтобы потом допиливанием напильником долго и мучительно превращать его в некое подобие архитектуры которую можно было взять изначально?

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

Ведь весь этот твой «прогресс» не более чем исправление первоначальной ошибки в выборе архитектуры.

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

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Мож не всех

Вот и не примазывайтесь.

Ну ок, мы верим. Дальше-то что? Сказано уже было, что проблему решит аппаратный префетчер и предсказатель переходов, которые будут в эльбрус добавлены (если не уже).

Который точно так же был добавлен в итаниуме, как элемент OoO. В таком случае непонятно, зачем вообще нужен VLIW, учитывая, что полноценный OoO лучше всего будет работать на CISC или RISC, о чем там тоже написано. VLIW при этом увеличивает количество транзисторов, не прибавляя заметной производительности на единицу потребляемой электрической мощности, о чем можно увидеть в той же ссылке, и даже по бенчмарку https://7-cpu.com/

И так по всем пунктам. Если нет - покажите хоть 1 стоящий пункт.

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

И так по всем пунктам.

вы написали бред

Это твой лучший технический аргумент, как я понимаю.

Во первых, меньше перезаказов кремния, каждый из которых делался на Тайване, и стоил миллионы (и не рублей вовсе).

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

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

Исследования - это хорошо. Плохо только, что на тупиковое направление делается такая большая ставка.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от anonmyous

Во вторых, влив наработки у них уже были, и хотелось реализовать их потенциал.

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

В третьих, МЦСТ - исследовательская контора, и думали, что потянут такой исследовательский проект.

В 2000 году? Возможно. В 2005, когда Бабаян свалил и уже публично заявлял, что не лезет каменный цветов, думать такое было как-то странно.

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

А если добавить сюда необходимость пилить мегасложный компилятор? Всё ещё на порядок более простые?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от anonmyous

Так ведь это же ты мне клоуна поставил, клоун! А я ничего такого не делал, значит, ты ещё и врун?

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

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

А если добавить сюда необходимость пилить мегасложный компилятор? Всё ещё на порядок более простые?

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

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

Все эти аргументы строятся на том факте, что VLIW всегда будет хуже суперскалярных архитектур с Out-of-Order Execution.

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

В Эльбрусе кроме VLIW архитектура просто более защищенная, Англичане на исследование ARM с малой частью защит Эльбруса, потратили больше чем ушло на Эльбрус-8С, и еще не закончили. А у них уже есть ARM, и опыт.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Ничто не мешает VLIW самому заниматься перестановкой.

Конечно не мешает. Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW?

VLIW более совершенен, потому что известно как ему помочь.

Пристрелить, чтобы не мучался?

В Эльбрусе кроме VLIW архитектура просто более защищенная

Защищённая от чего? От установки в пользовательские компьютеры?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Защищённая от чего? От установки в пользовательские компьютеры?

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

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

Конечно не мешает. Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW?

Потому что во многих случаях можно очень удачно набрать пакет команд и не заставлять процессор тратить мощности впустую?

Защищённая от чего? От установки в пользовательские компьютеры?

http://www.elbrus.ru/arhitektura_elbrus

MOPKOBKA ★★★★★
()
Ответ на: комментарий от liksys

записывает защищенный режим и тегированную память в свойство VLIW

И так, смотрим что я написал:

В Эльбрусе кроме VLIW архитектура просто более защищенная,

Определение кроме я тоже выпишу

Кроме - в добавление к кому-либо или чему-либо

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от liksys

Который точно так же был добавлен в итаниуме, как элемент OoO.

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

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

и проблемы VLIW, неочевидные для обывателя, встают в полный рост.

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

anonmyous ★★
()
Ответ на: комментарий от MOPKOBKA

Конечно не мешает. Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW?

Потому что во многих случаях можно очень удачно набрать пакет команд и не заставлять процессор тратить мощности впустую?

Это в каких? И как это помогает процессору-то? Этот пакет команд – просто довольно всратая кодировка инструкций процессора. Если у тебя в чипе есть спекулятивное выполнение и out-of-order, то ВНЕЗАПНО оказывается, что группировка команд нахрен не сдалась.

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

http://www.elbrus.ru/arhitektura_elbrus

Ты про вот этот кусок?

Одна из самых интересных идей, унаследованных от архитектур Эльбрус-1 и Эльбрус-2 – это так называемое защищенное исполнение программ. Его суть заключается в том, чтобы гарантировать работу программы только с инициализированными данными, проверять все обращения в память на принадлежность к допустимому диапазону адресов, обеспечивать межмодульную защиту (например, защищать вызывающую программу от ошибки в библиотеке). Все эти проверки осуществляются аппаратно. Для защищенного режима имеется полноценный компилятор С/С++ и библиотека run-time поддержки.

Это же буквально описание работы MMU любого современного процессора. Да-да, на x86 такое тоже возможно.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonmyous

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

Про это писал ещё хаскеллист-штангист thesz лет 10 назад (мем из-за него появился, да):

https://thesz.livejournal.com/1448727.html

хз есть ли он на ЛОРе, но про это тоже все давно знают. Это следствие всратой группировки команд, на которую тут дрочат фанаты VLIW.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Ничто не мешает VLIW самому заниматься перестановкой.

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

По этому, это даже не ОоО, а просто какие-то наработки, взятые из других архитектур.

anonmyous ★★
()
Ответ на: комментарий от MOPKOBKA

И так, смотрим что я написал:

И так

Господи.

В Эльбрусе кроме VLIW архитектура просто более защищенная

кроме VLIW

архитектура

«Кроме архитектуры архитектура более защищенная?»

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

Если у тебя проблемы с русским языком, то викисловарь незаменимая находка.

Меня русским языком попрекает клоун, не в состоянии правильно написать слово «итак»? Дожили.

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

Это же буквально описание работы MMU любого современного процессора. Да-да, на x86 такое тоже возможно.

Нет, гранулярность другая. Да и не только это. Эльбрус понимает, что такое «объект в памяти», и проверит, что указатель установлен на начало объекта (а не на середину), и что тип указателя соответствует объекту.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Они отвечали на этот вопрос

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

mbivanyuk ★★★★★
()
Последнее исправление: mbivanyuk (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Это в каких? И как это помогает процессору-то?

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

Это же буквально описание работы MMU любого современного процессора. Да-да, на x86 такое тоже возможно.

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от anonmyous

Это не совсем ОоО.

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

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

Сравнения совершенно легитимны в контексте подхода. Еще раз смотрим на историю итаниума и сравнения последних версий их микроахритектуры.

И совсем не те, о которых вы говорите

Нет, они идут в дополнение к тем, о которых я говорю.

liksys ★★★★
()
Ответ на: комментарий от anonmyous

Эльбрус понимает, что такое «объект в памяти», и проверит, что указатель установлен на начало объекта (а не на середину), и что тип указателя соответствует объекту.

Да-да, это буквально страничный MMU с тегированными. Только тут страницы более гранулярные. Ничего нового.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Second_Variety

У системы команд Эльбруса (то есть на уровне, который не требовал вообще никакого дорогого софта или оборудования) есть два фундаментальных ограничения.

  1. Единый регистровый файл.

Результат операции, которая произошла в канале 0 должна быть немедленно доступна для чтения всем шести. Даже если программа исполняет что-то типа сложения матриц, где это и не нужно. Это как все переменные делать атомиками в однопоточной программе. Юзкейсы, когда это полезно по пальцам фрезеровщика пересчитать можно.

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

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

Исправить это можно либо поломав обратную совместимость и выкинув на помойку все работы по компилятору, либо добавив скрытое спекулятивное состояние, но в таком случае у ISA нет фишек, которые делают эту работу проще по сравнению с каким-нибудь ARM, так что в чем был смысл?

Скажем, векторы у RISC-V явно требуют указать длину цикла перед каждой итерацией. За счет этого можно запилить спекулятивное исполнение без сложного предсказателя ветвлений, без всяких там Томасуло и переименований регистров, и префетчеров. А Е2К под такое банально не проектировался.

Mmmlmlm
()
Ответ на: комментарий от MOPKOBKA

Переставлять команды не бесплатно.

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

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

Ну, да. И? Использование VLIW это как-то убирает? Ни разу! Наоборот, всё становится только хуже.

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от liksys

«Кроме архитектуры архитектура более защищенная?»

Кроме свойства «VLIW» которое находится в наборе «архитектура», эльбрус обладает свойством «защита» которое находится в том же наборе «архитектура».

Меня русским языком попрекает клоун, не в состоянии правильно написать слово «итак»? Дожили.

Я понимаю смысл, ты нет. Ты даже с этим решил спорить? Иди правь тогда викисловарь, я то тут причем?

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Я понимаю смысл, ты нет.

Крайне сомнительно.

Иди правь тогда викисловарь, я то тут причем?

я то

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

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

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

Ну, да. И? Использование VLIW это как-то убирает? Ни разу!

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

Смотри выше мой ответ.

Там нету ответа на мои вопросы, вот тебе хороший сайт https://godbolt.org/
Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной, я очень хочу увидеть новые инструкции x86, которые видимо добавили 5 минут назад, потому что я еще ничего подобного не видел.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

Ссылок выше приведено до жопы.

с VLIW они могут лучше выполнять свою работу.

Не могут.

Там нету ответа на мои вопросы, вот тебе хороший сайт https://godbolt.org/ Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной, я очень хочу увидеть новые инструкции x86, которые видимо добавили 5 минут назад, потому что я еще ничего подобного не видел.

Читай сюда: https://wiki.osdev.org/Memory_Management_Unit

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от liksys

А элементы ОоО понадобились от общей проблемности VLIW, как и в случае с итаниумом.

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

anonmyous ★★
()
Ответ на: комментарий от liksys

*liksys не понимает простейшего предложения, издает страшные звуки при виде викисловаря*

Я понимаю смысл, ты нет.

Крайне сомнительно.

Бедняжка, я все понял, ты же GPT бот, умеешь выдавать вроде бы верные ответы, даже орфографию соблюдаешь, но к сожалению вместо содержания один бред.

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

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от Mmmlmlm

Исправить это можно либо поломав обратную совместимость и выкинув на помойку все работы по компилятору

Ну и ладно. :) Компилятор - не маски для кристалла, перепишут.

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

Покажи пример, выложи код на godbolt

Читай сюда: https://wiki.osdev.org/Memory_Management_Unit

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

с VLIW они могут лучше выполнять свою работу.

Не могут.

Просто повторю комментарий выше: Спасибо что привел так много аргументов, и ссылки на источники.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Бедняжка

Дальше этот шизобред не стал читать.

liksys ★★★★
()
Ответ на: комментарий от Second_Variety

Потому что быстро и дёшево. Другое на тот момент было невыполнимо.

Это, мягко говоря, неправда, даже если они сами так говорят. МЦСТ всю историю делал еще и спарки, и сейчас, кстати говоря, продолжает. Их собственный спарк r2000 от 2018 года лишь чуть-чуть уступает в производительности вливу эльбрус-8св с тем же количеством ядер, при том, что потребляет в три раза меньше энергии.

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

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

А если добавить сюда необходимость пилить мегасложный компилятор? Всё ещё на порядок более простые?

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

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW

Для МЦСТ vliw не является какой-то священной коровой, и очевидно что от чистого vliw’а они будут отходить, по вполне понятным причинам. Уже начинают отходить. Поэтому если сегодня ваши упрёки к разработчикам по поводу vliw ещё как-то прокатывают, то лет через 5-10 они, подозреваю, вообще будут что называется не в кассу.

Second_Variety
()
Ответ на: комментарий от anonmyous

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

До-о-о. Настолько очевидно, что сначала интел шел по пути VLIW, и понял, что железо без ОоО не обойдется, а потом МЦСТ тоже решил побиться головой в ту же стену. Просто и те и другие думали, что подход хороший, а оказалось, что проще отдать всё это на откуп очень умному железу.

Если бы её не решили, влив можно было бы хоронить - тут спору нет.

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

liksys ★★★★
()
Ответ на: комментарий от Second_Variety

Я не просто так упомянул про векторы RISV-V. Тогда их, очевидно, не было, но условный допиленный Kray вышел бы еще проще, чем VLIW, мог бы делать все числодробильные штуки плюс-минус также, как Эльбрус, но не потребовал бы прибивания гвоздями к первой же итерации своего процессора. Джаваскрипт исполнялся бы также посредственно, но хоть частота была не такой позорной.

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

Mmmlmlm
()
Ответ на: комментарий от Second_Variety

Для МЦСТ vliw не является какой-то священной коровой, и очевидно что от чистого vliw’а они будут отходить, по вполне понятным причинам. Уже начинают отходить. Поэтому если сегодня ваши упрёки к разработчикам по поводу vliw ещё как-то прокатывают, то лет через 5-10 они, подозреваю, вообще будут что называется не в кассу.

Когда они отойдут от чистого VLIW, он вполне может превратиться в RISC.

liksys ★★★★
()
Ответ на: комментарий от liksys

До-о-о. Настолько очевидно, что сначала интел шел по пути

Я сказал «проблема очевидная», а не решение. Про её готовое решение я сам только сегодня и узнал из вашей ссылки про пульсон. :) До этого, я лишь теоретически говорил, что, дескать, надо её как-то решать… А, уже решили? Ну и замечательно. :)

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

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

anonmyous ★★
()
Ответ на: комментарий от liksys

Когда они отойдут от чистого VLIW, он вполне может превратиться в RISC.

Да я ведь уже объяснил, что ничего похожего на реальный ОоО, там не может быть по определению. Как они могут прийти к РИСКу, если в рисках не используются бандлы параллельных инструкций?

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Бандлы OoO не помеха. Добавляется еще одно ограничение, что commit/retire должен произойти для всего бандла, а не для единичной инструкции. Или добавить еще регистр для отслеживания частичного исполнения бандла.

Mmmlmlm
()
Ответ на: комментарий от MOPKOBKA

То есть ты не можешь привести пример.

Пример чего? Настройки MMU? Серьёзно?

Получается, ты мало того что не знаешь даже самых поверхностных вещей о эльбрусе

Архитектура закрыта, как я могу о ней знать?

Просто повторю комментарий выше: Спасибо что привел так много аргументов, и ссылки на источники.

Повторюсь: источников выше натаскали целый тред.

Основной аргумент таков: если VLIW так хороша, почему же все – вообще все! – процессоры на ней такое тормозное говно?

hateyoufeel ★★★★★
()
Ответ на: комментарий от Second_Variety

Для МЦСТ vliw не является какой-то священной коровой

То есть, Эльбрус закопают?

Поэтому если сегодня ваши упрёки к разработчикам по поводу vliw ещё как-то прокатывают, то лет через 5-10 они, подозреваю, вообще будут что называется не в кассу.

Напомни мне об этом лет через 5-10. Если МЦСТ не сдохнет.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Пример чего?

Прямо в комментарии выше я писал. Ты рыбка?

Повторю:

Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной

Все это жду от тебя на https://godbolt.org/

Архитектура закрыта, как я могу о ней знать?

Поверхностно знать можешь из открытых источников, их достаточно, что бы знать о теме нашего разговора.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной

Я нигде не писал, что в x86 есть 128-битные указатели. Я написал, что ровно той же защиты можно добиться с помощью MMU. Остальное – твои фантазии.

Кстати, для тегирования указатели совершенно не должны быть 128-битными. В ARM хватает 64 бит. И прикол в том, что чип с MTE у меня вот прямо сейчас в телефоне стоит. А про Елбус я только на ЛОРе читаю и кекаю.

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

Поверхностно знать можешь из открытых источников, их достаточно, что бы знать о теме нашего разговора.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от anonmyous

Да я ведь уже объяснил, что ничего похожего на реальный ОоО, там не может быть по определению.

Это было описано в статьях, а не ты объяснял.

Как они могут прийти к РИСКу, если в рисках не используются бандлы параллельных инструкций?

Уберут бандлы %)

liksys ★★★★
()
Ответ на: комментарий от Second_Variety

Потому что быстро и дёшево. Другое на тот момент было невыполнимо.

А сейчас что мешает? Они пилить напильником этот VLIW ещё 30 лет будут, и не факт что допилят. Я склоняюсь к тому что не осилят, ресурсов не хватит. И потянет это ещё миллиарды. Сколько ещё нужно лет чтобы понять что это путь в никуда?

mbivanyuk ★★★★★
()
Последнее исправление: mbivanyuk (всего исправлений: 1)
Ответ на: комментарий от Mmmlmlm

Бандлы OoO не помеха.

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

Добавляется еще одно ограничение, что commit/retire должен произойти для всего бандла, а не для единичной инструкции.

Ну, по крайней мере в пульсоне - да. Ссылки на киттсон пока не подвезли. :)

Или добавить еще регистр для отслеживания частичного исполнения бандла.

Я так понимаю, это и есть примерно то, что Бабаян запатентовал под названием vectorized instruction pointer. Но, как по мне, это тоже не беспроблемный вариант, ибо вот он как раз уже может привести и к межбандловому переупорядочиванию. :) Чего совсем не хотелось бы допускать.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Я сказал «проблема очевидная», а не решение.

Очевидные проблемы решать надо на старте. А Бабаян был уверен, что это будет и так хорошо работать. Как и интел. Оба признали свою неправоту.

Ну были там рассуждения, что эльбрусу это поможет не радикально. Что отставание сократится, но не достаточно. Что в нём и так говна хватает. :) Мне это не особо интересно, меня перспективы интересуют

Интересуют перспективы, но не интересуют проблемы. И как же ты собрался понимать перспективы, если не интересуешься проблемами? Вопрос риторический.

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

Основной аргумент таков: если VLIW так хороша, почему же все – вообще все! – процессоры на ней такое тормозное говно?

«Основной» ответ: ровно то же самое происходило с многоядерниками 20 лет назад, когда никто (даже Кнут) не понимал, а накуя оно? Ведь пришлось переучивать целое поколение программеров, и переписывать с нуля тонны однотридного старого кода.

Но это сделали!

anonmyous ★★
()
Ответ на: комментарий от anonmyous

«Основной» ответ: ровно то же самое происходило с многоядерниками 20 лет назад, когда никто (даже Кнут) не понимал, а накуя оно? Ведь пришлось переучивать целое поколение программеров, и переписывать с нуля тонны однотридного старого кода.

Очень дерьмовый ответ. Во-первых, про «никто не понимал» – лютая брехня. Хотя бы потому что многопроцессорные системы существовали с древних времён, так что SMP не было чем-то новым. А во-вторых, VLIW-чипы появились раньше многоядерных процессоров, но всё равно не взлетели. Itanium скоро будет 30 лет (или уже было, если считать с самого начала разработки), и за 30 лет он успел родиться, доказать всем неработоспособность VLIW как идеи и сдохнуть.

Но это сделали!

А быстрый VLIW не сделали лол

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от liksys

Очевидные проблемы решать надо на старте. А Бабаян был уверен, что это будет и так хорошо работать. Как и интел. Оба признали свою неправоту.

Интересное заключение, учитывая, что Интел все имеющиеся проблемы решил ещё в Пульсоне (но, на той исторической итерации, было уже поздно), а Бабаян, являясь частью Интел, запатентовал vectorized instruction pointers.

Не признали они неправоту. Просто не всё даётся с 1го раза.

Интересуют перспективы, но не интересуют проблемы. И как же ты собрался понимать перспективы, если не интересуешься проблемами? Вопрос риторический.

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

anonmyous ★★
()
Ответ на: комментарий от MOPKOBKA

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=452133d11a56ba520edce7870a06357f

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

И еще этот указатель может стать 64-битным, если звёзды сойдутся. В типичном коде, у которого 90% рантайма - это epoll и поиск по хешмапе, дополнительные проверки де факто бесплатные, в т.ч. на Эльбрусе. В нетипичном коде редко бывают сложные паттерны работы с памятью, и эксплойты в нём почти не встречаются.

Mmmlmlm
()
Ответ на: комментарий от hateyoufeel

Я нигде не писал, что в x86 есть 128-битные указатели. Я написал, что ровно той же защиты можно добиться с помощью MMU. Остальное – твои фантазии.

О как завертелся, ну давай показывай те же примеры с использованием MMU. Я жду.

Кстати, для тегирования указатели совершенно не должны быть 128-битными.

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

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

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

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

Я тебе ссылку дал, там написано достаточно, что бы ты мог показать мне как через MMU будет достигаться тот же уровень, и как в ARM хватает 64 битов. Понять бы еще зачем правительство Англии стало финансировать проект где у указателя зачем то аж 128 битов в ARM.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от hateyoufeel

Очень дерьмовый ответ. Во-первых, про «никто не понимал» – лютая брехня. Хотя бы потому что многопроцессорные системы существовали с древних времён, так что SMP не было чем-то новым.

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

и за 30 лет он успел родиться, доказать всем неработоспособность VLIW

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

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

То есть, Эльбрус закопают?

Эльбрус образца 2005 года закопают. Вместо него будет другой Эльбрус – с ОоО, ТБВ, ШК, блэкджеком и прочими полезными опциями.

Если МЦСТ не сдохнет.

Это едва ли. Если они в 90-е – 00-е не сдохли, то сегодня им тем более ничто не угрожает.

Second_Variety
()
Ответ на: комментарий от MOPKOBKA

О как завертелся, ну давай показывай те же примеры с использованием MMU. Я жду.

Показать тебе исключение при обращении к неинициализированной странице? Держи доки: https://www.intel.com/content/www/us/en/docs/inspector/user-guide-linux/2022/uninitialized-memory-access.html

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

Зачем? Всё просто: если у тебя в каких-то code paths переменная используется до инициализации хотя бы в теории, просто кидаешь ошибку. Потому что стопудов это сишный говнокод.

hateyoufeel ★★★★★
()
Ответ на: комментарий от liksys

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

Second_Variety
()
Ответ на: комментарий от anonmyous

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

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

Забавно, что ни один Itanium не работал быстрее 2.6GHz. Хотя цеоны уже тогда за 3.5GHz ушли.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от Mmmlmlm

1. Там нету неинициализированной переменной

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

3. Он не соответствует 128 битному указателю из эльбруса по наполнению, у тебя просто языковая абстракция в виде slice, которая даже не распространяется на прочие типы

4. Никаких 128 битных указателей там нету

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от anonmyous

Интересное заключение, учитывая, что Интел все имеющиеся проблемы решил ещё в Пульсоне

Ага. Закапыванием итаниума. Просто они поняли, что раз им понадобился OoO, то нет смысла делать VLIW.

Нерешаемых пока не вижу.

Плохо смотришь.

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

Показать тебе исключение при обращении к неинициализированной странице?

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

Зачем? Всё просто: если у тебя в каких-то code paths переменная используется до инициализации хотя бы в теории, просто кидаешь ошибку. Потому что стопудов это сишный говнокод.

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от Second_Variety

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

liksys ★★★★
()
Ответ на: комментарий от MOPKOBKA

Примеров я не дождусь, понятно.

Как и я не дождусь примеров работающего VLIW, который бы не тормозил как сучка :D

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Так вот же, Эльбрус, свободная имплементация RISC-V от университета Англии сливает Эльбрус-8С.

На одном ядре он быстрее чем Ampere Altra Q80-30, хотя вот это не точно, пришлось через несколько цепочек сравнивать.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от anonmyous

Здрасьте… Киттсон в каком году вышел? А в каком - пульсон?

В 2017. Это было 7 лет назад в рамках поддержки. С тех пор итаниум окончательно закопан.

Kittson has no microarchitecture improvements over Poulson; despite nominally having a different stepping, it is functionally identical with the 9500 series, even having exactly the same bugs, the only difference being the 133 MHz higher frequency of 9760 and 9750 over 9560 and 9550 respectively.

January 2019: Intel announces Itanium’s end of life with additional orders accepted until January 2020 and last shipments no later than July 2021.

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

Забавно, что ни один Itanium не работал быстрее 2.6GHz. Хотя цеоны уже тогда за 3.5GHz ушли.

Когда? Пульсон - 2012 год. И работал на 2.5. Ну а дальше его уже существенно и не тянули, так как было понятно, что этот поезд ушёл.

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

anonmyous ★★
()
Ответ на: комментарий от liksys

В 2017. Это было 7 лет назад в рамках поддержки. С тех пор итаниум окончательно закопан.

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

anonmyous ★★
()
Ответ на: комментарий от MOPKOBKA
  1. Просто неинициализированная переменная - это вообще ошибка компиляции в Rust и ворнинг во всех вменяемых компиляторах С или плюсов. Так даже не интересно.
  2. Если у Эльбруса нет способа скастить указатель в число и обратно, то эта фича абсолютно неюзабельна для сколь угодно сложного кода. Скорее всего этот способ есть, так что и поле для косяков остаётся.
  3. x86 и UTF-8 нативно не поддерживает, меня это не беспокоит.
  4. В терминах языка это называется fat pointer, ничего не знаю. То, что он работает без необходимости использовать маргинальную платформу только плюс.
Mmmlmlm
()
Ответ на: комментарий от anonmyous

Напомню, что пульсон вышел в 12м.

Интервал между релизами вообще не смущает?

И никто тогда ещё закапывать итаник не собирался.

До-о-о-о #2. То-то крупные поставщики софта забили болт на него, а потом и сам интел в следующем году:

2009: Red Hat announces that it is dropping support for Itanium in the next release of its enterprise OS, Red Hat Enterprise Linux 6.

2011: Oracle Corporation announces that it will stop developing application software, middleware, and Oracle Linux for the Itanium.

2012: SAP discontinues support for Business Objects on Itanium.

2013: Intel cancels Kittson as a 22 nm shrink of Poulson, moving it instead to its 32 nm process.

2013: HP announces that its NonStop servers will start using Intel 64 (x86-64) chips.

liksys ★★★★
()
Ответ на: комментарий от MOPKOBKA

Так вот же, Эльбрус, свободная имплементация RISC-V от университета Англии сливает Эльбрус-8С.

лол а теперь сравни с x86 или arm

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от Mmmlmlm

Просто неинициализированная переменная - это вообще ошибка компиляции в Rust и ворнинг во всех вменяемых компиляторах С или плюсов. Так даже не интересно.

Аналог

char buf[1000000];
read(FILE, buf, 1000000);

в rust потребует инициализацию перед чтением? А какое предупреждение на это даёт компилятор Си?

monk ★★★★★
() автор топика
Ответ на: комментарий от Mmmlmlm

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

А зачем??? Указатель в число можно. А обратно по стандарту Си в любом случае UB.

monk ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

А еще я люблю сравнение Эльбруса-2СВ и МЦСТ-R2000. Вот где сравнение вообще не в пользу Эльбрусов. При схожей производительности, у R2000 энергопотребление в три раза меньше. Потому что волшебный компилятор не тянет оптимизировать код так же хорошо, как предсказатель, и все миллионы дополнительных транзисторов VLIW по сравнению с RISC висят мертвым грузом.

liksys ★★★★
()
Ответ на: комментарий от anonmyous

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

Itanium тут вообще не причём.

Запретили невыровненный доступ к памяти

Как и тут. Это старая фишка вообще всех процессоров, когда на шине памяти экономили.

навязывают стрикт алиасинг

Strict aliasing появился в C89, когда итаника даже в проекте не было. Только его никто не осилил, в лялексе больше половины проектов имеют -fno-strict-aliasing в флагах сборки.

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

Прогибают-прогибают, а они – твари такие! – не прогибаются!

hateyoufeel ★★★★★
()
Ответ на: комментарий от Mmmlmlm

Просто неинициализированная переменная - это вообще ошибка компиляции в Rust и ворнинг во всех вменяемых компиляторах С или плюсов. Так даже не интересно.

Выше разобрал, ты говоришь о простейшем случае.

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

Попробуй почитать стандарт С.

x86 и UTF-8 нативно не поддерживает, меня это не беспокоит.

Да вроде твое спокойствие и не обсуждали.

В терминах языка это называется fat pointer, ничего не знаю. То, что он работает без необходимости использовать маргинальную платформу только плюс.

Мне все равно как оно там называется в Rust, тебе должно быть тоже.

---

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от monk

А зачем??? Указатель в число можно. А обратно по стандарту Си в любом случае UB.

По какому стандарту? Вот этому?

7.18.1.4
Integer types capable of holding object pointers
The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

intptr_t

The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

uintptr_t

Когда-нибудь я таки начну с ЛОРовских сишников брать деньги за чтение стандарта вслух, ведь сами они не могут.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от monk

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от liksys

До-о-о-о #2. То-то крупные поставщики софта забили болт на него, а потом и сам интел в следующем году:

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

Это вообще никак не свидетельствует в пользу того, что пульсон был «плохим» или «тупиковым». Просто если ты выкатил что-то на 10 лет позже сроков, и упустил всех клиентов, то уже не важно, что ты там выкатил в конечном итоге: поезд ушёл.

Они скоро попробуют ещё раз: когда начнётся массовый исход с х86. Что именно они попробуют - неизвестно. Может, риск-5, а может - снова влив. Скоро узнаем.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

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

Нет, не правильно. Убедились они еще в 2013, когда порезали техпроцесс.

Они скоро попробуют ещё раз: когда начнётся массовый исход с х86. Что именно они попробуют - неизвестно. Может, риск-5, а может - снова влив. Скоро узнаем.

RISC, очевидно. Потому что VLIW доказал свою тупиковость для всех, кроме фанатов VLIW.

liksys ★★★★
()
Ответ на: комментарий от monk

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

Mmmlmlm
()
Ответ на: комментарий от hateyoufeel

Itanium тут вообще не причём.

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

Как и тут. Это старая фишка вообще всех процессоров, когда на шине памяти экономили.

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

имеют -fno-strict-aliasing в флагах сборки.

Так вот когда перестанут «иметь», то и влив взлетит. Чего непонятного то?

anonmyous ★★
()
Ответ на: комментарий от anonmyous

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

Они несут пользу для любой архитектуры.

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

Для любой архитектуры код работает быстрее при меньшем количестве обращений к памяти. Всегда ваш, Копетан Очевидность!

Так вот когда перестанут «иметь», то и влив взлетит. Чего непонятного то?

Не взлетит. Что непонятного-то?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от liksys

Нет, не правильно. Убедились они еще в 2013, когда порезали техпроцесс.

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

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

Они несут пользу для любой архитектуры.

Минимальную. А для влив - критическую.

Для любой архитектуры код работает быстрее при меньшем количестве обращений к памяти. Всегда ваш, Копетан Очевидность!

Но, однако же, даже АРМы, будучи рисками, всё таки решили поддержать невыровненный доступ на аппаратном уровне, чтобы производительность не проседала. По этому, она только у вливов будет от такого катастрофически проседать.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Минимальную. А для влив - критическую.

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

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

Алсо…

По этому

Иди русский язык выучи уже!

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonmyous

Я про это и говорил, если вы не заметили.

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

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

anonmyous ★★
()
Ответ на: комментарий от anonmyous

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

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

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

Mmmlmlm
()
Ответ на: комментарий от liksys

Это я об этом говорил. А ты говорил туманно про ушедший поезд и тряс ядром, вышедшим в 2017.

Понять, что поезд ушёл и клиентов уже не вернуть - можно и за 5-7 лет до закапывания проекта. Так вот, закопали они его в 17 или в 19, в зависимости от того, как считать. Но уж точно не после выпуска пульсона. А вот маркетинговый отдел убедился в том, что рынок безвозвратно утерян - в 13 году, что и сказалось на финансировании проекта.

anonmyous ★★
()
Ответ на: комментарий от Mmmlmlm

А проверка границ массива нет. Зачем решать аппаратно то, что решается на более высоком уровне абстракции, да еще и лучше?

Heartbleed некоторых ничему не научил...

X-Pilot ★★★★★
()
Ответ на: комментарий от hateyoufeel

Ведь кроме компилятора теперь нужен будет ещё и прогибатор!

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

Ровно то же самое происходило с мультикорками: стали появляться соотв камни, NPTL, убрали биг кернель лок, ОпенМП выкатили… И программеры подумали: чёрт, ну ок… Придётся, видимо, всё переписывать. :)

anonmyous ★★
()
Ответ на: комментарий от Mmmlmlm

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

Какое определение у «полноценной работы»?

MOPKOBKA ★★★★★
()
Ответ на: комментарий от anonmyous

Прогибатор - это те самые стандарты…

… на которые и программисты, и вендоры успешно кладут хер уже 30 лет.

Ровно то же самое происходило с мультикорками: стали появляться соотв камни, NPTL, убрали биг кернель лок, ОпенМП выкатили… И программеры подумали: чёрт, ну ок… Придётся, видимо, всё переписывать. :)

Нет, не то же самое.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от liksys

было бы странно, если бы создатели сабжа были бы не в курсе проблем с их творением ;)

bp123
()
Ответ на: комментарий от hateyoufeel

… на которые и программисты, и вендоры успешно кладут хер уже 30 лет.

Да нет, не кладут. Давно уже привили программерам культуру писать без варнингов и без всяких -fno-xxx. Это раньше, лет 20 назад, кому скажешь «добавь инклуд, варнинг же!», а тебе в ответ «а не пох на варнинг?». Сейчас большинство людей свои прожекты с -Werror собирают и прогоняют через убсан регулярно, который невыровненный доступ и прочую ересь не пропустит.

anonmyous ★★
()
Ответ на: комментарий от X-Pilot

Heartbleed случился потому что «мы ж кулхацкеры, у нас же не бывает ошибок с памятью». Даже в Си можно писать в стиле параноика с проверками на каждый чих, не говоря о современных языках. А такие зубры и в Эльбрусе наделают эксплойтов.

Mmmlmlm
()
Ответ на: комментарий от MOPKOBKA

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

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

Mmmlmlm
()
Ответ на: комментарий от anonmyous

Да нет, не кладут. Давно уже привили программерам культуру писать без варнингов и без всяких -fno-xxx.

Дядя, ты на linux.org.ru. Открой исходники ведра люникс и подивись -fwrapv, -fno-string-aliasing, вагону -Wno-xxx и прочим отходам от стандартов. Сам Торовалтос множество раз писал, что срал он на стандарты.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Дядя, ты на linux.org.ru. Открой исходники ведра люникс и подивись -fwrapv, -fno-string-aliasing, вагону -Wno-xxx и

Ядро - оно и в Африке ядро, это фристендинг энвайронмент. А кроме того, открыл, и, кроме -fno-strict-aliasing и -fno-delete-null-pointer-checks, ничего особо в глаза и не бросается. Если я правильно понимаю, со стрикт-алиасингом просто не всё пока так гладко в самом стандарте. Людям надо кастовать из байт-стрима в различные типы, а им говорят «используй мемкопи во временную переменную», что нифига не оптимизация. Над этим пока работают.

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

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

anonmyous ★★
()
Ответ на: комментарий от Mmmlmlm

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

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от anonmyous

А кроме того, открыл, и, кроме -fno-strict-aliasing и -fno-delete-null-pointer-checks, ничего особо в глаза и не бросается.

А этого типа мало?

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

Да нет, авторы стандарта на его мнение тоже клали член. Они вообще в своей особой реальности существуют.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer

Это на Эльбрусе работает.

А в обратную сторону и на GCC x64 не всегда: https://godbolt.org/z/r57164GKs

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Ну лол.. ты как раз в strict aliasing вляпался. У тебя UB и дело не в кастах.

Но если тебе так хочется срать в память, держи, я починил: https://godbolt.org/z/arqso9z5G

UPD: вот так работает даже с -O3 https://godbolt.org/z/KnP1P17E7

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от Second_Variety

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

Дооо, прогресс.

Восьмое поколение, надо полагать, вмотируют прямо в Cyberdyne Systems 101 серии 800.

mark1
()
Ответ на: комментарий от MOPKOBKA

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

Хм. Тогда вот еще кейс. Допустим я своём приложении создал mmap на 64 гигабайта, чтобы заменить всю работу с памятью на ультра-быстрый бамп-аллокатор и больше не морочить голову с malloc/free. Потому что, ну вы знаете, сейчас 2024 год, что мы зря 64-битные архитектуры придумывали. Получается, в таком случае Эльбрус меня больше не защитит? Если освобождение памяти - это просто уменьшение оффсета.

Mmmlmlm
()
Ответ на: комментарий от Second_Variety

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

mark1
()
Ответ на: комментарий от hateyoufeel

Нет. Если ты уберёшь преобразования из чисел, будет ровно то же.

Если я уберу преобразование, то *(int*)(&a-1) определённо UB, так как пытается получить доступ за пределы объекта.

monk ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

А этого типа мало?

-fno-strict-aliasing для влива, скорее всего, не мало, так как не позволяет осуществить довольно массовые сохранения небольших объектов в регистрах. Но, во первых, ядро есть ядро. А во вторых, с тайпкастами разбираются очень активно. Например, в с++23 ввели std::start_lifetime_as(). А гццшники встали в позу, и сказали «а нам пофиг на стандарт, мы тайпкасты поддерживать не собираемся». Ну и тд. Чтобы влив взлетел, всё это должно устаканиться.

anonmyous ★★
()
Ответ на: комментарий от Mmmlmlm

Получается, в таком случае Эльбрус меня больше не защитит?

Защитит от попытки читать незаписанную. Понятно, что любой указатель на этот массив сможет писать в любое место в этом массиве.

Если освобождение памяти - это просто уменьшение оффсета.

И после получения ранее использованной тоже не защитит.

Если очень хочется выстрелить себе в ногу, это можно сделать.

P.S. Вспомнилось, как на Фортране делали один глобальный огромный массив в COMMON блоке.

monk ★★★★★
() автор топика
Ответ на: комментарий от anonmyous

Ну и тд. Чтобы влив взлетел, всё это должно устаканиться.

Главное – это верить!

Готов поспорить на штуку баксов, что к 2030 году ни один VLIW чип не обгонит свежий x86 или ARM при аналогичных техпроцессе и потребляемой мощности.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Готов поспорить на штуку баксов, что к 2030 году ни один VLIW чип не обгонит свежий x86 или ARM при аналогичном техпроцессе и потребляемой мощности.

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

DrRulez ★★★★★
()
Ответ на: комментарий от hateyoufeel

Главное – это верить!

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

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

Готов поспорить что и любой другой отечественный процессор общего назначения, независимо от архитектуры, не обгонит свежий x86 или ARM при аналогичных техпроцессе и потребляемой мощности. Ни к 2030 ни к 2040 году. Вывод?

Second_Variety
()
Ответ на: комментарий от hateyoufeel

Безусловно. Но VLIW всё это никак не поможет.

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

И всё, и не придётся тогда ростелекому ковырять софт под эльбрусы.

anonmyous ★★
()
Ответ на: комментарий от Mmmlmlm

Допустим я своём приложении создал mmap на 64 гигабайта, чтобы заменить всю работу с памятью на ультра-быстрый бамп-аллокатор

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

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

Помимо этого защита от неинициализированной памяти.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от liksys

Однопоточная производительность https://7-cpu.com/:

R2000 @ 2000 MHz: 826 попугаев,  0.41 попугаев/MHz
E-8SV @ 1500 MHz: 1845 попугаев, 1.23 попугаев/MHz
E-16S @ 2000 MHz: 2553 попугаев, 1.27 попугаев/MHz

Вроде производительность на мегагерц у эльбрусов в 3 раза выше, чем у R2000. Про потребление там ничего нет.

iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 1)
Ответ на: комментарий от anonmyous

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

Нет, не видел.

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от iliyap

лол как они этого добились? E-16S в режиме эмуляции x86 оказался быстрее самого себя с нативным кодом! 2873 против 2553 попугаев. Нахер там этот VLIW, если x86 эмулировать быстрее выходит? Может проще тогда пойти путём Transmeta, сделать VLIW просто особенностью реализации и эмулировать какой-нибудь ARM?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от liksys

А разве x86-64 не в сторону широкого слова сейчас двигается? Сейчас в ядре есть несколько параллельных декодеров и их количество увеличилось в свежих архитектурах, эти декодеры питают несколько портов исполнительных устройств. Все это выглядит так что из одного потока инструкций внутри ядра формируются широкие слова и они уже исполняются. ARM-ядра растят производительность за счёт такого же подхода. Коренное различие в том, что у е2к нарезка на слова возложена на компилятор, который в теории может делать более эффективную нарезку, т.к. он оперируя исходным кодом лучше «видит» замысел программиста. Но ему недоступно микроархитектурное состояние ядра и это ограничивает возможности оптимизации раскладки микроопераций по исполнительным устройствам. Если делать нарезку на слова внутри железа ядра, то становится доступным состояние, но зато ядро видит перед собой деревья, но не видит леса

cobold ★★★★★
()
Ответ на: комментарий от cobold

VLIW по-моему ещё в полярисах были и копали крипту лучше чем x86 или arm

Конечно. Но речь в треде идёт о CPU, а не о видеокартах. Из видеокарт этот VLIW, кстати, тоже выпердолили к чертям в итоге. Не взлетает!

hateyoufeel ★★★★★
()
Ответ на: комментарий от cobold

Там же, где и видеокарты на x86.

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Это что за казацкий тверк начался? В исходном комменте речь была о чипе. Без разделения на cpu, general purpose cpu, видеокарты и вот это всё

cobold ★★★★★
()
Ответ на: комментарий от hateyoufeel

Нет, не видел.

Ну здрасьте: https://www.cnews.ru/news/top/2021-05-27_rostelekom_pomozhet_kompaniyam

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

Да это не влив, а эльбрус. А я про влив хотя бы уровня пульсона, где большинство проблем устранено.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Ну здрасьте: https://www.cnews.ru/news/top/2021-05-27_rostelekom_pomozhet_kompaniyam

cnews.ru/

Потому и не видел. И как, за три года он кому-то помог уже?

где большинство проблем устранено.

Только в фантазиях фанатов VLIW.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Вон смотри-ка, Elbrus в режиме x86 уделал сам себя в нативном!

Знакомьтесь - год 2000, проект HP Dynamo. Это эмулятор процессора PA-8000, работающий на этом же процессоре PA-8000, но с технологией JIT. И реальные программы, запускающиеся в эмуляторе - в итоге работают быстрее, чем на голом процессоре. Результаты повышения производительности доходили до +22%, в среднем по тестам получалось +9%.

vasya_pupkin ★★★★★
()
Ответ на: комментарий от vasya_pupkin

Вон смотри-ка, Elbrus в режиме x86 уделал сам себя в нативном!

Знакомьтесь - год 2000, проект HP Dynamo. Это эмулятор процессора PA-8000, работающий на этом же процессоре PA-8000, но с технологией JIT. И реальные программы, запускающиеся в эмуляторе - в итоге работают быстрее, чем на голом процессоре. Результаты повышения производительности доходили до +22%, в среднем по тестам получалось +9%.

Блин, это ж мечта гентушника! Можно будет одну и ту же прогу компилировать ни один раз, а аж два! Причём подряд!

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Только в фантазиях фанатов VLIW.

Да вы бы прочитали ссылку-то про пульсон. Реально ведь работа была огромная проделана. Практически все сталлы побеждены… Ну так, почти. :)

anonmyous ★★
()
Ответ на: комментарий от iliyap

Про потребление написано в одной из ссылок первых ссылок, что я писал на первой странице, на основе данных от МЦСТ.

liksys ★★★★
()
Ответ на: комментарий от cobold

Это вообще не то же самое - параллельное декодирование и одновременное исполнение пачки команд. Собственно, вся разница между VLIW и CISC в этом и состоит. В CISC эти блоки сами по себе и не требуют упаковки, и Out-of-Order-механизма позволяют эффективнее всем этим управлять, чем статическое планирование компилятором.

liksys ★★★★
()
Ответ на: комментарий от anonmyous

Добавляется еще одно ограничение, что commit/retire должен произойти для всего бандла, а не для единичной инструкции.

Ну, по крайней мере в пульсоне - да.

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

Вот это, реально, допрыгались. :) Мдя… Не сразу разглядел этот нюанс на 10 страницах описания архитектуры пульсона. :)

anonmyous ★★
()
Ответ на: комментарий от anonmyous

Да вы бы прочитали ссылку-то про пульсон. Реально ведь работа была огромная проделана. Практически все сталлы побеждены… Ну так, почти. :)

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Даже после всей этой огромной работы итаник дико просасывал.

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

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

Скорее всего из-за особенности vliw - жирный код. Узким местом становится доступ к ram. А у x86 в современном исполнении код компактный, а вся интерпретация варится внутри камня. Таким образом при эмуляции снижается зависимость от доступа к памяти

frost_ii ★★★★★
()
Ответ на: комментарий от liksys

R2000 @ 2000 MHz 8 ядер 36W, E-16S @ 2000 MHz 16 ядер 130W. Эльбрус жрет в 3 раза больше, но и попугаев даёт в 3 раза больше. Не вижу очевидных преимуществ у R2000.

К тому же у R2000 интегрирован только контроллер памяти и линк к чипсету, а E-16S полноценный однокристальник с контроллером памяти, PCIe 3.0, 10GbE, USB 3.0, SATA 3.0.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

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

frost_ii ★★★★★
()
Ответ на: комментарий от iliyap

R2000 @ 2000 MHz 8 ядер 36W, E-16S @ 2000 MHz 16 ядер 130W. Эльбрус жрет в 3 раза больше, но и попугаев даёт в 3 раза больше. Не вижу очевидных преимуществ у R2000.

Смотри внимательно, я писал про 8SV, который современник R2000. Не надо сравнивать чипы разных поколений. Так вот спарк одного с эльбрусом поколения более экономичный.

liksys ★★★★
()
Ответ на: комментарий от Somebody

Да тут не нужно быть Вангой. Человек выставляет Эльбрус образцом плохого, негодного процессора, при этом примера хорошего отечественного процессора, способного в перспективе обогнать современный ему х86 или АРМ он почему-то не привёл. Из чего напрашивается закономерный вывод: на какой бы архитектуре не были выполнены отечественные процессоры – они всегда будут уступать своим зарубежным соперникам, а значит все они плохие и их разработку следует прекратить, всех без исключения.

Second_Variety
()
Ответ на: комментарий от Second_Variety

Да тут не нужно быть Вангой

Но они будут! :))

Из чего напрашивается закономерный вывод

Да, это обычное дело для определённой категории граждан. Но зато есть повод поспорить... ;)

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

Somebody ★★
()
Ответ на: комментарий от liksys

В CISC эти блоки сами по себе и не требуют упаковки, и Out-of-Order-механизма позволяют эффективнее всем этим управлять, чем статическое планирование компилятором.

Как out-of-order может быть эффективнее, если информации у него меньше, чем у компилятора (процессор видит только очередь инструкций) и времени на алгоритм оптимизации намного меньше (выбор операции надо сделать за 1 такт)?

monk ★★★★★
() автор топика
Ответ на: комментарий от frost_ii

Скорее всего из-за особенности vliw - жирный код. Узким местом становится доступ к ram.

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

monk ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Из видеокарт этот VLIW, кстати, тоже выпердолили к чертям в итоге.

Уже обратно впилили огрызок в виде «dual issue». :)

numas13
()
Ответ на: комментарий от liksys

Потому что VLIW доказал свою тупиковость для всех, кроме фанатов VLIW.

Тупик – это когда дальше нет хода. Совсем. Очень сомневаюсь, что VLIW это тупик. Если это тупик, то все технологии – тупик. Поздно или рано.

А ещё сомневаюсь, что есть какие-то мифические «фанаты VLIW». Есть сочувствующие отечественной микроэлектроники.

rechnick ★★★
()
Ответ на: комментарий от rechnick

А ещё сомневаюсь, что есть какие-то мифические «фанаты VLIW».

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

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

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

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

rechnick ★★★
()
Ответ на: комментарий от rechnick

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

Всякое может быть. Ту же самую технологию ведь и в x86 можно использовать, но руки ни у кого не дошли (Microsoft Research сделала Singularity, но дальше ядра дело не дошло).

monk ★★★★★
() автор топика
Ответ на: комментарий от frost_ii

Да, под это Риск5 как раз и заточен

А в Риск5 разве есть возможность указать процессору порядок предвыполнения инструкций? Или ты хотел написать VLIW?

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Если брать вместо байткода Риск5, то там инструкций не хватает.

monk ★★★★★
() автор топика
Ответ на: комментарий от frost_ii

А этим будет заниматься аппаратный планировщик

Аппаратный планировщик всегда хуже программного. Он видит меньше контекста (буквально несколько десятков инструкций), у него гораздо жёстче требования по скорости (JIT компилятор может выполнять алгоритм тысячи тактов, а аппаратный обязан за один такт выдать решение на столько инструкций, сколько можно выполнить параллельно).

monk ★★★★★
() автор топика
Ответ на: комментарий от frost_ii

Тем не менее эмуляция х86, где тоже нет порядка, исполняется на эльбрусах быстрее

Там как раз JIT компиляция. Как в OS Singularity.

Можно также транслировать RISC V. Но эффективней какой-то свой байткод.

E-16S в режиме эмуляции x86 оказался быстрее самого себя с нативным кодом! 2873 против 2553 попугаев.

Это как раз про сравнение двух компиляторов. Один из Си, второй из x86.

monk ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.