LINUX.ORG.RU

Опубликована система команд Эльбрус

 


1

4

http://elbrus.ru/efficient_elbrus_programming_book_2020-05

Кто хочет написать свой компилятор или доработать gcc/clang/whatever — велкам!

ЗЫ Кто хочет написать новость - тоже велкам.

Перемещено Zhbert из linux-hardware

★★★★★

Ответ на: комментарий от Aceler

Может быть так.

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

Уф, …

Владимир

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

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

Да и сами термины придумали ещё в 60-х и они тоже могли устареть.

Сколько компиляторов написал?

Ноль, а зачем?

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

Да и сами термины придумали ещё в 60-х и они тоже могли устареть.

Wiki часто «шпарит» определениями 60-х, да еще претендует на «правильность».

Владимир

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

Сколько компиляторов написал?

Ноль, а зачем?

И мы о том же - а зачем? Ни нормального определения, ни открытости, ни зелени, ни деревяных. Мотивации, понимаешь ли, нет.

Вот если бы ты написал и взял бы нас на «слабо». Вот тогда бы была мотивация.

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

Wiki часто «шпарит» определениями 60-х, да еще претендует на «правильность».

ИМХО метаданные в понимании wiki это скорее полное непонимание
того каковы бывают метаданные и чем они могут быть полезны /template C++ - «верх понимания»/.
Типа

Метаданные это .... - ОГОГОООООООО!

Владимир

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

Вот если бы ты написал и взял бы нас на «слабо». Вот тогда бы была мотивация.

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

Вот если кто-то хочет компилятор делать — пусть делает, я помогу.

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

Компилятор это

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

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

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

Это очень емкая тема.
«Нельзя объять, необъятное».

Да и то, что принято называть компиляцией «не гранитный памятник».

Владимир

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

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

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

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

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

Никаких «специализированных процессоров нет». Просто есть те области, в которых требования выше

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

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

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

Да и реальности основным потребителем цпу являются не числодробильни.

и-мен-но. и потому никто в здравом уме не делает CPU на VLIW. и никто в здравом уме не называет тот же С66х - CPU. не смотря ни на наличие MMU, ни на имеющийся порт линукса на него.

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

да-да, настолько хорошо что его даже из GPU выкинули нафиг ввиду бесперспективности :)

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

Полная чушь. х86 обладает таким же уровнем параллелизма.

нет, х86 - до 4 команд за такт шедулит при определенных условиях.

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

я вообще-то про ущербный VLIW…

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

неветвящийся код - он только в примитивных числодробильнях

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

которые никто в здравом уме на CPU не считает - есть гораздо более эффектвные примитивные чипы под это дело.

И на эту чушь я отвечал. Никаких «числодробилен» нет, как и никаких чипов под них как и никакой в них примитивности.

халва, халва… требования в специализированных чипах нифига не выше.

Выше.

вернее, там одно требование - тупая примитивная архитектура

Зачем ты повторяешь одну и ту же херню, на которую ответ мною уже дан?

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

Опять же херня, на которую уже дан ответ. Заявление болтуна никак не соотносится с дествительностью.

хотя в GPU уже тоже от VLIW отказались, ввиду его бесперспективности.

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

Все гпу вливы. По определению.

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

Опять нету ответа и опять какой-то лузунг от эникея, который нихрена не понимает. И который игнорирует данный ему ответ.

и-мен-но. и потому никто в здравом уме не делает CPU на VLIW.

Это сарказм, маня. Основные потребители ЦПУ - числодробильны. Ты опять обделался.

и никто в здравом уме не называет тот же С66х - CPU. не смотря ни на наличие MMU, ни на имеющийся порт линукса на него.

Меня мало волнует, что «думают» какие-то там эникеи.

да-да, настолько хорошо что его даже из GPU выкинули нафиг ввиду бесперспективности :)

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

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

нет, х86 - до 4 команд за такт шедулит при определенных условиях.

Ты опять опозорился. Срочно за букварь.

я вообще-то про ущербный VLIW…

О боже, насколько нелепые потуги. Гений мне рассказывал, что уровень параллелизма в <10 - это ненужно. Это избыточно и ко-ко-ко. Но почему-то интел её наращивает кажрый раз и там она уже более нескольких сотен.

Да, наш гений действительно эксперт. Типичный.

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

нет, не JIT. JIT - это компиляция в машинный код перед выполнением.

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

Он так же собирает код спекулятивно, так же выбирает «ветки».

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

Так же я тебе сообщал, но сообщу ещё раз. Основная сложность там именно в спекулятивности. А они никакого отношения к суперскаляру не имеет. И она так же есть и в эльбрусе.

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

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

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

Ах да, сообщу тебе про amd и влив. Влив там как был так и остался, но.

Я тебе уже сообщал о зависимом/независимом параллелизме. Дак вот, ещё одна тайна - зависимый параллелизм - самый простой и дешевый. И о чудо - влив - он независимый. И суперскаляр независимый.

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

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

Но и к тому же, амд не отказался от влива. Просто вся параллельность сброшена на симды(к тому же шейдеры/оцл имеют ту же симдовую природу. Пишется один кусок кода, который один и тот же запускается на множестве исплнителей. Код один by-design).

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

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

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

дадада, тупой примитивный VLIW уже оказывается научился во внеочередное исполнение :) ох уж эти иксперты-сказочники :)

Никаких предсказателей ветвлений не существует, к тому же они никакого отношения к суперскаляру не имеют. Да и предсказать ветвление невозможно.

существует. имеют самое прямое. вполне возможно - успешность более 90% на х86.

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

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

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

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

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

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

Ога. Не С++, гцц 4.4 - уровень познаний поражает, опять же.

да, не С++ чтобы смотреть именно оптимимизацию под архитектуру, а не оптимизацию работы с объектами (которая к архитектурным оптимизациям никакого отношения не имеет). а Gcc 4.4 - ну чтобы лет 7 как протухший, +- ровесник сэнди бриджа. ну чтобы оценить прогресс в софтовой оптимизации, и сравнить с прогрессом в кремнии.

Да ты чё, а пацаны с видяхами, с армами не знали. видяхам не надо исполнять чужой бинарный код, у них шейдеры в байткод на лету конпеляются, как и GPGPU код. ввиду примитивности что процов, что кода - это прокатывает; на CISC такое пытались внедрить - родился андроид простигосподи, который все равно без native libraries никуда…

ну и да, на армах ABI никуда не ломается, что A5, что A15 допустим - одно и то же ABI, хоть первый - обычный скалярный проц, второй - 3-way OoO с кучей исполнительных блоков. и на А72 код, скомпиленый под какой-нить А5, пойдет прекрасно. для VLIW такой финт в принципе не прокатит.

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

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

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

Ветвящийся код - код дошколят. Это свойство низкой квалификации, а не чего-то ещё.

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

Выше.

нет. иначе бы не лепили туда 100500 тупых ядрышек.

Опять же херня, на которую уже дан ответ. Заявление болтуна никак не соотносится с дествительностью.

опять иксперд газирует лужи. х86 ограничен по производительности лишь TDP и геометрическими размерами ядер. почему тупых DSP и лепят по 100500 ядрышек на кристалл, а х86 - максимум 28 что ли, пушо больше - дорого и очень горячо.

Основные потребители ЦПУ - числодробильны.

нет, в числодробильнях давным-давно рулят tesla и firepro. интел пыталась туда влезть со своей larrabee - но в очередной раз лишь опказала что ЦП, пускай и кастрированные, для числодробилен не особо годятся.

Меня мало волнует, что «думают» какие-то там эникеи.

дадада, для вас и C66x - CPU, да, иксперд вы наш? :)

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

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

вот только во VLIW это все ограничено довольно куцым словом команд - и «какой угодно сайд эффект» туда не упихать, когда всего-то 3-4 команды в слове. и даже при 8 командах (с кучей ограничений и оговорок) это печально. итог - при 8 командах на такт ipc и до 2 не дотягивает в сколь-либо сложных задачах (про тупое перемножение матриц ессно не говорим - никто в здравом уме это на ЦП не считает).

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

я ставлю

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

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

дадада, тупой примитивный VLIW уже оказывается научился во внеочередное исполнение :) ох уж эти иксперты-сказочники :)

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

Ты бы хоть пошёл их книжку почитал. Балабол.

существует. имеют самое прямое. вполне возможно - успешность более 90% на х86.

Опять потуги уровня «умеют потому что умеют», какие-то нелепые цифры 90% непонятно что значащие и откуда взятые(из рекламных агиток для домохозяек), которые ничего не значат и смысла не имеют.

это все непосредственно к суперскаляру, да.

Нет, ты опять перданул в лужу.

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

Опять же - за букварь. Ничего этого знать не нужно.

а vliw-у - да, оно нахрен не надо ввиду его примитивности и убогости :)

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

никакие потоки вычислений суперскаляр не строит, не несите чушь.

Да, эникей то явно лучше всех, к том числе и меня знает.

он «всего лишь» выполняет те последующие инструкции

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

которые не завязаны на результаты уже помещенных на исполнение.

Никаких помещений нет, никаких «уже помещённых» нет, к тому же это полная херня.

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

Потому как никаких х86-регистров не существует и никаких таблиц соответствий никто не хранит, да и их невозможно реализовать.

и да, этим занимается планировщик - которого в VLIW в принципе нет.

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

К тому же, никакого планировщика в суперскаляре нет и быть не может.

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

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

да, не С++ чтобы смотреть именно оптимимизацию под архитектуру,

Ты опять опозрился. Примеры приведены были.

а не оптимизацию работы с объектами (которая к архитектурным оптимизациям никакого отношения не имеет).

Зачем эникей пытается рассуждать об языках, С++ и компиляторах, о которых нихрена не знает?

а Gcc 4.4 - ну чтобы лет 7 как протухший, +- ровесник сэнди бриджа.

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

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

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

ну и да, на армах ABI никуда не ломается, что A5, что A15 допустим - одно и то же ABI, хоть первый - обычный скалярный проц, второй - 3-way OoO с кучей исполнительных блоков.

Какие же жалкие потуги балабол предпринимает. Вспомнил древнее говно аккурат под смену abi. И да, куда видяхи то дел? Чего не ответил?

и на А72 код, скомпиленый под какой-нить А5, пойдет прекрасно. для VLIW такой финт в принципе не прокатит.

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

К тому же, потуги уровня «не прокатит» имея реальный эльбрус на котором прокатывает - это сильно.

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

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

Твоя шиза никакого отношения к реальности не имеет.

просто, тупо и примитивно.

Ога.

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

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

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

Совместимости сверху вниз нигде нет. Снизу вверх - не является проблемой. К тому же она у них есть. Да и у них есть бинарная трансляция.

Древнему дерьму нужно иметь одну возможность - запускаться. Запускаться оно может хоть в виртуалке. Всем насрать.

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

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

Нет, почитай букварь.

нет. иначе бы не лепили туда 100500 тупых ядрышек.

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

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

опять иксперд газирует лужи. х86 ограничен по производительности лишь TDP и геометрическими размерами ядер.

Ты опять обгадился. Срочно за букварь.

почему тупых DSP и лепят по 100500 ядрышек на кристалл

Никаких 100500 ядрышек нет. Тебя обманули.

а х86 - максимум 28 что ли, пушо больше - дорого и очень горячо.

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

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

нет, в числодробильнях давным-давно рулят tesla и firepro.

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

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

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

интел пыталась туда влезть со своей larrabee - но в очередной раз лишь опказала что ЦП, пускай и кастрированные, для числодробилен не особо годятся.

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

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

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

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

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

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

Никакой проблемы нет. А почему же он этого не сделал?

дадада, для вас и C66x - CPU, да, иксперд вы наш? :)

Потуги достойны. Сектант орёт «Ты поклоняешься дерьму или моче? Для меня дерьмо - бог.», на что получает ответ «мне насрать на твои потуги и на то, что то чему ты там поклоняешься». И после начинает орать «ко-ко-ко, для тебя моча бог? Как ты мог».

Нет, маня. Это твоя шиза, это разделение возникло лишь как следствие твоей несостоятельности. В реальности этого не существует, для меня этого не существует.

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

вот только во VLIW это все ограничено довольно куцым словом команд

Какая-то шизофазия.

и «какой угодно сайд эффект» туда не упихать

Ещё большая шизофазия.

когда всего-то 3-4 команды в слове.

Какое слово, какие команды. Ты пришёл, родил какую-то херню нелепую и на базе её производишь какие-то выводы.

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

и даже при 8 командах (с кучей ограничений и оговорок)

Подожди, ты там выше балаболил, что у х86 их 4, а теперь тебе не хватает восьми?

К тому же, ты там ещё до этого балаболил, что их там много и вообще можно пихать их дохрена и их куда больше, чем в х86.

итог - при 8 командах на такт ipc и до 2 не дотягивает в сколь-либо сложных задачах (про тупое перемножение матриц ессно не говорим - никто в здравом уме это на ЦП не считает).

Опять какие-то сложные задачи, ipc и прочая чушь.

Тебе нужно отвечать про спекулятивность. Попытайся ещё раз.

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

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

на VLIW - да, не существует, пушо планировщика не существует. на OoO - вполне себе существует.

Опять потуги уровня «умеют потому что умеют», какие-то нелепые цифры 90% непонятно что значащие и откуда взятые(из рекламных агиток для домохозяек), которые ничего не значат и смысла не имеют.

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

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

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

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

Какие же жалкие потуги балабол предпринимает. Вспомнил древнее говно аккурат под смену abi. И да, куда видяхи то дел? Чего не ответил?

не было никаокй смены ABI. было расширение ABI новыми командами, да. которое на голом тупом VLIW в принципе невозможно.

ну и да, не нравится пример - так код что на А53, что на А72 один и тот же работает. не смотря на разное кол-во исполнительных блоков, да. повторюсь, с VLIW такой финт не прокатит - ибо VLIW в роли ЦП это примитивная тупая архитектура для идиотов, не сумевших в суперскаляр.

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

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

На мобилках жава, либо сборка под десяток вриаций армов.

жава, лол. да ни в одной сколь-либо сложной андроид софтине не обходится без нэйтив библиотек. а их там ажно всего 2 варианта: под ARMv7 (32бит) и ARMv8 (64бит) abi. всё. крайне редко - экзотика типа х86 или мипс еще конпеляется. и похрен, какие там ядра - хоть а53, хоть а57, хоть а72, хоть а77, хоть вообще какая-нить тегра - всё это ARMv8, да.

а теперь представьте что там будет 100500 вариаций недопроцессоров на VLIW, каждый из которых друг с другом принципиально несовместим - пушо разное кол-во EU, и разное ABI соответственно…

Снизу вверх - не является проблемой. К тому же она у них есть. Да и у них есть бинарная трансляция.

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

Древнему дерьму нужно иметь одну возможность - запускаться. Запускаться оно может хоть в виртуалке. Всем насрать.

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

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

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

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

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

Интел никуда не лез.

дадада, larrabee не было, ничего не было, был только один могучий vliw, весь потанцевал которого до сих пор никто не разглядел, идиоты такие :)

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

на VLIW - да, не существует, пушо планировщика не существует. на OoO - вполне себе существует.

Нигде не существует.

нет, это у вас таки тут потуги показать всем, какой же перспективный в теории будет VLIW

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

К тому же, тебе сообщили, что современный суперскаляр на 90% «влив». Всё уже давно доказано и признано, но эникей увидев в интернете пару агиток решил срывать покровы.

вот как только изобретут волшебный конпелятор

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

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

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

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

Опять шизофрения пошла. Моя нога даст 95%, все вероятности я итак знаю. А какие не знаю - их не знает и bp.

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

только по факту это не более чем фантазии.

Да, это потуги рандомного эникея.

и VLIW - так и останется маргинальной архитектурой

Ога, влив это всё к чему предъявляются какие-то требования. Влив - это 2 последних десятка развития суперскаляров.

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

Ога.

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

Да, познания эникея о сложных алгоритмах безграничны.

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

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

дадада, ничего этого нет, и планировщик не планировщик, и OoO не внеочередное,

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

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

Т.е. влив так же OoO, представляешь?

есть один только VLIW, который вообще нагибает все и всех

Да.

но пока еще нет - надо подождать только волшебный конпелятор, он наступит уже вот-вот, и вот тогда… :рукалицо:

О боже, эникейщик, ты опять несёшь эту херню? Какой ещё, нахрен, компилятор?

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

жава, лол. да ни в одной сколь-либо сложной андроид софтине не обходится без нэйтив библиотек.

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

а их там ажно всего 2 варианта: под ARMv7 (32бит) и ARMv8 (64бит) abi.

Подожди, трепло. А как же совместимость, как же «нельзя поменять abi»? Ты обгадился что-ли? Поменяли и без проблем.

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

всё. крайне редко - экзотика типа х86 или мипс еще конпеляется. и похрен, какие там ядра - хоть а53, хоть а57, хоть а72, хоть а77, хоть вообще какая-нить тегра - всё это ARMv8, да.

Очередные ахренительные познания эникея. Что ты балаболил?

ну и да, на армах ABI никуда не ломается, что A5, что A15 допустим - одно и то же ABI

А теперь вдруг всё забыл. Абсолютно неважно то, что новое ядро обратно совместимо с базой. abi у них различаются, а то, что abi старого подмножество нового - ничего не значит.

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

а теперь представьте что там будет 100500 вариаций недопроцессоров на VLIW

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

каждый из которых друг с другом принципиально несовместим

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

  • пушо разное кол-во EU, и разное ABI соответственно…

Нет, срочно в школу.

нет совместимости снизу вверх.

Совместимость никому не нужны. Ты уже обделался с этим выше. К тому же влив никак не противоречит её наличию.

есть костыли типа бинарной трансляции,

Не, я уже не могу.

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

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

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

Эникей нам сообщает, что бинарная трансляция костыль, тормозит и вообще «фу» и нужна для мусорного влива. Таким образом - х86 - это костыльное говно с эпичными тормозами и это главная причина - почему всё не на нём.

Потому как обратная совместимость там реализовано именно бинарной трансляцией. х86 в принципе не умеет в 95% своих инструкций и они онлайн бинарно транслируются в зашитые в микрокоде их имплементации.

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

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

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

И что самое интересное - именно из-за неё он и тормозит. И так много той самой электроэнергии жрёт. Хотя проблема, как я уже говорил, не в самой бинарной трансляции.

minihic112 ()

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

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

  1. По поводу производительности на простых задачах.

Эльбрус рвёт x86 как тузик Грету, на задачах, требующих большого количества простых вычислений и допускающих параллелизм. Например, задачах распознавания образов, потокового шифрования по ГОСТ, потокового сжатия и дедупликации. ПАК по распознаванию рукописных заявлений для МФЦ или комплекс для СХД на базе процессоров e2k создавали, исходя из этих особенностей.

Собственно, изначальные заказчики архитектуры, в лице военных, этого и хотели. 2C+, который изготавливается в России по архитектурным нормам, прости господи, 90 нм (300МГц), очень неплохо справляется с задачей распознавания целей в составе радаров.

  1. По поводу невозможности расширения ABI.

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

По производительности, например, 7z, собранный для v3, работал на процессоре v4 на один процент примерно медленнее, чем 7z, собранный для v4. Если там и бинарная трансляция, её что-то не видно.

  1. По поводу «сдувания производительности на сложных алгоритмах».

Я не знаю, какие алгоритмы считать сложными, но если речь идёт просто об обычных задачах, то давайте возьмём процессоры, сделанные по одинаковой технорме. Для Эльбрус-8СВ аналогом от Intel тогда будет Sandy Bridge. Вполне себе сопоставимы они по производительности, не смотря на более высокие тактовые частоты у Intel.

То есть отставание современных процессоров e2k от современных процессоров x86 обусловлено техпроцессом, а не архитектурой.

  1. По поводу умного компилятора/тупого процессора.

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

  1. Ещё мысли.

В эльбрусах аппаратная защита указателей. Это не связано с VLIW, реализовать VLIW можно и без этого, это связано с безопасностью, но сказывается и на производительности, а также на сложности портирования ПО с сохранением оптимизаций. К примеру, реализация GC это боль и печаль, Java для E2k делали очень долго. Отсюда и сложности с JIT компиляцией.

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

Let the srach continue.

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

Пытавшиеся объяслянли что llvm никак не подходит для трансляции в vliw.

Ещё инсайдов: по сообщениям в прессе, прямо сейчас в МЦСТ пилят llvm для e2k. Ожидаемый срок поставки, впрочем, неизвестен.

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

В эльбрусах аппаратная защита указателей.

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

Владимир

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

Обсуждение в стиле «в голове моей бигуди, а на большее ты не рассчитывай» не имеет смысла.

Да и «теоретизирование» без реального опыта использования Эльбрус - смешно.

Владимир

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

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

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

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

сопоставимы

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

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

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

одинаковой технорме

нет там никакой «одинаковой технормы». эльбрус производится на технорме 2020г, сандибридж производился по технорме 2011г. причём в условиях отсутствия конкуренции (амуде на тот момент не являлась конкурентом) и потому намеренно был ограничен маркетологами, тк не было смысла выпускать например 20ядер бустящих до 5ггц, хотя возможно было

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

Насколько я помню из презентации (и от Юрьева), МЦСТ решили транслировать IR от llvm в IR для lcc и собирать так. Потому что оптимизатор LLVM делался под CISC/RISC и натягивать его на LLVM можно, конечно, но возьни много, а результат крайне отстойный и апстрим не примет (был же уже прецедент с написанием бэкенда для IA-64, адское было УГ).

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

SkyMaverick ★★ ()