GCC для «Эльбруса»

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

Т.е. OoO всё равно статическое, просто выполняется часто. Мне на первый взягляд не кажется, что это даст выгоды по скорости в сравнении с родным аппаратным OoO. Хотя, конечно, цифры покажут.

Т.е. OoO всё равно статическое, просто выполняется часто. Мне на первый взягляд не кажется, что это даст выгоды по скорости в сравнении с родным аппаратным OoO. Хотя, конечно, цифры покажут.

Это всё компромисс, они походу таким образом экономят на транзисторах/тепловыделении. Если интересно, можешь почитать более развёрнутый вариант. https://www.anandtech.com/show/8701/the-google-nexus-9-review/4 Там же и бенчи есть. Хотя бенчи могут не отражать всей сути, т.к. размер кеша под внутренний код ограничен, а что если его не хватит на все программы.

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

Вы просто не понимаете суть этого самого risc5 Это банальная роялтифри isa что бы избавится от бремени покупки ARM лицензий. Она должна спокойно налазить на существующие процессоры (вроде снапдрэгона). Большие дяди из крупных компаний вообще очень любят консорциумы и не любят лишнее платить https://aomedia.org/about/

А c:

В чём смысл сравнивать не сравниваемое?

Полностью согласен.

МЦСТ не разрабатывает фронтенд, поэтому непосредственно их поддержкой не занимается. Сейчас большая часть фич C++17 поддержана штатным фронтендом.

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

https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/ Проще было бы с софтом, не надо морочиться с самим LLVM

проприетарному процу, проприетарный компилятор.

Сейчас есть прототип конвертера из LLVM IR в EIR (Эльбрусовское представление), он пока выполнен чисто как proof of concept, но кое-какие задачи из SPEC на нём ходят.

А, тогда вопрос отпадает, молодцы (я, думал самый умный)

Раз фронтенд чужой, он ведь наверняка вам то же какое-то свое представление опять таки дает, в чем разница?

В трудозатратах. Существующая связка отлажена, работает, есть платная поддержка (!). LLVM IR несколько отличается от представления lcc, для него нужно дорабатывать внутренние компоненты, с нуля всё отлаживать.

А почему вы не хотите просто LLVM IR выдаваемый фронтендом точно так же перегонять в свой IR и дальше компилировать как по вашему?

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

Найс фейлософские манявры. «Не можешь объяснить суть в пяти словах школьнику - сам не понимаешь». ©

А что на счёт портирования какой-нибудь виртуальной машины в обозримом будущем?

А что на счёт портирования какой-нибудь виртуальной машины в обозримом будущем?

Виртуальными машинами занимается отдельная организация, они и jvm, и какую-то для js, и для c# портируют.

Я про виртуальные машины в свете этой темы.

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

А портирован ли WINE под «Эльбрус»?

А портирован ли WINE под «Эльбрус»?

Нет

СК не выкладывается скорее по политическим причинам

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

Ещё такой вопрос: почему нет порта «Зари» под «Эльбрус»? Под x86, x86-64, POWER7, IBM System z порты имеются, а под «Эльбрус» нет.

Потому что «Заря» все.

С чего это вдруг?

Я так понял, смысл твоего посыла, что разработчики Эльбруса - боги, остальные - говно.

лучший комментарий.

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

Существующая связка отлажена, работает, есть платная поддержка (!). LLVM IR несколько отличается от представления lcc, для него нужно дорабатывать внутренние компоненты, с нуля всё отлаживать.

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

вы так написали будто бы это ни с того ни с сего проблема появилась. «ой! чтоже делать?! нужно ОПЯТЬ всё разрабатывать с нуля!»

на сегодняшний момент Эльбрус существует только чтоб пилить буджет.. и как только Царя вилами снимут с трона — про Эльбрус (В НЫНЕШНОМ ВИДЕ) все забудут.

ни на о каких военных можете даже не мечтать (после этого) — потому что военные статьи расходов мгновенно урежут (сразу после инцидента с вилами).

вполне всем очевидно (но только вам похоже не очевидно?) что для ДОЛГОИГРАЮЩИХ перспектив жизни Эльбруса — нужна ПЕРВЫМ делом это интеграция в апстримы: GCC, kernel.org , LLVM .

даже если это будет медленный НЕЭФФЭКТИВНЫЙ код — всё равно это обязательный этап.

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

# P.S. и ПРЕКРАТИТЕ повторять одно и тоже про ваш уникальный путь и про неправильную архитектуру GCC/LLVM относительно VLIW .. да — работать будет крайне медленно — но это ОБЯЗАТЕЛЬНЫЙ набор инструментов.. даже в случае их медленной работы.

# P.S. и ПРЕКРАТИТЕ повторять одно и тоже про ваш уникальный путь и про неправильную архитектуру GCC/LLVM относительно VLIW .. да — работать будет крайне медленно — но это ОБЯЗАТЕЛЬНЫЙ набор инструментов.. даже в случае их медленной работы.

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

ну тык «работать медленно» и «вообще вообще нихрена не работает» — это огромная пропость

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

Есть стандарт на язык. Поддерживать васянские расширения не надо. Это только увеличивает фрагментацию. Из-за этих васянов ядро до сих пор не собирается через clang. Vendor lock от цитадели швабодки. Кто бы мог подумать.

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

MSVC нормально живёт и собирает 99% виндового софта. Сравни долю винды и линукса на пк и поймёшь так ли важно соблюдение святых гнушных расширений.

ни на о каких военных можете даже не мечтать (после этого) — потому что военные статьи расходов мгновенно урежут (сразу после инцидента с вилами).

А потом заплатят и покаются. А остальные деньги раздадут креаклам. Всё так и будет, Маня.

для ДОЛГОИГРАЮЩИХ перспектив жизни Эльбруса — нужна ПЕРВЫМ делом это интеграция в апстримы: GCC, kernel.org , LLVM .

Разрабы уже отвечали. Часть интеллектуальной собственности принадлежит сторонним конторам. Они не могут сами распоряжаться этой частью. По этой же причине другие проприетасты (вроде хуанга) не открывают исходники дров. Амд вообще с нуля начали пилить дрова, а не открыли прошлые. Как по-твоему, у хуанга есть «ДОЛГОИГРАЮЩИЕ перспективы жизни»? Выходит что нет. Жаль.

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

оооо! супер секретные разработки.. (и такие надутые щёки!)

ды кому они нафиг нужны до тех пор пока процессоры проигрывают ширпотребу (intel, amd, rasspberry pi)-- по ВСЕМ параметрам :-)

боитесь что украдут?

или проблема в том что например тот же аналог Spectre может быть в процессорах e2k тоже но в отличии от x86 — реализовываемый через компилятор, а не аппаратно?

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

Я не вижу особо сильного переписывания в ALT Sisyphus. Видимые патчи с пометкой E2K достаточно примитивны. Может, конечно, есть что-то большое и неопубликованное...

ды кому они нафиг нужны до тех пор пока процессоры проигрывают ширпотребу (intel

У Intel есть Itanium, который тоже проигрывает ширпотребу. И если, вдруг, дело только в компиляторе... Так, просто мысли вслух.

может тебе просто скинуть минимальный пример некомпилируемого кода со ссылкой в документаци (где сказано чтот он работать должен)?

или что хотел сказать? что проблемы такой нет? или что даже если есть — то никого она не интересует (нет переписки)?

или ты хотел сказать что расширения GNU-C не нужны?

У Intel есть Itanium, который тоже проигрывает ширпотребу

И поэтому он умер при рождении.

In a 2009 article on the history of the processor — «How the Itanium Killed the Computer Industry» — journalist John C. Dvorak reported «This continues to be one of the great fiascos of the last 50 years».

Есть стандарт на язык.

ну есть стандарт, а есть.GCC с GNU-C-расширениями.

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

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

при этом clang/llvm у тебя ни кто НЕ отнимает — бери и пиши свои программы хоть на clang/llvm хоть на вообще на Microsoft Visual Studio :-) ..

нахождение clang/llvm в системе НЕ заставляет тебя удалить gcc — они паралельно могут жить вместе :-)

или что хотел сказать? что проблемы такой нет? или что даже если есть — то никого она не интересует (нет переписки)?

Я хотел сказать, что, в реальности, «в стабильной ветке портируемого репозитория наработано более 6100 исходных пакетов»: https://www.altlinux.org/Ports/e2k

А у тебя теория какая-то.

И поэтому он умер при рождении.

Паффтаряю: может они просто не осилили компилятор.

За 20+ лет (история EPIC началась в 1989) за дофигальярд убитых енотов две весьма известные ИТ компании (при участии и сообщества — gcc же умеет ia64) не осилили.

сколько из этих пакетов написал ты? сами прогоаммы.

ты понимаешь что ты мне как творцу запрещаешь использовать расширения GNU, в случае если бы я хотел БЫ свои поделки использовать в Эльбрусе?

повезло что что мне не нужна поддержка Эльбруса, а достаточно обычного linux (x86-32 x86-64 aarch...) там всё работает.

на кой хрен мне твои 6100 пакетов, если именно нужного среди них не было бы? :-)

вот я удивояюсь: я вам говорю «не работает такая-то штука», а вы мне отвечаете «ну и что — вот возьми 6100 пакетов» :-)

(при участии и сообщества — gcc же умеет ia64)

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

повезло что что мне не нужна поддержка Эльбруса

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

Ну и хорошо. Зачем ты тогда волнуешься?

волнуюсь что если в этот раз повезло (не пришлось связываться с необходимостью работы на Эльбрусе), то в другой раз может не повезти (и связаться с этим дерьмом придётся). и тут ты такой красивый появляешься — «а не используй расширения» — а может уж сразу предложишь на windows или mac перейти(?), почему рекомендации только про расширения?

(только вот правда на Windows и Mac — есть работающие порты gcc — а на Эльбрусе не осилили)

и вопрос не идёт о производительности.. а вообще о том чтобы хотя бы работало бы.

и тут ты такой красивый появляешься — «а не используй расширения»

А почему ты считаешь, что ты красивее? Потому, что расширения используешь? :-)

А почему ты считаешь, что ты красивее? Потому, что расширения используешь? :-)

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

2. потомучто GCC является неотъемлемой частью GNU/Linux (по крайней мере — до прихода так называемых «линуксов от эльбруса»)

3. потомучто меня удовлетворяет ситуация того что программы будут работать в GNU/Linux. и не важно будут ли работать в других операционных системах.

4. изобретение такого Линукса в котором нельзя компилировать через GCC — выглядет скорее как нонсенс чем как правда. и довольно сложно поверить в такую ситуацию которая сейчас у Эльбруса сложилась. это случилось, но ситация всёравно выглядет невероятной. и это даже не позиционируется как студенческая экспериментальная поделка (just fir fun) , однако GCC нет.

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

ещё раз:

«уметь хотя бы как-то»

и

«неуметь вообще»

----- видишь тут разницу?

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

а не спрашивают «когда будет ЭФФЕКТИВНЫЙ» GCC.

ответы в стиле «не будет, потому что он будет работать неэффективно медленно» — это просто как детский сад.

в точно таком же случае можно было и на Perl/Python/Bash/Ruby ничего никогда не программировать — ведь «скорость программы низкая» :-) .. ну лол же!

ды кому они нафиг нужны до тех пор пока процессоры проигрывают ширпотребу (intel, amd, rasspberry pi)-- по ВСЕМ параметрам :-)

Пруфоф конечно же не будет.

боитесь что украдут?

Разумеется. Там довольно много патентованных вещей как в аппаратуре, так и в компиляторе.

или проблема в том что например тот же аналог Spectre может быть в процессорах e2k тоже но в отличии от x86 — реализовываемый через компилятор, а не аппаратно?

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

Пруфоф конечно же не будет.

пруфы на что? на то как сборка 11 версии постгреса падает при попытке собраться с jit ?

или будем соревноваться по количеству if-в-секунду Эльбруса с rasspberry-pi ?

намекни хоть чуть-чуть в чём может быть превосходство Эльбруса — у меня есть и Radoberry-Pi и Эльбрус — я могу проделывать эксперименты :-)

наверно как паралельная числодробилка — наверное Эльбрус должен убить всех по эффективности при работе с:

int v4si __attribute__ ((vector_size (16)));

> боитесь что украдут?

Разумеется. Там довольно много патентованных вещей как в аппаратуре, так и в компиляторе.

🤡🤡🤡🙈

У тебя странная фикция на расширениях компилятора GCC. За последние свои пять постов ты как минимум пять раз упомянул слово «расширения» или «расширения GNU-C».

Напомни, пожалуйста, как называется эта болезнь.

наверно болезнь называется «припихивается процессор в котором про них можно забыть»

кстати, тут незнаю почему примечание у меня сохранено про твой профиль о том что ты фанат Visual Studio и считаешь что линукс только для серверов.. незнаю почему такое примечание написано, но ссылка на https://goo.gl/m6Sfus

если примечание не врёт то подозреваю что тебе (в отличии от меня) феолетово на эти расширения ды и вообще на сам GCC :-) .. и своего рода наверно ты даже забавляешься от вида этой переписки :-)

припихивается процессор в котором про них можно забыть

Кто это его тебе припихивает? Тут люди в очереди за ним стоят, пощупать хотят, а купить не могут. А тебе значит его припихивают?

фанат Visual Studio

Неверно. Однако я не отрицаю, что в MS Visual Studio (IDE, а не компиляторов в комплекте), есть неплохо реализованная функциональность. Например, для работы с Git'ом многим другим IDE нужно брать пример с мелкософтовской софтины.

феолетово на эти расширения ды и вообще на сам GCC :-) .

На расширения мне действительно фиолетово, а вот на GCC — нет. Тем более туда теперь добавят язык D с которым я хотел бы немного познакомиться.

и своего рода наверно ты даже забавляешься

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

И кстати с чего ты взял, что они отсутствуют? Компания EDG, фронтенд компилятора которой используют сотрудники МЦСТ, на своей странице заявляет о поддержке диалекта GNU C, пруф: https://www.edg.com/c Так что может там и есть эти твои гнутые расширения и вполне себе рабочие, а не кривые. Успокоишься ли ты, узнав что они там есть и работают?

пруфы на что? на то как сборка 11 версии постгреса падает при попытке собраться с jit ?

Вообще на слова производительность, но можно и про это поговорить. Что конкретно падает, с какой формулировкой?

или будем соревноваться по количеству if-в-секунду Эльбруса с rasspberry-pi ?

Можно, думаю малина продует :)

намекни хоть чуть-чуть в чём может быть превосходство Эльбруса — у меня есть и Radoberry-Pi и Эльбрус — я могу проделывать эксперименты :-)

Во всём, я и там и там SPEC CPU2006 гонял ;) Результаты для малины весьма плачевные (даже не считая что часть тестов там просто сломались). Если брать какой-нибудь 462.libquantum, то на Эльбрусе там результат 42.81, а на малине 8.69. И то это старые замеры, сейчас этот тест на том же Эльбрусе в несколько раз быстрее ходит.

у меня сохранено про твой профиль

О, у тебя тоже есть списочек, как у intelfx (у него про systemd правда)? :-)

Если брать какой-нибудь 462.libquantum, то на Эльбрусе там результат 42.81, а на малине 8.69.

Оспадетыбожемой. Ты там серьёзно гордишься тем, что малину обогнал?

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

Утверждение от того же автора, что и «гнутые расширения позволяют не переходить на C++».

Оспадетыбожемой. Ты там серьёзно гордишься тем, что малину обогнал?

Аноним выше ответил.

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

Успокоишься ли ты, узнав что они там есть и работают?

успокоюсь..

но пока-что на моём Эльбрусе они не работают

# P.S.: ну как успокоюсь.. беспокойство по поводу отсутствия взаимодействия с сообществами: GCC, kernel.org, LLVM — всё ещё останется. но просто на одно беспокойство меньше