{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Bloomberg: Apple выпустит Mac с процессором собственного производства вместо чипа от Intel в 2021 году Статьи редакции

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

Apple разрабатывает три собственных процессора для компьютеров Mac на базе чипов A14, которые появятся в будущих моделях iPhone, сообщает Bloomberg со ссылкой на источники.

Компания хочет выпустить первый компьютер на собственном процессоре уже в 2021 году. Собирать новые чипы будет Semiconductor Manufacturing, тайваньский партнёр Apple по производству процессоров для iPhone и iPad, говорят собеседники издания.

Так Apple стремится получить больший контроль над производительностью собственных устройств и конкурентное преимущество, пишет Bloomberg. В частности, Apple перестанет зависеть от Intel, нынешнего поставщика процессоров для Mac.

Intel с трудом поддерживает ежегодный прирост производительности, который сама предлагала, утверждает Bloomberg. Это станет ударом по репутации Intel, пишет издание.

Переход на собственные разработки процессоров Apple, скорее всего, начнёт с нового ноутбука, поскольку первые чипы для Mac не смогут конкурировать с производительностью, которую Intel обеспечивает для MacBook Pro, iMac и настольных компьютеров Mac Pro, отмечает Bloomberg.

Первые процессоры для Mac будут включать восемь высокопроизводительных ядер с кодовым названием Firestorm и минимум четыре энергоэффективных ядра Icestorm. В будущем Apple планирует выпускать процессоры более чем с 12-ю ядрами, отмечают источники издания.

Представители Apple и Intel отказались от комментариев.

0
163 комментария
Написать комментарий...
Злой Полушубок

Далеко не весь софт есть под ARM платформу. И это создает проблемы. Захочет ли Адоб возиться с портированием своего софта на ARM или скажут кушайте версию для айПада?
Много разработчиков используют маки и тут тоже встает вопрос с специфическим софтом.

Второй вопрос: а они все свои компы собираются переводить на ARM? И Mac Pro? Или будут сидеть на 2-х стульях?

Ответить
Развернуть ветку
Bulat Ziganshin

странно почему для айпада они совсем новый софт написали, а для макбука портировать не захотят

Ответить
Развернуть ветку
Злой Полушубок

Для айпада доступен сильно урезанный фотошоп. И тут получается или такой же обрезанный делать для макбуков на АРМ или портировать полноценный фотошоп на АРМ. И решение будет зависеть от ответа на второй вопрос - Mac Pro и iMac останутся на интелах или перейдут на АРМ.

Ответить
Развернуть ветку
Bulat Ziganshin

правильно написанный софт уже портабелен

Ответить
Развернуть ветку
Злой Полушубок

А вы можете сказать в чем отличие модели памяти ARM от x86?

Ответить
Развернуть ветку
Bulat Ziganshin

нет. а вы понимаете, что когда вы пишете на ЯВУ - вы используете модель памяти этого языка, а не процессора?

Ответить
Развернуть ветку
Злой Полушубок

Вот только фотошоп не написан на Яве и не может быть на ней написан, в силу того что это очень критичное к производительности приложение.
И тут выясняется что у С++ модели памяти нет, она зависит от целевой платформы. И значит или надо писать версии кода для критичных к производительности участков. Плюс надо ловить всякие специфичные баги, типа https://habr.com/ru/post/320342/

Когда мигрировали с Power на x86 там было ясно ради чего - обобщение кодовой базы с Windows портом. А тут сильно непонятно зачем поддерживать платформу с непонятным перформансом и охватом пользователей.

Ответить
Развернуть ветку
Make Luv

Кмк ЯВУ тут это язык высокого уровня, а не, прости господи, жава.

Ответить
Развернуть ветку
Злой Полушубок

C++ - ЯВУ? ЯВУ!
Но там нет своей, независимой от целевой платформы архитектуры памяти.

Ответить
Развернуть ветку
Bulat Ziganshin

этот вывод ты сделал на основании одной статьи?

Ответить
Развернуть ветку
Злой Полушубок

До C++ 11 там вообще её не было, после появилась но поддержка но не полная, например hardware_destructive_interference_size поддержиается MSVC но не GCC, а вот с Coroutines наоборот.

А ещё есть другие приколы: можно сделать CAS на 128 битные данные и где-то это будет честный CAS, а где-то будет lock - просто платформа не обеспечивает такого. Семантика соблюдена, а производительность идет по бороде.

Ответить
Развернуть ветку
160 комментариев
Раскрывать всегда