Комментарии 43
Мне кажется что рано давать какие-либо прогнозы на этой платформе. Через год-два увидим во что это выльется, может и правда начало новой мобильной эры.
Но ведь x86, насколько мне известно, огромный костыль.
Когда из нее собираются выпилить все ненужное и устаревшее?
Когда из нее собираются выпилить все ненужное и устаревшее?
Никогда. Ибо потеряется обратная совместимость. Поэтому хочется верить, что x86, в привычном нам виде, благополучно загнется, а вместо нее будет предложено что-то более свежее.
Есть ли какие-то причины, почему x86 не может жить и развиваться еще долго-долго?
Вот я наконец купив себе смартфон на андроиде ВНЕЗАПНО обнаружил, что он построен на ARMv6, а следовательно многими разрабами уже считается устаревшим гавном и версии под него не делаются. А сколько таких фэйлов уже было у владельцев ARM? Ну типа купил клевый гаджет за кучу килорублей, прошло полгода, вендор выпускает новую модель без обратной совместимости со старой и привет, выкидывай, покупай новую (пример Nokia N800).
На x86 у меня такое случалось чуть менее чем никогда. Так что мне не кажется чем-то плохим наличие обратной совместимости.
На x86 у меня такое случалось чуть менее чем никогда. Так что мне не кажется чем-то плохим наличие обратной совместимости.
Ну как, было время, когда некоторые игры не хотели работать в определенных режимах без mmx или, например, sse3. Ну и виндовая виртуалка не на всех процессорах интела запускается (а только на тех, где есть аппаратная виртуализация). При чем последнее даже не от возраста зависит.
В играх, если честно, чаще сталкивался с отсутствием в видюхе нужных шейдеров, чем с отсутствием нужных инструкций в проце. С x86 крепко дружу около 14 лет уже.
А виртуализацию вроде бы прикрутили потом, во всяком случае новость мелькала.
А виртуализацию вроде бы прикрутили потом, во всяком случае новость мелькала.
Виртуалка чутка более специфичная софтина, нежели Angry Birds. От того, что виртуалка не пахает на нетбуке девочка не расстроится, а вот от бёрдзов может телефон и в стеночку пульнуть.
А я, хоть и не девочка, расстроюсь!
Аналогично, я и расстроился, была у меня задача с GPS работу отладить, а работал на десктопе под виртуалкой(специфичные настройки были которые конфликтовали с настройками реальной машины, разные задачи) и лег спать вечером весь такой окрыленный что завтра пойду на озеро работать с ноутбуком перекинув туда виртуаку… и утром меня ждало разочарование в виде не поддержки процом 64 бит виртуализации(хотя сам проц 64 бита).
>>Ну и виндовая виртуалка не на всех процессорах интела запускается (а только на тех, где есть аппаратная виртуализация). При чем последнее даже не от возраста зависит.
Виндовая виртуалка с вами не согласна www.microsoft.com/downloads/ru-ru/details.aspx?familyid=e70dd043-e262-43c0-a002-446567f1e2b4 (KB977206) По умолчанию этот патч не идёт в комплекте и автоматом не ставится, т.к. без наличия аппаратной виртуализации в процессоре (поддержка AVX инструкций) скорость работы будет крайне мала. Однако если установить этот патч можно запускаться на любом железе.
Виндовая виртуалка с вами не согласна www.microsoft.com/downloads/ru-ru/details.aspx?familyid=e70dd043-e262-43c0-a002-446567f1e2b4 (KB977206) По умолчанию этот патч не идёт в комплекте и автоматом не ставится, т.к. без наличия аппаратной виртуализации в процессоре (поддержка AVX инструкций) скорость работы будет крайне мала. Однако если установить этот патч можно запускаться на любом железе.
Архитектура как таковая играет роль только в случае использования нативного кода. Развитие управляемых языков, типа явы и прочего шарпа, эту головную боль с программиста снимает. Т.е. код компилим как обычно, а запуститься оно будет способно на чем угодно, лишь бы там была машина для этого языка.
Пример смартфона на x86 прекрасно иллюстрирует этот подход. Большая часть Андроидного софта отлично завелась на совершенно другой архитектуре.
Проблема как раз в тех самых разработчиках, которые используют нативный код на андроиде, чем стреляют в ногу не только себе, но и, в данном случае, интелу. И Вам.
PS. Вы уверены, что в Вашем случае речь именно об архитектуре, а не о банальной мощности процессора? Иногда девелоперы боятся минусиков в карму(звездочек в маркете) и блокируют конкретные девайсы при малейших подозрениях на несовместимость. Попробуйте добыть сам апк-шник, может оказаться, что оно будет способно работать и у Вас.
Пример смартфона на x86 прекрасно иллюстрирует этот подход. Большая часть Андроидного софта отлично завелась на совершенно другой архитектуре.
Проблема как раз в тех самых разработчиках, которые используют нативный код на андроиде, чем стреляют в ногу не только себе, но и, в данном случае, интелу. И Вам.
PS. Вы уверены, что в Вашем случае речь именно об архитектуре, а не о банальной мощности процессора? Иногда девелоперы боятся минусиков в карму(звездочек в маркете) и блокируют конкретные девайсы при малейших подозрениях на несовместимость. Попробуйте добыть сам апк-шник, может оказаться, что оно будет способно работать и у Вас.
Я согласен, с андроидом все-таки получше. Мои замечания больше относятся именно к нативному коду — активно слежу за процессом портирования ICS на мой девайс, очень много проблем из-за того, что часть кода из инфраструктуры (драйверы) только под ARMv7. Хотя уже встречал в маркете софт, который на моем девайсе тупо не запускается.
Ну а гаджеты с ОС на нативном коде вообще дико страдают. А ведь нативный код почти наверняка будет быстрее исполнятся, чем виртуальная машина.
Ну а гаджеты с ОС на нативном коде вообще дико страдают. А ведь нативный код почти наверняка будет быстрее исполнятся, чем виртуальная машина.
Тут уж ничего не поделать — вендор тупо не выпустил драйвер. К архитектуре как таковой это не относится.
По поводу быстродействия — это уже скорее миф. В некоторых случаях управляемый код может оказаться быстрее.
По поводу быстродействия — это уже скорее миф. В некоторых случаях управляемый код может оказаться быстрее.
Но практика показывает, что управляемый код обычно тормознее раз в тыщу. Потому что пишут криволапые чуваки, которых в школе ворду учили. Такие чуваки как правило сишку не осиливают, отсюда и перевес в плане говнокода на различных платформах.
Кстати, современные билд системы полностью решают вопрос архитектурынх различий ни чуть не хуже явы.
Кстати, современные билд системы полностью решают вопрос архитектурынх различий ни чуть не хуже явы.
Так вот и задумаешься, а не происходит ли этого из-за несовместимости платформ и их условного быстрого устаревания?
Неа, не думаю. Я вообще не очень понимаю, как так получилось, что часть драйверов для чипсета оказалось несовместима с архитектурой этого самого чипсета. То есть кто написал драйвера для него, с ним несовместимые?(Вы говорите, что дело в Arm6 vs Arm7)
Если же под ICS для Вашего чипсета тупо нет дров(такая с моим Desire — тупо нет дров для ядра 3.x, из-за чего ICS там работает, мягко говоря, нестабильно), то я не понял, при чем тут архитектура. Просто вендору было впадлу портировать существующий код под новое ядро.
Если же под ICS для Вашего чипсета тупо нет дров(такая с моим Desire — тупо нет дров для ядра 3.x, из-за чего ICS там работает, мягко говоря, нестабильно), то я не понял, при чем тут архитектура. Просто вендору было впадлу портировать существующий код под новое ядро.
Драйвера имеется ввиду для периферии. И для новой версии чипсета есть, в которой уже ARMv7. Правда после подачи петиции Qualcomm все-таки выдала скомпиленные под ARMv6 версии и разработка значительно продвинулась. Теперь вот набора кодеков не хватает, совместимых с ICS — та же причина.
> Просто вендору было впадлу портировать существующий код под новое ядро.
Я про то и толкую, платформа быстро устаревает, а обратной совместимости нет — вот им и впадлу бэкпорты делать.
> Просто вендору было впадлу портировать существующий код под новое ядро.
Я про то и толкую, платформа быстро устаревает, а обратной совместимости нет — вот им и впадлу бэкпорты делать.
Даа, бинарники убунты уже не накатить
Да, конечно обратная совместимость это большой плюс, но в случае с x86 получается слишком большая обратная совместимость.
Если не ошибаюсь, то оттуда не убрана поддержка 16-битных ОС, которыми сейчас уже никто не пользуется. Возможно более поддержка более старых инструкций также не убрана.
Если не ошибаюсь, то оттуда не убрана поддержка 16-битных ОС, которыми сейчас уже никто не пользуется. Возможно более поддержка более старых инструкций также не убрана.
Ну и что? Старый софт использует старые инструкции, новый — новые. В чем проблема? Пускай там себе на кристалле будет отдано немного места под совместимость, на быстродействие современного софта это ведь не влияет.
Я думаю, никто не разочаруется, если реальный режим будет убран — загрузчик может сразу стартовать в защищённом.
Если не секрет, то что за более старые инструкции? Я знаю лишь «устаревшие порты» вроде PIC, который эмулируется.
Если не секрет, то что за более старые инструкции? Я знаю лишь «устаревшие порты» вроде PIC, который эмулируется.
>>Если не ошибаюсь, то оттуда не убрана поддержка 16-битных ОС, которыми сейчас уже никто не пользуется. Возможно более поддержка более старых инструкций также не убрана.
В x86-64 уже убрано и то и то.
В x86-64 уже убрано и то и то.
AMD попытались выпилить селекторы в x64. Обломались.
Intel рассчитывает, что 75% существующих приложений Android будут прекрасно работать. Проблема в оставшихся 25%. Чем более требовательно приложение к ресурсам, тем более вероятно, что оно не будет работать. Всё с хорошей графикой, включая большинство игр, скорее всего просто не запустится.
Наукообразненько. Интересно, автор статьи имел в виду native код, который используется в некоторой (интересно, в какой) части java прложений под android? Или что-то другое? При чем тут загадочные «ресурсы»?
Native код очень активно используется. У меня половина софта с нативными либами точно. И это не считая игр, которых 80% с нейтивом. А с распространением таких движков как Unity, игр без нейтива не останется в принципе. Ява — это ололо какая тормозня и тонна ограничений.
Ну насчет «тормозной джавы» — это религиозная фигня, для фронт-энда и бизнес-логики большинства приложений производительности джавы хватает за глаза. А причина активного использования нейтивного кода в играх — это переносимость между пратформами и доступность огромного количество игровых библиотек, которые в абсолютном большинстве на С или С++. Игры — такой класс приложений, где не требуется «родной» для платформы вид и сильная интеграция с системой, что делает написание их на «дефолтных» языках (например Java/ObjectiveC) как минимум нерациональным. А с библиотеками вроде Marmalade можно легко добиться 100% общего кода на разных платформах.
Интересно, за что минусуют… :)
За многое…
>>Ну насчет «тормозной джавы» — это религиозная фигня"
В C/C++, как минимум, есть возможность прямой работы с памятью. Писать код с указателями немного опасно криворуким людям, но конечный результат восхищает. Так что «тормознутость жабы» имеет место быть.
>>А причина активного использования нейтивного кода в играх — это переносимость между пратформамии и доступность огромного количество игровых библиотек, которые в абсолютном большинстве на С или С++.
Вы что, какая переносимость? Переносимость как раз в Java (C# и еже с ними) — там байткод, который автоматически компилируется в нативный на конечном хосте (виртуалки уже давно не используются, так что в этой части «тормознутость жабы» — миф :) ). В общем код на Java как раз кросс-платформенный. В свою очередь код на C/С++ разработчику надо самостоятельно скомпилировать под всё платформы (Gentoo не в счёт :) ).
>>Ну насчет «тормозной джавы» — это религиозная фигня"
В C/C++, как минимум, есть возможность прямой работы с памятью. Писать код с указателями немного опасно криворуким людям, но конечный результат восхищает. Так что «тормознутость жабы» имеет место быть.
>>А причина активного использования нейтивного кода в играх — это переносимость между пратформамии и доступность огромного количество игровых библиотек, которые в абсолютном большинстве на С или С++.
Вы что, какая переносимость? Переносимость как раз в Java (C# и еже с ними) — там байткод, который автоматически компилируется в нативный на конечном хосте (виртуалки уже давно не используются, так что в этой части «тормознутость жабы» — миф :) ). В общем код на Java как раз кросс-платформенный. В свою очередь код на C/С++ разработчику надо самостоятельно скомпилировать под всё платформы (Gentoo не в счёт :) ).
Перенести сишный код с android на iOS гораздо проще, чем java-программу:)
>В C/C++, как минимум, есть возможность прямой работы с памятью. Спасибо кэпПисать код с указателями немного опасно криворуким людям, но конечный результат восхищает. Так что «тормознутость жабы» имеет место быть.
Про прямую работу с памятью — это КО а все остальное — это ерунда. Прямая работа с памятью это не то, что делает С/С++ быстрее, а отсутствие VM. Но VM, как и любой дополнительный уровень абстракции хоть и снижает производительность, это не значит что любой язык использующий VM — «тормознутый». Все зависит от задачи и ресурсов. Во многих случаях N процентов прироста в использовании процессора и памяти и окупаются другими преимуществами, например сокращение времени разработки.
Если что, я как основной инструмент использую именно C++ (потому что род задач такой), но в выборе инструментов важен прагматизм и сильно вредит религиозный догматизм.
>Вы что, какая переносимость? Переносимость как раз в Java (C# и еже с ними) — там байткод
Кэп, я про переносимость между мобильными платформами, которые далеко не все поддерживают Java, но почти все поддерживают компилируемый C/C++ код (кроме WP у которого тоже скоро добавят поддержку native code).
Про прямую работу с памятью — это КО а все остальное — это ерунда. Прямая работа с памятью это не то, что делает С/С++ быстрее, а отсутствие VM. Но VM, как и любой дополнительный уровень абстракции хоть и снижает производительность, это не значит что любой язык использующий VM — «тормознутый». Все зависит от задачи и ресурсов. Во многих случаях N процентов прироста в использовании процессора и памяти и окупаются другими преимуществами, например сокращение времени разработки.
Если что, я как основной инструмент использую именно C++ (потому что род задач такой), но в выборе инструментов важен прагматизм и сильно вредит религиозный догматизм.
>Вы что, какая переносимость? Переносимость как раз в Java (C# и еже с ними) — там байткод
Кэп, я про переносимость между мобильными платформами, которые далеко не все поддерживают Java, но почти все поддерживают компилируемый C/C++ код (кроме WP у которого тоже скоро добавят поддержку native code).
>Но когда он сократится до 14 нм Intel сможет предложить такие тонкие смартфоны, каких еще не было
Наш смартфон на 8 нанометров тоньше всех! Вы этого все равно не заметите, но можете гордиться!
Сделай сам: как с помощью простой шкурки сделать самый тонкий смартфон ещё на 100500 нанометров тоньше на том же процессоре!!!
:)
Наш смартфон на 8 нанометров тоньше всех! Вы этого все равно не заметите, но можете гордиться!
Сделай сам: как с помощью простой шкурки сделать самый тонкий смартфон ещё на 100500 нанометров тоньше на том же процессоре!!!
:)
ARM — это в первую очередь энергоэффективная архитектура. И при одинаковом техпроцессе ARM всегда будет более эффективным и мобильным чем x86. Intel может конкурировать с ARM только за счет опережения конкурентов по техпроцессу и ARM всегда будет дышать затылок. И когда нибудь, когда intel новый техпроцесс освоит так легко (бесконечная миниатюризация не возможна) ARM сожрет х86 и Intel возможно будет выпускать процессоры с архитектурой ARM.
Вообще Intel уже выпускала ARM в свое время. Про StrongARM погуглите.
Интел может банально начать распараллеливать всё на ядрах, выигрывая за счёт более низкой частоты на ядро, что выльется в практически бесконечную гонку. Не только уменьшать техпроцесс, но и увеличивать ядра. Пока ядро одно у Медфилда с гипертредингом, а он уже рвёт в клочья четырёхядерные Тегры по производительности в Sunspider, и показывает сносное энергопотребление. Lava XOLO X900 — первый смартфон на Medfield.
Я вроде говорил про архитектуры в принципе а не про конкретные процессоры.
Если процессоры которые вы сравниваете привести к общему знаменателю.
Sunspider — это однопоточный тест? При чем тут Tegra с 4 ядрами?
Medfield — 32 nm Tegra — 40 nm.
И если говорить про потребление то нужно мерить потребление одного ядра, без всего того, что на этих SoC наворочено (например видео). В спецификации обычно пишут сколько весь чип потребляет в пике.
Вы в принципе согласны с тезисом, что для вычисления некого Х на ARM энергии потребуется меньше чем на х86 и сам ARM будет меньше и как следствие дешевле при прочих равных условиях (не беря в расчет время расчета)?
То, что одно ядро x86 на такт более производительное я с этим не спорю.
В десктоп сегменте актуально выдавать максимальную производительность на одно ядро (не все можно распаралелить, по крайней мере еще не все распаралелено) ценой практически безлимитного потребления (десктоп подключен к розетке)
В мобильном сегменте все упирается в емкость аккумулятора (энергию надо экономить, иногда ценой производительности)
Если процессоры которые вы сравниваете привести к общему знаменателю.
Sunspider — это однопоточный тест? При чем тут Tegra с 4 ядрами?
Medfield — 32 nm Tegra — 40 nm.
И если говорить про потребление то нужно мерить потребление одного ядра, без всего того, что на этих SoC наворочено (например видео). В спецификации обычно пишут сколько весь чип потребляет в пике.
Вы в принципе согласны с тезисом, что для вычисления некого Х на ARM энергии потребуется меньше чем на х86 и сам ARM будет меньше и как следствие дешевле при прочих равных условиях (не беря в расчет время расчета)?
То, что одно ядро x86 на такт более производительное я с этим не спорю.
В десктоп сегменте актуально выдавать максимальную производительность на одно ядро (не все можно распаралелить, по крайней мере еще не все распаралелено) ценой практически безлимитного потребления (десктоп подключен к розетке)
В мобильном сегменте все упирается в емкость аккумулятора (энергию надо экономить, иногда ценой производительности)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Смартфоны Intel inside: x86 во всех карманах страны?