Apple откажется от Intel и перейдёт на собственные чипы в Mac Статьи редакции
«Исторический день для Mac».
Apple объявила об отказе от Intel и переходе на процессоры собственной разработки в Mac на WWDC 2020. Трансляция конференции для разработчиков велась на YouTube-канале компании.
Первые компьютеры с процессором Apple выйдут в конце 2020 года. Компания рассчитывает завершить переход в течение двух лет.
Разработка позволит Apple обеспечить более высокую производительность при большей энергоэффективности, объяснили в компании.
Для адаптации приложений под Apple Silicon нужно использовать новую версию XCode. О поддержке Apple Silicon уже заявили Microsoft и Adobe. В качестве иллюстрации компания показала, как работает Photoshop.
Для разработчиков, которые не успеют перенести свои приложения под новую архитектуру, компания создала технологию Rosetta 2, которая позволит автоматически адаптировать их. Технология Universal 2, наоборот, позволит запускать приложения для процессоров Apple на Intel.
Для разработчиков Apple выпустит специальную версию Mac mini для создания приложений на Mac с собственными чипами.
Хотя и ожидаемый, но сильный ход сделал Эппл. Теперь текущая линейка даже самый топовый МакБукПро 16" морально устарел - моща есть, но уже не та арихитектура)) Выбрасывай и покупай новый)).
И похоже любителям запускать Виндовз на железе Эппл придется туго. В теории Виндовз АРМ архитектуру поддерживает, но драйверы.. Скорее всего вариант использвания Виндовз на железе Эппл будет теперь невозможен.
Ждём эмулятор. Дожили. Процессор от телефона будет эмулировать настольный комп с его сотом.
С эмулятором непонятно. На демо мелькал Параллелис, что там будет виртуализироваться и эмулироваться - большой вопрос. Скорее всего, будет эмулироваться прикладной софт, а виртуализироваться уже нативный.
При таком сценарии (если мои предположения верны) Виндовз не запустишь никак, если только Эппл и Микрософт не договорятся между собой.
Это правда. Показывали виртуализацию Linux, но не уточнили, на какой архитектуре была инсталляция (x86, ARM?) и какой был tradeoff по производительности.
Следите за руками - 1:44:26 :)
👍🏼
Я думаю, что скорее всего будет поддерживаться только АРМ эдишен.
А суть Параллелиса - это задействование аналогов VT-d /VT-x на АРМ архитектуре Эппл. Ну и/или что-то типа KVM будет.
Учитывая, что этот момент не акцентировали — тоже так думаю. Но это сильно ограничит, к сожалению, виртуализацию для разработчиков — все же желательно проверять свои приложения на целевой архитектуре (x86), а не обнаружить, что something went wrong только после передачи кода в контур CI.
Но похоже Эппл списало х86 со счетов, так что в их картине мира разработка под х86 уже никому не понадобится))
Apple же сама приводила примеры web-разработчиков. Там x86 не списан со счетов.
Думаю, вопрос проще. Intel много финансировали в виртуализацию — это оплачивал серверный рынок, где на это был большой спрос, — к тому же у них еще и целью была оптимизированная гомогенная виртуализация x86->x86.
У Apple при отсутствии фокуса на этом направлении и необходимости в гетерогенной виртуализации, скорее всего, просто не было возможности сделать адекватное решение. Ну и не будет на это фокуса — серверный рынок для них не так актуален.
Зачем веб разработчикам х86?!
Веб — это не только Javascript. Там еще и бэк есть. А даже та же Java (или node.js) на x86 и на ARM может очень по разному себя вести в плане Performance хотя бы. А уж о различных Rust, Go и пр. я и вовсе молчу.
Проблемы performance для бэка обычно тестированием проверяют - и не на рабочей машине. Разработке ничего не помешает. Для остального есть Облако с CI.
Первичное тестирование всегда делает, вольно или нет, разработчик. Если у него приложение будет жестко лагать из-за того, что какая-то функция JVM не оптимизирована под ARM — разработка будет очень грустным зрелищем.
И с различными Go, Rust, C++ и пр. что предлагаете делать? Забыть о локальном тестировании и отладке? Там и поведение между архитектурами может отличаться (как и в JVM, пусть и с меньшей веростностью).
Не зря Apple говорит, что разработчикам в простых (!) случаях нужно будет потратить несколько дней на адаптацию приложения.
Оптимизацией JVM занимаются разработчики JVM. Высок шанс, что очевидные проблемы быстро поправят - платформа маков довольно большая и популярная.
Для всего остального - не вижу проблем. Разрабатывайте на одной архитектуре - тестируйте на всех других. Как будто мало софта разрабатывалось на macOS и работало на Linux. А разница в работе ОС даже больше / не меньше чем у архитектур процессоров, кмк.
Но пока они ей не занялись — боль из-за нее испытывают разработчики.
Высок шанс, что очевидные проблемы быстро поправят - платформа маков довольно большая и популярная.Не факт. Во-первых, не такая и большая. Во-вторых, основной рынок — все-таки server side. Инструменты разработки, которыми являются маки, это, конечно, важно, но всегда можно предложить использовать удаленную виртуалку на целевой архитектуре.
Как будто мало софта разрабатывалось на macOS и работало на LinuxCome on. Почти всегда для этого локально установлена виртуалка с Linux. Как раз из-за разницы в работе ОС.
А разница в работе ОС даже больше / не меньше чем у архитектур процессоров, кмк.Не факт. С учетом того, что до этого десктопный или серверный ARM был достаточно маргинальной платформой, не думаю, что под них кто-то оптимизировал компиляторы и активно чинил их баги.
Вот именно - вся проблема была оттого, что ARM архитектура на компах была маргинальной. А Эппл сделает её мейнстримовой - то есть все баги могут пофиксить довольно быстро.
Но первые устройства я бы не советовал покупать в качестве единственного у разработчика))
Это да. Но они хотят это изменить. Серверная версия Mac Pro есть.
Не видно преимуществ эппл-сервера для пользователей. Специфического серверного софта - нет. Под капотом - тот же юникс. Конкурировать придётся примерно со всеми и с линуксом, который почти победил в серверах.
Смысла видно мало.
Единственная идея - сделать мощный арм-сервер. Но эппл добавляет к процессору обвес для потребительских устройств - на обычном сервере он нужен не весь, и не факт, что нужен. Может, они сделают специфический сервер для каких-то нейросетей или видеообработки.
Это пока (на мой взгляд) не выглядит как какие-то серьезные сподвижки. Но кто знает. С учетом постепенного роста ARM-серверов, может, Apple сделает здесь свои решения.
Но сомневаюсь, что в ближайшее время. Все же слишком сильно отличаются требования к серверному оборудованию (и, в принципе, рынок, модель продаж(, а голый камень от Apple, скорее всего, никому не нужен.
У Apple сейчас и так будут полные руки развития модели сервисов (Arcade, TV+, ...), чтобы распылаться на совсем другой рынок с другими законами.
Для Эппла нужны легковесные варианты виртуализации или её аналоги, т.к. они понимают, что нужно поддерживать контейнеризацию, иначе потеряют долю рынка. Вот что-то такое они и сделали на новой архитектуре (как я понял).
Сервер для Эппла пока не актуален, зато сейчас, когда у них везде будет АРМ своей разработки они смогут максимально унифицировать железо и снизить себестоимость. Думаю, прибыль от реализации настольных устройств/ноутбуков имеет шанс поставить очередной рекорд))
Надеюсь, что настольные компьютеры с АРМ от Эппл сделают идею компьютеров с АРМ популярнее и появится много решений с АРМ для серверов.
осталось Microsoft заплатить триллион денег Figma, FL, Evernote, Notion и сделать их эксклюзивами Windows, пускай страдают
Evernote они не купят. Прямой конкурент MS OneNote.
Не думаю, что текущие архитектуры потянут эмуляцию.
Возможно - будущие потянут. Чипы для телефонов оч дешевые - и их можно много воткнуть. 32 ядра в пользовательском компе? Легко и дёшево. Особенно, если речь идёт о вычислительных ядрах без доп обвеса
Если речь о железе, то уже тянут. Версия АРМ архитектуры у Эппл очень удачная.
Чипы для телефонов оч дешевые - и их можно много воткнутьДешевые только за счет массового производства, а так вовсе нет.
Сложно судить - тянут или нет.
Но, думаю, эмуляцию сделают. Чтобы можно было legacy soft под Windows запустить на новом маке с армом. Crypto pro - вот это все.
32 ядра не дадут сэмулировать хорошую 1-ядерную производительность. :) С учетом того, что софт для x86 расчитан на небольшое количество ядер, не факт, что 32 шт. сейчас дадут значимую компенсацию эмулации.
Можно будет все запущенные процессы разложить по ядрам - работать как то будет. В общем, чем 8 слабых ядер, лучше 32 слабых ядра!