Продвигая основанные на архитектуре x86 решения на базе платформы Android компания Intel столкнулась (http://www.networkworld.com/article/2360304/opensource-subne...) с неожиданными трудностями, выразившимися в том, что в условиях доминирования в экосистеме Android одной аппаратной архитектуры огромное число приложений оказались привязаны к архитектуре ARM. Несмотря на то, что базовым языком для Android является платформонезависимый Java, при помощи NDK (Native Development Kit) разработчики могут организовать выполнение нативного кода в окружении мобильной платформы Android. Было выявлено, что их двух тысяч самых популярных программ в каталоге Google Play, 2/3 используют NDK для реализации на языке Си критичных к производительности блоков кода, что препятствует использованию таких программ на системах с иной архитектурой.URL: http://www.networkworld.com/article/2360304/opensource-subne...
Новость: http://www.opennet.me/opennews/art.shtml?num=39949
Java пока еще тормозит, но скоро все измениться. (с) 1994
У меня не тормозит. ЧЯДНТ?
У меня на Core-i7 тоже, но тут речь о смартах и ARM
> У меня на Core-i7 тоже,Это смотря что с ней делать. Вон перепиши VP9 кодировщик на яву. Он и так то кодирует на максимальном качестве полтора фрейма в минуту, а если на яве переписать... давайте посмотрим как там развернется мегаоптимизатор, да? :)))
> но тут речь о смартах и ARM
Ну вот они стали 8-ядерными и на пару ГГц не от хорошей жизни...
я тут недавно видел AArm64 который по производительности делает топовые ксеоны... правда TPD у него тоже не маленький..
> У меня не тормозит. ЧЯДНТ?У тебя 2/3 на ндк.
в том-то и дело, что нет
Тогда ты тормоз и не пробовал сравнивать скорость. Попробую угадать - ты умеешь на яве программить и больше ничего не знаешь. Поэтому и поешь мантры...
после "Тогда ты тормоз" нужно было остановиться. Получил бы массу плюсиков за шутку"
тут может быть одно из двух - либо тормоз ява, либо тормоз ты
> У меня не тормозит. ЧЯДНТ?Может ты сам тормозишь, поэтому и не замечешь?
врешь или бредишь. в реальных (не синтетических) тестах жаба сливает на порядки C/C++.
после недель оптимизаций отставание можно сократить до порядка. кому нужен код который тормозней в 10 раз?
угу, а C/C++ сливает ассемблеру, а тот в свою очередь сливает FPGA - только что из этого следует?
Только SystemVerilog
Только хардкор
VHDL?
> угу, а C/C++ сливает ассемблеру, а тот в свою очередь сливает FPGAЗнаток хренов. Нынче половину аппаратных блоков делают путем трансляции из субсета си в схему. Вот так вот просто и брутально. Зато можно что-нибудь сложное оттранслировать, типа навороченного кодека.
не сливает.
сливает
> У меня не тормозит. ЧЯДНТ?У тебя заниженные требования или реакция.
Или со сравнениями туговато. Напиши программу на си и посмотри как работает.
> Или со сравнениями туговато. Напиши программу на си и посмотри как работает.боюсь, что он сможет тормознуть даже небо, даже аллаха.
> Java пока еще тормозит, но скоро все измениться. (с) 1994Ну так и изменилось же.
JavaScript пока еще тормозит, но скоро все изменится. (с) 2014
> Ну так и изменилось же.
> JavaScript пока еще тормозит, но скоро все изменится. (с) 2014А что изменилось то? На горизонте появился еще один тормоз, еще более забористый? :)
> изменитьсяПрямо так и было в оригинале?
славное было время. еще говорил про безопасность, песочницу и т.д.
Русский язык выучи для начала.
>...2/3 используют NDK для реализации на языке Си...Всё правильно делают!
не всё: некоторые вещи лучше делать на Фортране
> не всё: некоторые вещи лучше делать на Фортранеага, вдоль
> не всё: некоторые вещи лучше делать на ФортранеНе нужно на Фортране. Достаточно Си.
Действительно хорошая новость.
Это плохо или хорошо?
А то я, чисто интуитивно, плюсанул...
)))
Красава!
Атлична
> Это плохо или хорошо?
> А то я, чисто интуитивно, плюсанул...Это хорошо. Но совсем отлично будет выкинуть Java совсем и оставить только C.
а чего они ждали?
На самом деле здесь жалко даже не интел, а MIPS, у которого есть ряд интересных чипов под планшеты (и ещё больше - готовятся), который страдает от той же проблемы, и на который, в отличии от Интела, мало кто будет обращать внимание и что-то под него перекомпилировать.
Можно попробовать адаптировать существующие приложения под MIPS. Это реально, я пробовал.
хе-хе, не удалось затащить людей на это гогно, разработчики даже готовы немного пройти через очередь унижений в виде NDK. Надеюсь что наконец таки закопают эту бредовую идею и будут просто делать старые добрые нативные бинарные сборки на платформах следующих поколений.
Как бы Google не напоролся на свой же NDK. С одной стороны Java в текущем (в обоих смыслах) состоянии на мобильнике ну ни как не может обеспечить высокую производительность, с другой есть опасность, что ARM+Android на мобильниках превратится в очередной wintel - сменить аппаратную платформу вроде как хочется, но куча софта при этом отвалится, а если не отвалится, то лучше бы уж отвалилась.
Выход в сегодняшней ситуации видится один - LLVM или его аналог вместо компиляции в ARM-инструкции + компиляция в нативный код на этапе установки.
Но кому это надо кроме Intel, которая по определению этого сделать не может т.к. мейнстримом рулит Google?
Вот тебе и свободная платформа.
да нет никакой проблемы с компиляцией, сделать заранее несколько сборок под разные архитектуры совсем не проблема если официально дать нормальую поддержку инсталяции таких пакетов. Проблема в топике возникла исключительно из-за запрета таких дистрибутивов приложений - разработчики платформы летают в облаках со своими фантазиями и положили хер на данную фичу. Раз никто разработчикам не предлагает правильных решений, то они начинаю придумывать местечковые решения заточенные только под конкретные девайсы.
А что делать, если список платформ, для которых Google делает Android вырастет? Снова собирать пакеты для новых архитектур?
Выбор Java в качестве языка для Android это очень адекватное решение с точки зрения переносимости - написал софтину и запускай на любой аппаратной платформе, где есть соответствующее окружение. А вот возможность писать на сях и компилить только для ARM - решение хоть и понятное, но не последовательное. Получается, что весь профит от Java улетает в топку только потому, что можно писать на сях и компилить для ARM.
Если смотреть с этой стороны - наиболее сбалансированное решение - это как раз компиляция не для Java-машины, которая тормозная, и не для ARM, который не переносимый, а во что-то вроде LLVM с последующей оптимизацией под конкретное устройство во время установки (этакий одноразовый JIT). Так можно и производительность близкую к сям получить и переносимости уровня Java добиться.
> А что делать, если список платформ, для которых Google делает Android вырастет? Снова собирать пакеты для новых архитектур?Это всё какие-то клинические фантазии ява фанбоев. Ну не появляются новые платформы, практически вообще никак. Какая-то новая платформа это целое событие. Осилить одну платформу раз в десять лет ни для кого не проблема.
Все остальные кейсы это простая пересборка пакетов, как это делается уже хз сколько лет в бинарных линуховых дистрибутивах.
> Получается, что весь профит от Java улетает в топку только потому, что можно писать на сях и компилить для ARM.
Так весь и посыл в том, что ява вообще нахер не нужна. Есть нативный SDK и тулчейн который разработчику сразу соберёт его пакет под N профессорных платформ. Это в смысле как нужно было делать с самого начала.
> Если смотреть с этой стороны - наиболее сбалансированное решение - это как раз компиляция не для Java-машины, которая тормозная, и не для ARM, который не переносимый, а во что-то вроде LLVM с последующей оптимизацией под конкретное устройство во время установки (этакий одноразовый JIT).
В принципе тоже ок, тогда на телефоне нужно будет держать весь тулчейн для сборки и выжирать его батарею во время установки и обновления.
>> А что делать, если список платформ, для которых Google делает Android вырастет? Снова собирать пакеты для новых архитектур?
> Это всё какие-то клинические фантазии ява фанбоев. Ну не появляются новые платформы,
> практически вообще никак. Какая-то новая платформа это целое событие. Осилить одну
> платформу раз в десять лет ни для кого не проблема.Платформа AMD64 сколько лет назад появилась? Я до исх пор крайне редко вижу ПК без единой программы в x86. Если бы не это наследие - AMD64 была бы куда менее консервативной платформой.
> Все остальные кейсы это простая пересборка пакетов, как это делается уже хз
> сколько лет в бинарных линуховых дистрибутивах.Пересборка это конечно хорошо и скорее всего даже реализуемо, но что будем делать, если разработчик свой проект забросил, а исходников для этой самой пересборки не оставил?
>> Получается, что весь профит от Java улетает в топку только потому, что можно писать на сях и компилить для ARM.
> Так весь и посыл в том, что ява вообще нахер не нужна.
> Есть нативный SDK и тулчейн который разработчику сразу соберёт его пакет
> под N профессорных платформ. Это в смысле как нужно было делать
> с самого начала.Это просто констатация непоследовательных действий со стороны Google. Java для Android была взята как раз для независимости от аппаратуры, причем ценой производительности. Зачем же тогда NDK, который по определению лишает программы этой переносимости?
>> Если смотреть с этой стороны - наиболее сбалансированное решение - это как раз компиляция не для Java-машины, которая тормозная, и не для ARM, который не переносимый, а во что-то вроде LLVM с последующей оптимизацией под конкретное устройство во время установки (этакий одноразовый JIT).
> В принципе тоже ок, тогда на телефоне нужно будет держать весь тулчейн
> для сборки и выжирать его батарею во время установки и обновления.Не такой большой тулчейн, учитывая размеры остальной платформы. Батарею компиляция кушает один раз, а потом солидно ее экономит.
Кстати я оказался прав - http://www.opennet.me/opennews/art.shtml?num=40041
Осталось только выпилить NDK, но на это не приходится рассчитывать в ближайшее время.
Угу, есть еще более простой вариант - поверх всего, что сейчас уже есть, воткнуть Portage и собирать приложения на самом устройстве из исходников....
pS: хоть это немного сарказм, но все же (мое личное мнение) - довольно интересно было бы увидеть нечто подобное
только вот большинство приложений под андроид исходников в открытом доступе не имеют. Но вообще да, было бы прикольно.
> Вот тебе и свободная платформа.Ну так а что ты хотел. Рулит тот кто что-то делает. Где интел со своим атомом лапу сосал, когда мобильный рынок вверх взлетал? Проипали направление, теперь хныкать поздно. Вон микрософт смирилась...
> Вот тебе и свободная платформа.Если бы там был не маркет с платными калькуляторами, а нормальный репозиторий со свободным софтом, платформу можно было бы называть свободной.
А сейчас андроид - это такая винда, просто на основе ядра линукса.
>> Если бы там был не маркет с платными калькуляторами, а нормальный репозиторий со свободным софтом, платформу можно было бы называть свободной.
>> А сейчас андроид - это такая винда, просто на основе ядра линукса.FDroid - нормальный репозитарий со свободным софтом. Платформа - свободная, а вот то что сверху на это налеплен толстый слой проприетарного гугловского фреймворка, всасывающего в себя всё больше и больше функций, которые раньше были открытыми - явная ловушка гугла, надеющегося закрыть всё, кроме самого ядра линукса (им не жалко, всё равно все драйвера в виде блобов).
Пока ещё хотя бы не запретили установку сторонних магазинов и фреймворков.
> Платформа - свободнаяи бесполезная.
впрочем, любители говна будут его жрать пока не лопнут.
> А сейчас андроид - это такая винда, просто на основе ядра линукса.Если ты часть своего виндового Г. вымажешь на Android и Linux, чистым не станешь.
Дык это, в Intel уже давно сделали динамический рекомпилятор, который позволяет запускать почти что любое приложение с ARM кодом. И в телефонах и в планшетах с Atom'ами он давно встроен и работает, пользователи не жалуются. К тому же многие приложения уже имеют отдельные версии для x86 и MIPS.
> Дык это, в Intel уже давно сделали динамический рекомпилятор, который позволяет запускатьДык в оригинале то новости про это есть
Apps that use the ARM instruction set still run on Intel mobile devices because Intel-specific Android versions have a compatibility layer called Houdini that maps ARM instructions into X86 instructions.
Не понимаю, чего они переживают. Их платформа выполняет приложения, пусть и с потерей в скорости. Если Atom'ы так быстры, как о них пишут маркетологи, это не должно быть проблемой. А если разработчик приложения пересоберёт свой код под x86, оно станет ещё быстрее. Прямо профит на профите, а они чего-то охают и ахают.Вот MIPS устройства выходили вообще без какой бы то ни было поддержки ARM, это был былинный отказ. Да и сейчас официальной поддержки нет, есть только MagicCode от независимых хакеров, который не всё ест.
>Не понимаю, чего они переживают.Переживали. Вас вводит в заблуждение здешний заголовок. В оригинале новость называется
Intel has solved the problem of ARM-native incompatibility. / Интел решил проблему несовместимости с арм.
FatELF? =)
> FatELF? =)Нет, там просто отдельные so-шки для каждой архитектуры в своих директориях. А чтобы размер приложения не бы большим из-за лишних бинарников, гугл плей (кажется, это началось ещё в те времена, когда он был маркетом) позволяет загружать несколько версий приложения. Для ARM устройств скачается версия с бинарниками под ARM, для x86 -- под x86.
Костыли потому что, я бы тоже переживал.
> Дык это, в Intel уже давно сделали динамический рекомпилятор, который позволяет запускать
> почти что любое приложение с ARM кодом.дык это, в qemu уже давно… и далее по тексту.
а ещё Android's C Library Has 173 Files of Unchanged OpenBSD Code http://undeadly.org/cgi?action=article&sid=20140506132000
> а ещё Android's C Library Has 173 Files of Unchanged OpenBSD Code
> http://undeadly.org/cgi?action=article&sid=20140506132000Бээсдэшники в шоке! Их код использовали и _не _закрыли. Возмутительнно!!!1111 [зловещий звук рвущихся шаблонов из-за кадра] >/<
Ох, Андрюша, как же тебе неймётся-то, что живы ещё бсдэшники! Или они тебя, как вьетнамцы Маккейна, годами анально мяли? )
> Ох, Андрюша, как же тебе неймётся-то, что живы ещё бсдэшники! Или они
> тебя, как вьетнамцы Маккейна, годами анально мяли? )Анонимы желают обсудить анальную маяту? Маккейна? Ай, затейник! Нарисуй плакатик, иди маршеровать перед посольство.
Неужели "APP_ABI=all" не решает проблему?
Все правильно сделали Atom не нужен, пусть используют ARM64
А что они делают такого платформозависимого на Сях? Оптимизации?
Именно платформеннозависимого ничего. Просто собирают код в натив чтобы он быстрее работал и меньше выжирал батареи. Может быть даже используют какие-то библиотеки функционал которых нечем заменить в SDK
Используют NEON, например.
Так ведь нативные приложения род андроид можно собирать под разные архитектуры, что мешает разработчикам делать это?
печально.
скоро к C-писаным бинарям в приложения - добавятся обфуцирующие элементы и вещи препятствующие работу этого самого "Houdini". "ибо нехЪ" (c)
Хотите сказать, что есть идиоты, которые хотят сузить рынок для своего софта, вложив усилия (т.е. деньги) в то, чтобы он где-то не работал? Ну-ну...
Это не обязательно должны быть сами авторы софтов.> http://streamcomputing.eu/blog/2013-08-01/google-blocked-ope.../
Добавьте к этому common knowledge о том что
> Android team is very Java biased and see the NDK as something that was imposed on them
>> Android team is very Java biased and see the NDK as something that was imposed on themПонабрали по объявлениям...
Переходите на Tizen, лучшие южнокрейские программисты уже расчехлили свои клавиатуры.
нужно больше костылей!!!11имхо, лучше бы они NDK попилили, на предмет компиляции нативного кода под разные платформы и их упаковки
Проблема в том что некоторые приложения используют не просто нативный код а особенности архитектуры.
Вставки на С делаются не для оптимизации, а для защиты от декомпиляции, ибо пиратство и клонирование на андроиде имеют чудовищные масштабы.
Боюсь показаться занудой, но.
Зачем тогда вообще нужен этот dalvik, если 2/3 все равно на NDK?
Как всякие sailfish, tizen, firefox os будут адаптировать это? Понимаю, что архитектура одна, но это получается потребуется и C-библиотека и пр.