Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

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

О нарушениях можно сообщить модератору, нажав синюю кнопку #77 справа над спорным сообщением.

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

mag_ai где Вы в новости нашли, что это будет ARM с x86? Если перейти по ссылке на новость про этот Tremont, то можно догадаться, что это явно не ARM.
Я могу предположить, что они идут не тем путем. Может стоило бы Intel выделить направление на разработку RISC SoC для мобильной техники? Как мне кажется, что Lakefield не взлетит. Просто не будет использоваться на полную мощь.

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

Фанаты интел будут делать лейк интелу. Если вы понимаете о чем я

X86 не место в смартфонах.

за это взялся Келлер - так что взлетит без вариантов.

все эти гибриды где то на уровне дохлого ноута
вон топовый qualcomm как проц для ноута это еще та "мощь"))
я не очень понимаю что интел пытается сделать
мощный недоноут? так за него платить много не хотят, потерпят тормозной планшет
а интел же хочет заработать, поэтому его чипы дешевы не будут
на рынке смартфонов вряд ли они влезут с своими SoC
там уже все забито, может когда чипы arm станут жручими, тогда )))

ark-bak может быть у Келлера и получется что-то весьма интересное, но разработчики не станут делать два проекта доя ARM и для x86. Просто приложения будут под x86 портироваться, что в итоге просто не даст себя проявить в полной мере. Вот что я имел ввиду.

Если речь про Андроид, то Ява-приложения не нативны. Для нативных же компиляторы под x86 и MIPS существуют с довольно давних времён. Плюс Интел делали транслятор для Андройд.

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

Специфичные инструкции АРМа используют от силы 0,01% от нативных приложений, а то и меньше. Это крупные программные пакеты оптимизированные под конкретные архитектуры для конкретного специфического применения. И то большая часть из них имеет и x86 версию.

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

coth увы и ах это не так... вы думаете про вектора, а я думаю например про инструкции уплотнения команд, и тп

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

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

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

Некоторые, правда, имеют нативные библиотеки в комплекте. Но x86 и MIPS уже давно стали частью Android, большая часть таких приложений имеют x86 и MIPS версии библиотек в комплекте.


Имеет. Вопрос не в этом. Вопрос в том, что программ использующих в своих исходниках такой код крайне мало. Обычные С++, C# или Pascal приложения легко компилируется под ARM или x86. Большинство игровых движков так же имеют x86 и ARM версии. Особых проблем с поиском приложений под x86 на Андройде нет. Каких-то нет, но таких крайнее меньшинство.

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

не сочиняйте плиз...

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

вы должны понимать что если что то и есть под "арм" то это отдельная ветка например "анреал инжен" да есть и под айос и под андроид, но это не совместимая с х86 ветка.

Приводится в пример, чтоб дать понять, что 99% приложений на Андройде не зависят от архитектуры.


С добрым утром. x86 официально поддерживается с версии 4.2, x86-64 с версии 5.0.
https://developer.android.com/ndk/guides/abis


Причём тут окружение, если речь о приложениях?


UE4 поддерживает компиляцию под x86 для Android ещё с 2014 года.

так почему байт машины работающие на более высоком уровне абстракций стали хорошим пример чтоб показать "99% приложений андроида архитектурно не зависимы"?
с такой же логикой можно сказать что 99% людей физиологически друг на друга не похоже и найдите мне опровержение.

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

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

1. Нет там более высокого уровня абстракции.
2. Потому, что в них нет нативного кода. Они компилируются в нативный код во время выполнения или перед выполнением. в данном случае пере выполнением Android Runtime'ом. ART поддерживает компиляцию в arm, aarch64, x86 и x86-64.


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