Не статистика, но как-то я из интереса разбирал код одной ААА игрушки. Под консоли, в которых всё-таки x86, там собирали с заранее собранным из плейтестов профилем.
Это не статистика, но меня очень порадовало, что люди все-таки пользуются PGO, пытаясь выжать из устаревшей железки всё что возможно.
Кстати со сложностью ассемблера не соглашусь. Он необычный, кого-то можно даже удивить им, но можно ли сравнить его с ассемблером x86 и сказать что он заметно сложнее? По-моему опыту с ними двумя как-то нет. Сложно для этого писать компилятор, конечно. А куда без компиляторов денешься...
Хороший ответ Armmaster'у, ждем реакции с его стороны. *приготовил попкорн*
Но правда как обычно где-то посередине. Мне, честно, нравятся Эльбрусы. Я не вижу чтобы в статье где-то вообще соврали. Они действительно производительны, не одно поколение процессоров сменилось, да и софт стабильный. Как я говорил, бери и внедряй. Это реально самая уникальнейшая и при этом готовая разработка в РФ.
Но всё ли так радужно? Да, если вы готовы терпеть: отсутствие быстрых JIT, полностью статичное планирование и полузакрытую систему команд.
А так же компиляторы, потому что у Эльбруса есть только закрытый lcc, а существующий порт llvm даже не в курсе про e2k, он создает код в нескучном IR, который все равно подается на вход особой сборке lcc.
Можно ли так жить? Однозначно можно. Но сравнима ли ситуация с таким же отечественным Байкалом? Мне кажется, нет.
Мне было лишь интересно, как он работает. Предметно, каюсь, не лазил. Задач подобных просто нет.
Вот именно идея с промежуточным кодом, компиляцией в нативный прям на юзерской машине, со сбором профиля и рекомпиляцией выглядит достаточно интересной в контексте VLIW.
Потому что если всё оставить как есть, рано или поздно это выйдет боком. Может быть. А может e2k вообще не дорастёт до этого этапа.
Отвоёвывать, потому что в своих сборках они зачем-то зафорсили адресное пространство шире, с чем обычно собирается Linux на многих ARM устройствах. Если мне не изменяет память, он хочет 48 бит и всё падает после MAP_FIXED.
Я слышал что предсказатель переходов возможно появится в v7. Но пока о нём ничего не известно толком. Появится в компиляторе — придется ковырять компилятор.
Но я надеюсь к тому времени МЦСТ одумается, их "Заказчики" тоже и они начнут соблюдать GPL. Нашего эмулятора бы не было, если бы в Astra Linux не лежал *.deb архив с исходным кодом binutils.
Если кто-то займется сборкой Android на e2k, то оно будет работать. Но это настолько сложный процесс, что в нём просто чёрт ногу сломит. Я пробовал и возвращаться к нему не хочу. Это что-то страшное, из наслоений легаси в виде Android.mk, новых Android.bp, нового kati, который Android.mk перегоняет в Ninja потому что Make слишком медленный и всё это вместе зовется Soong. Всё это ещё обмазано абсолютно недружественной к разработчику среде в виде сотни гигабайт говнокода от Google. Говнокодить больше чем Google надо постараться.
Простите, больная тема. :)
И к e2k вопросов нет, собирать Android в любом случае боль и к архитектуре это не имеет никакого отношения, один фиг кросскомпиляция. Для меня лично это решила не сколько x86 как архитектура, а AMD с относительно доступными Ryzen. И 1 ТБ NVMe. И 32 ГБ памяти.
А вот что про ART, я считаю он подходит для e2k. Само собой, я не обсуждаю JIT времён до Lollipop, про него можно забыть.
Почему Android в моём понимании более удачен?
Распространяется промежуточный код, который локально компилируется в нативный с учётом возможностей процессора. Это было в моём предыдущем комментарии.
Во время работы приложения собирается профиль, что также немаловажно. Вы упускаете это, а про это между прочим написано в документации Android.
Затем специальный демон, в фоне перекомпилирует приложение с учётом профиля.
AOT компиляция там всего-лишь одна из стадий и часто используемое приложение скорее всего будет перекомпилировано JIT компилятором.
Не знаю какой версии сейчас Qt, но ядро 5.4 и glibc 2.29. И кто знает над каким работает соответствующий отдел прям сейчас.
Не статистика, но как-то я из интереса разбирал код одной ААА игрушки. Под консоли, в которых всё-таки x86, там собирали с заранее собранным из плейтестов профилем.
Это не статистика, но меня очень порадовало, что люди все-таки пользуются PGO, пытаясь выжать из устаревшей железки всё что возможно.
Всё-таки он lcc. llc -- это компилятор LLVM IR в нативный. :)
Не знаю, мне в целом одинаково, что тут, что там.
После эмулятора меня это не пугает конечно. Особенно запуская те части, от которых исходного кода нет.
Кстати со сложностью ассемблера не соглашусь. Он необычный, кого-то можно даже удивить им, но можно ли сравнить его с ассемблером x86 и сказать что он заметно сложнее? По-моему опыту с ними двумя как-то нет. Сложно для этого писать компилятор, конечно. А куда без компиляторов денешься...
Есть.
Компилятор кстати помогает считать такты. Если убрать галочку в Filter->Comments, то между ШК будет комментарий с тактами.
Вы не понимате -- это другое!
Нет, мне просто кажется что невозможно сочинить такой ответ за 38 минут. Сравните дату самостоятельно.
Больше похоже на совпадение. К тому же тематика разная.
Не считается. Статьи были опубликованы почти в одно время. :)
Хороший ответ Armmaster'у, ждем реакции с его стороны. *приготовил попкорн*
Но правда как обычно где-то посередине. Мне, честно, нравятся Эльбрусы. Я не вижу чтобы в статье где-то вообще соврали. Они действительно производительны, не одно поколение процессоров сменилось, да и софт стабильный. Как я говорил, бери и внедряй. Это реально самая уникальнейшая и при этом готовая разработка в РФ.
Но всё ли так радужно? Да, если вы готовы терпеть: отсутствие быстрых JIT, полностью статичное планирование и полузакрытую систему команд.
А так же компиляторы, потому что у Эльбруса есть только закрытый lcc, а существующий порт llvm даже не в курсе про e2k, он создает код в нескучном IR, который все равно подается на вход особой сборке lcc.
Можно ли так жить? Однозначно можно. Но сравнима ли ситуация с таким же отечественным Байкалом? Мне кажется, нет.
Говорят отдельно плату можно все-таки достать сильно дешевле, раза в 1.5-2 точно. Тем более 8С это фактически легаси, сейчас актуальный 8СВ.
Впрочем цифра для меня лично получается достаточно большой. :)
>высосанная непонятно с какого места цифра
Литография вещь такая, что производство дешевеет только при больших партиях. Да, Эльбрусов мало и именно поэтому они стоят так дорого.
Сделают — посмотрим. Не сделают — тоже хорошо. Ядро не похоже чтобы сильно менялось со времён E3M, это просто видно по ISA.
Даже задержки не менялись вплоть до v6. Там задержки по памяти подняли ради тактовой частоты.
Мне было лишь интересно, как он работает. Предметно, каюсь, не лазил. Задач подобных просто нет.
Вот именно идея с промежуточным кодом, компиляцией в нативный прям на юзерской машине, со сбором профиля и рекомпиляцией выглядит достаточно интересной в контексте VLIW.
Потому что если всё оставить как есть, рано или поздно это выйдет боком. Может быть. А может e2k вообще не дорастёт до этого этапа.
Хм...
Партия разочарован в вас.
Партия отобрать кошкожена.
Отвоёвывать, потому что в своих сборках они зачем-то зафорсили адресное пространство шире, с чем обычно собирается Linux на многих ARM устройствах. Если мне не изменяет память, он хочет 48 бит и всё падает после MAP_FIXED.
Не для людей делают, вот. :)
Я слышал что предсказатель переходов возможно появится в v7. Но пока о нём ничего не известно толком. Появится в компиляторе — придется ковырять компилятор.
Но я надеюсь к тому времени МЦСТ одумается, их "Заказчики" тоже и они начнут соблюдать GPL. Нашего эмулятора бы не было, если бы в Astra Linux не лежал *.deb архив с исходным кодом binutils.
Если кто-то займется сборкой Android на e2k, то оно будет работать. Но это настолько сложный процесс, что в нём просто чёрт ногу сломит. Я пробовал и возвращаться к нему не хочу. Это что-то страшное, из наслоений легаси в виде Android.mk, новых Android.bp, нового kati, который Android.mk перегоняет в Ninja потому что Make слишком медленный и всё это вместе зовется Soong. Всё это ещё обмазано абсолютно недружественной к разработчику среде в виде сотни гигабайт говнокода от Google. Говнокодить больше чем Google надо постараться.
Простите, больная тема. :)
И к e2k вопросов нет, собирать Android в любом случае боль и к архитектуре это не имеет никакого отношения, один фиг кросскомпиляция. Для меня лично это решила не сколько x86 как архитектура, а AMD с относительно доступными Ryzen. И 1 ТБ NVMe. И 32 ГБ памяти.
А вот что про ART, я считаю он подходит для e2k. Само собой, я не обсуждаю JIT времён до Lollipop, про него можно забыть.
Почему Android в моём понимании более удачен?
AOT компиляция там всего-лишь одна из стадий и часто используемое приложение скорее всего будет перекомпилировано JIT компилятором.