Прогрес ARM процесорів

[dext]

У вас якесь упереджене ставлення до яблучної продукції.

Саме так: через закритісь та несумісність, бо навіть за часів x86 у віртуалці було складно запустити макос, і працювало воно в режимі слайд-шоу, поради купити мак щоб хоч щось розробляти/протестувати під мак це і є визначення "вендор лок"

Ви так пишете ніби Mac-и на M чипах не варті уваги взагалі, а це не так, геть не так.
Від себе можу додатии мало що але по власному досвіду Mac-и на M-чипах відрізняються дуже пристойною автономністю, звичайно не у всих кейсах використання, але в більшості типових завдань, ноути на Intel/AMD поруч не стоять, взагалі.

Я вже писав якщо влаштовує софт, закрита екосистема, одноразовість by design - без питань.
Якщо потрібна сумісність, розширюваність, ринкові ціни, підтримка стандартів, DIY - це принципово не до яблука, і поки що не до АРМ

І тим більше не потрібно нав'язувати що якщо більшість невибагливих користувачів не знають про можливість поставити другу плашку DRAM, то їм обов'язково потрібно впарити значно дорожчий мак, бо вони і не здогадуються як же погано живуть на x86 (ні), це якраз типові маніпуляції релігійних сектантів.

Щодо автономності: типові сценарії тестування на відтворення відео залежать від ефективності апаратних декодерів та модулів wifi, які до архітектур ЦП не мають жодного відношення, і чи не найбільший внесок взагалі вносить екран

Тематика цього форуму завжди в контексті DIY, тому просувати одноразові моноліти на закритій екосистемі - якось не те, не знаходите?

[yuriy_dd]

з O3 вмикається loop unrolling

але ви ж знаєте що loop unrolling вмикається і з О2 - лише на старих не вмикається. Ви застрягли в минулому?

давно відомий мені, але не вам баг з -O3: https://dev.mysql.com/worklog/task/?id=10343

там ж написано -

where the GCC is so old

Ви застрягли в минулому?

-ffast-math
активує небезпечні оптимізації без урахування вимог стандарту ieee754 - як от некоректну поведінку при обробці NaN

чому я за 30 років комерційного програмування не мав проблем з NaN?

в сучасних x86 ще з часів Core 2 Duo 2006-го року

для вас проц з 2006 - сучасний? Ви застрягли в минулому? Вас так радує що х86 має сумісність, і ви компілюєте свій код з огляду на проци 2006 року?

Як в сучасних ARM (aarch64) так і в старих (arm32) достатньо складних інструкцій накшталт ldmia/stmia/cbz/cbnz/ldp/stp

давайте розберемо одну з них, і порівняємо з тою що дав я?

Можете скинуть объективные тесты x86 vs ARM что бы понимать в каких обстоятельствах наиболее оптимально использовать разные машины

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

але в більшості типових завдань, ноути на Intel/AMD поруч не стоять, взагалі.

вони не вірять в це, і не мають можливості перевірити

Відправлено через 5 хвилин 35 секунд:

бо навіть за часів x86 у віртуалці було складно запустити макос

а до чого тут АРМ?

закрита екосистема

це ваша хвора уява. Чому весь новий сучасний софт в більшості вперше зявляється під МакОС?

одноразовість by design

таке точно є стосовно більшості тех пристроїв

потрібно впарити значно дорожчий мак

нема нічого і близько до макбук ейр за ту саму ціну. Все що на х86 - і дорожче і гірше

Щодо автономності: типові сценарії тестування на відтворення відео залежать від ефективності апаратних декодерів та модулів wifi

але якщо люди користуються поштою, месенджерами, браузером, офіс і тд - і автономність значно вища, і нема падіння швидкодії?

Тематика цього форуму завжди в контексті DIY, тому просувати одноразові моноліти на закритій екосистемі - якось не те, не знаходите?

що? це хто вирішив?

Відправлено через 2 хвилини 34 секунди:

бо мало хто з O3 компілює релізи

тобто компанії вкладають млрд $ в оптимізації - щоб якийсь відсталий від тех прогресу заявив що нікому оптимізації не треба, бо він має статтю 20-ти річної давності що колись були проблеми?

[AntonyKandaurov]

Чому весь новий сучасний софт в більшості вперше зявляється під МакОС?

Приклади? Їх не буде бо:
- абіженка
- шукайте самі, доцент дуже зайнятий. Він вміє тільки ляпати і тікати в кущі

що? це хто вирішив?

Достатньо почитати хоча б останню новину на сайті про 2080ті та її моддінг. І щось ніхто тут не постить новини про величний епл, бо мабуть це нікому не цікаво окрім пари сектантів

[waryag]

це ваша хвора уява. Чому весь новий сучасний софт в більшості вперше зявляється під МакОС?

Ні дня без брехні, Юрчику?

[Ekz0rcyst]

Саме так: через закритісь та несумісність, бо навіть за часів x86 у віртуалці було складно запустити макос, і працювало воно в режимі слайд-шоу, поради купити мак щоб хоч щось розробляти/протестувати під мак це і є визначення "вендор лок"

Ну хоч без лицемірства, чітко сформулювали свою позицію, це добре, я таке вітаю.

Я вже писав якщо влаштовує софт, закрита екосистема, одноразовість by design - без питань.
Якщо потрібна сумісність, розширюваність, ринкові ціни, підтримка стандартів, DIY - це принципово не до яблука, і поки що не до АРМ

Тут все теж 50/50, розширюваність у x86 десь є десь немає, ринкові ціни теж сумнівно, бо в купі якісний пристрій буде коштувати однаково і не тільки Apple хоче заробити кошти, DIY тут з вами згоден, всі 100500% не до яблука, але як бачимо і x86 йде тією ж доріжкою.

І тим більше не потрібно нав'язувати що якщо більшість невибагливих користувачів не знають про можливість поставити другу плашку DRAM, то їм обов'язково потрібно впарити значно дорожчий мак, бо вони і не здогадуються як же погано живуть на x86 (ні), це якраз типові маніпуляції релігійних сектантів.

Тут я з вами згоден, що розширюваність важлива бо це зручно, і наївно це не визнавати, тому тут я з вами на 100% погоджуюсь.

Щодо автономності: типові сценарії тестування на відтворення відео залежать від ефективності апаратних декодерів та модулів wifi, які до архітектур ЦП не мають жодного відношення, і чи не найбільший внесок взагалі вносить екран

І тим не менш ARM Mac-и "живуть" від батарейки довго, в порівнянні із x86 "колегами", тому архітектури CPU мають значення. Та й щось смартфони на x86 так і не зайняли свою нішу, а я пам'ятаю як Intel намагався зайняти цей сегмент і ніфіга не вийшло бо автономність була в порівнянні із ARM смартфонами нікчемна.

Тематика цього форуму завжди в контексті DIY, тому просувати одноразові моноліти на закритій екосистемі - якось не те, не знаходите?

Тематика цього форуму про технології в цілому, а не DIY чи не DIY Apple теж є частиною цього, подобається вам це чи ні, саме тому ми власне і бачимо новини про нові Mac-и тут на сайті і взагалі існує подібна дискусія Та й ті ж Intel NUC і подібні пристрої minisforum вам у приклад, та й прикладів насправді достатньо.

[dext]

але ви ж знаєте що loop unrolling вмикається і з О2 - лише на старих не вмикається. Ви застрягли в минулому?

агресивний loop unrolling, далі все актуальне

Ви застрягли в минулому?

це (витіснення з L1) мікроархітектурна проблема, а не проблема GCC - що знову демонструє відсутність компетенції

чому я за 30 років комерційного програмування не мав проблем з NaN?

вочевидь - тому що чхати хотіли на стандарти і ніколи не мали справ з NaN

для вас проц з 2006 - сучасний? Ви застрягли в минулому? Вас так радує що х86 має сумісність, і ви компілюєте свій код з огляду на проци 2006 року?

рекомендації не вмикати O3 йдуть саме з тих часів, що є справедливим також і для сучасних ЦП - що знову демонструє відсутність компетенції та ставить під сумнів "30 років комерційного програмування", якщо вас взагалі цікавила продуктивність коду

давайте розберемо одну з них, і порівняємо з тою що дав я?

добре:

Код: Виділити все

LDMIA r0!, {r4-r6, pc}

а до чого тут АРМ?

це про яблуко за часів x86, за часів ARM - це вже практично неможливо, тотальний vendor lock

це ваша хвора уява. Чому весь новий сучасний софт в більшості вперше зявляється під МакОС?

повністью переписані під пропрієтарні і ні з чим не сумісні API яблука (як от Metal) - що є канонічним визначенням закритої екосистеми

таке точно є стосовно більшості тех пристроїв

в світі ARM, не в світі x86

нема нічого і близько до макбук ейр за ту саму ціну. Все що на х86 - і дорожче і гірше

нікому окрім фанатів яблука не потрібна одноразова поробка - доведено ще за часів ейр на x86

але якщо люди користуються поштою, месенджерами, браузером, офіс і тд - і автономність значно вища, і нема падіння швидкодії?

для цього підійде будь-який android-планшет, купувати для цього ПК і тим більше емейзінг за оверпрайс - немає потреби

що? це хто вирішив?

мабудь ... назва та тематика форуму, з часів його створення?

тобто компанії вкладають млрд $ в оптимізації - щоб якийсь відсталий від тех прогресу заявив що нікому оптимізації не треба, бо він має статтю 20-ти річної давності що колись були проблеми?

Це ще раз доводить відсутність вашої компенетції, бо проблема з роздуттям/витісненням коду з L1 є фундаментальною тож навіть Торвальдс радить компілювати ядро з -Os/-O2, з -O3 його компілюють тільки ідіоти

[yuriy_dd]

Ні дня без брехні, Юрчику?

я ж вам дав приклад, знову забули? знову нагадувати одне й те ж по колу?

може ви дасте щось нове сучасне?

[waryag]

я ж вам дав приклад, знову забули? знову нагадувати одне й те ж по колу?

може ви дасте щось нове сучасне?

Клоуне, коли ти пишеш

весь новий сучасний софт в більшості вперше зявляється під МакОС

, то одного прикладу вкрай недостатньо. І якщо ти не розумієш чому, тебе треба гнати з освіти ссяним ганчір'ям.

[dext]

Тут все теж 50/50, розширюваність у x86 десь є десь немає

відверта маніпуляція, бо з x86 ви можете це прямо обрати, з яблуком - у вас такого вибору немає

ринкові ціни теж сумнівно

якщо виробники змовляться синхронно підвищити ціні - отримають штрафи, таке вже було неодноразово

Intel/AMD не продають готові системи з DRAM/NAND, тож на вільному ринку дискретні SSD 2TB за $1000 ніхто не купить.
У випадку яблука у вас немає вибору: намалюють хоч $2000 за 2TB - нікуди ви дінетесь, бо воно в складі SoC

І тим не менш ARM Mac-и "живуть" від батарейки довго, в порівнянні із x86 "колегами"

гарна оптимізація та інтеграці дуже обмеженої номенклатури SoC+OS, без тисяч варіантів та універсальності як в x86.
тому мак це супер, мак це енергоефективно, а як доходить до роботи - сидить пан yuriy_dd та аналізує логи з x86-серверів

архітектури CPU мають значення

ви неуважно прочитали, що я написав: апаратні декодери та періферія має значення, бо без них з SW-Decode будь-який АРМ помре дуже швидко, тому SoC (+iGPU) має значення, задача CPU при цьому - заснути якнайшвидше і не прокидатись якнайдовше

плюс щоб зайти на ринок смартів потрібно чи не щороку проектувати нові SoC а не лише ЦП, для AMD/Intel це означає пряму конкуренцію з власними замовниками (ASUS, MSI, Samsung) - тому вони не випускають ані телефонів, ані ноутбуків, ані готових ПК, ані мат. плат, лише універсальні ЦП/ГП/чіпсети, це простіше

Тематика цього форуму про технології в цілому, а не DIY чи не DIY Apple теж є частиною цього

яблуко це в першу чергу про "емейзінг", закритість та пропрієтарність, канонічний приклад - вимучений TypeC в іх смартфонах

також подивився на новий MacMini - куди підключати наявні type-a клавіатуру/мишу? зате є вбудований динамік розміром з ... M.2 2242, але динамік важливіше бо це перша сигнальна система, модульність та заміни усіляких ssd - друга, не потрібно користувачів такими знаннями напружувати

тож не бачу сенсу обговорювати компанію, яка своєю метою ставить в першу чергу нав'язування "емейзінг" рішень, а не задоволення реальних потреб (апгрейд SSD, апгрейд RAM, ...)

[yuriy_dd]

але ви ж знаєте що loop unrolling вмикається і з О2 - лише на старих не вмикається. Ви застрягли в минулому?
агресивний loop unrolling, далі все актуальне

якщо він вас так чешеться - його можна відключити
але ваш приклад згенерував би той самий код що з О2 що з О3 - просто ви не знаєте

Ви застрягли в минулому?
це (витіснення з L1) мікроархітектурна проблема, а не проблема GCC

такі тупі люди пишуть GCC, що не в курсі проблем - тільки одне світило на форумі знає краще за них

давайте розберемо одну з них, і порівняємо з тою що дав я?
добре:
LDMIA r0!, {r4-r6, pc}

а розбір де?

повністью переписані під пропрієтарні і ні з чим не сумісні API яблука (як от Metal)

взагалі не в курсі що це і для чого це. Швидкість виконання JavaScript в браузері - залежить від цього?

для цього підійде будь-який android-планшет

пробували в офісі документи редагувати на планшеті?

Відправлено через 6 хвилин 57 секунд:

то одного прикладу вкрай недостатньо

ну я навів, ви не змогли зробити нічого - як завжди

бо без них з SW-Decode будь-який АРМ помре дуже швидко

браузер працює найшвидше і найдовше. Ви знову обманюєте, або не знаєте

тому вони не випускають ані телефонів

Інтел втратив 17 млрд $ прагнучи попасти в мобільні - але фанат х86 на таке не знважає, і придумали собі відмазку

намалюють хоч $2000 за 2TB - нікуди ви дінетесь, бо воно в складі SoC

ну це ви знову обманюєте або не знаєте - як завжди - на макміні можна замінити ссд
давайте вибачайтесь що знову маячню зморозили

також подивився на новий MacMini - куди підключати наявні type-a клавіатуру/мишу?

прикол в тому - що підключена клавіатура споживає більше ніж сам мак міні в стані спокою. Тому так - підключати через bluetooth
ви знаєте про такі пристрою? чи у ваші ноути з 2006 такого не мають?

[isusik63]

але ви ж знаєте що loop unrolling вмикається і з О2 - лише на старих не вмикається. Ви застрягли в минулому?
агресивний loop unrolling, далі все актуальне

якщо він вас так чешеться - його можна відключити
але ваш приклад згенерував би той самий код що з О2 що з О3 - просто ви не знаєте

Ви застрягли в минулому?
це (витіснення з L1) мікроархітектурна проблема, а не проблема GCC

такі тупі люди пишуть GCC, що не в курсі проблем - тільки одне світило на форумі знає краще за них

давайте розберемо одну з них, і порівняємо з тою що дав я?
добре:
LDMIA r0!, {r4-r6, pc}

а розбір де?

повністью переписані під пропрієтарні і ні з чим не сумісні API яблука (як от Metal)

взагалі не в курсі що це і для чого це. Швидкість виконання JavaScript в браузері - залежить від цього?

для цього підійде будь-який android-планшет

пробували в офісі документи редагувати на планшеті?

Відправлено через 6 хвилин 57 секунд:

то одного прикладу вкрай недостатньо

ну я навів, ви не змогли зробити нічого - як завжди

бо без них з SW-Decode будь-який АРМ помре дуже швидко

браузер працює найшвидше і найдовше. Ви знову обманюєте, або не знаєте

тому вони не випускають ані телефонів

Інтел втратив 17 млрд $ прагнучи попасти в мобільні - але фанат х86 на таке не знважає, і придумали собі відмазку

намалюють хоч $2000 за 2TB - нікуди ви дінетесь, бо воно в складі SoC

ну це ви знову обманюєте або не знаєте - як завжди - на макміні можна замінити ссд
давайте вибачайтесь що знову маячню зморозили

також подивився на новий MacMini - куди підключати наявні type-a клавіатуру/мишу?

прикол в тому - що підключена клавіатура споживає більше ніж сам мак міні в стані спокою. Тому так - підключати через bluetooth
ви знаєте про такі пристрою? чи у ваші ноути з 2006 такого не мають?

Выпили ? Дерзкий вы Юрий стали

Если в теме посчитать сколько вас в "га..о" макали носом то вы за мучаетесь извинятся .
Вам человек пишет про отсутствие функционала (юсб) , вы опять про энергопотребление .

Вы не отвечаете на неудобные вопросы/факты а просто игнорируете или отвечаете словесным бредом не имеющего нечего общего к вопросу и опять заводите мантру про энерго потребления ...
Конструктивного разговора с вами не построить (ну судя из темы не кому это не удалось пока).
Если вы реально преподаватель то это печально ,
я так понимаю медосмотр покупаете (по психике так точно).

[AntonyKandaurov]

Просто цей товариш не в курсі що таке блютуз пристрої і як агресивна політика енергозбереження бісить в роботі коли кожні 5 секунд мишка або клава засинає і потрібно їх пробудити.
Мабуть хороші девайси недарма мають в комплекті свистки для роботи в 2.4ггц діапазоні, а ще краще можливість працювати з кабеля.
Але ж це треба мати досвід, а не ляпати язиком бо про це тобі колись за пляшечкою розповів інший доцент іншої кафедри.

[dext]

якщо він вас так чешеться - його можна відключити
але ваш приклад згенерував би той самий код що з О2 що з О3 - просто ви не знаєте

чудовий приклад створення проблеми на порожньому місці і її героїчного вирішення

такі тупі люди пишуть GCC, що не в курсі проблем - тільки одне світило на форумі знає краще за них

роздуття коду від loop unrolling - це нормальна поведінка, ненормальна поведінка - всюди пхати O3 без розуміння побічних наслідків

а розбір де?

як "експерт і знавець по ARM" та людина з 30-річним комерційним досвідом ви розбираєте ARM, я розбираю x86, чи не так, які проблеми?

взагалі не в курсі що це і для чого це. Швидкість виконання JavaScript в браузері - залежить від цього?

я про системні API накшталт Metal, ні з чим не сумісні, ви мені про JavaScript...

пробували в офісі документи редагувати на планшеті?

для роботи в мене є ергономічне крісло, повнорозмірна клавіатура, великий екран та стаціонарний ПК з 96ГБ RAM -- напевно все те, чого ви не маєте через переплату за "емейзінг"

браузер працює найшвидше і найдовше. Ви знову обманюєте, або не знаєте

браузер підчас відтворення відео не працює, всю роботу на себе бере аппаратний декодер відео

Інтел втратив 17 млрд $ прагнучи попасти в мобільні - але фанат х86 на таке не знважає, і придумали собі відмазку

скільки яблуко втратило прагнучи попасти в сервери/hpc/top500? ах, воно ж навіть не намагалося, цікаво чому?

ну це ви знову обманюєте або не знаєте - як завжди - на макміні можна замінити ссд
давайте вибачайтесь що знову маячню зморозили

2TB Storage скільки коштують в яблучних поробках, офіційно щоб не втрачати гарантію?

прикол в тому - що підключена клавіатура споживає більше ніж сам мак міні в стані спокою.

тобто пряма відповідь - існуючу type-a періферію до емейзінгу підключати нікуди

що підключена клавіатура споживає більше ніж сам мак міні в стані спокою

що за маячня ... більше 1w, більше 2w, більше 3w?

Тому так - підключати через bluetooth

що так, куди підключати існуючі type-a блютус ресівери?

Натурально, спитав чому яблуко за користувачів вирішило прибрати всі USB-A і замінити іх на USB-C, а у відповідь отримав відверту маячню

[AntonyKandaurov]

dext

що за маячня ... більше 1w, більше 2w, більше 3w?

Ну типу 5в 500мА, типу 2.5вт бере але ж це просто максимум який видає не зарядний юсб порт. Реальне споживання нижче, але ж то доцент теоретик, неважливо що він пише бо це або маніпуляція або брехня.

Відправлено через 1 хвилину 32 секунди:

що так, куди підключати існуючі type-a блютус ресівери?

Типу в макміні вже є блютуз і можна підключати блютуз клаву і мишу. Але є купа нюансів, про які я вже писав вище

[yuriy_dd]

Вам человек пишет про отсутствие функционала (юсб)

людина застрягла в 2006 буде ще нити що і VGA, LPT, COM портів нема
те що можна підєднати перехідник на typeA - він не в курсі
він буде говорити про все окрім швидкості процесора, результатів тестів і тд

[tornadox]

бо навіть за часів x86 у віртуалці було складно запустити макос

Зараз з цим значно простіше, на лінуксі завести доволі легко https://github.com/kholia/OSX-KVM
Для користувачі Unraid є плагін Macinabox який сам все робить. Для дебага і розробки цього більш ніж хватає, а якщо прокинути відеокарту АМД то і буде відеоприскорення.
Ще на старому unraid сервері бавився.

спойлер

Кому цікаво залишу відео.

[dext]

Ну типу 5в 500мА, типу 2.5вт бере але ж це просто максимум який видає не зарядний юсб порт. Реальне споживання нижче, але ж то доцент теоретик, неважливо що він пише бо це або маніпуляція або брехня.

Type-C взагалі 20v5a = 100w тож підключати нічого не можна, краще щоб цих портів взагалі не було, дякуємо яблуку за турботу про енергоефективність

Типу в макміні вже є блютуз і можна підключати блютуз клаву і мишу. Але є купа нюансів, про які я вже писав вище

ну так, багато періферії цже з власними ресіверами та без можливості створення пар, до того ж в UEFI bt-стек не працює

Зараз з цим значно простіше

нуу... за часів x86 це можна було зробити на virtualbox + windows + інструкція була значно коротшою, але воно все одно гальмувало, тому такий собі прогрес ...

людина застрягла в 2006 буде ще нити що і VGA, LPT, COM портів нема
те що можна підєднати перехідник на typeA - він не в курсі

чому ви так тригернулись на просте питання, чому кожного разу пропонуєте купувати перехідники там, де вони в нормальних ПК не потрібні?
бо зі сторони виглядає так, що не тільки мак потрібно купити, а також сумісну клавіатуру, мишу, дбж (щоб по usb моніторити стан), монітор (?), принтер (?), що ще забув?

також цікавий момент: в NAS лише найдешевші/бюджетні моделі з ARM, всі топові/продуктивні - на x86, чому так, невже виробники настільки дурні?

[artko]

Type-C взагалі 20v5a = 100w тож підключати нічого не можна, краще щоб цих портів взагалі не було

ну це вже зовсім відвертий троллінг нема ніяких проблем до type-c порту підключити щось , що потребує 5в.

[dext]

ну це вже зовсім відвертий троллінг нема ніяких проблем до type-c порту підключити щось , що потребує 5в.

ви знущаєтесь? світлодіод на numlock споживає більше ніж m6 ultra pro в cinebench-2077

[tornadox]

нуу... за часів x86 це можна було зробити на virtualbox + windows + інструкція була значно коротшою, але воно все одно гальмувало, тому такий собі прогрес ...

Ну це для тих, кому реально потрібно.
VirtualBox і VMware Workstation не мають PCIe passthrough, хіба що Hyper-V під Windows. На Linux можна тримати хоста на iGPU, а гостьовій системі віддати дискретну ВК. Але це вже екзотичний юзкейс.
Хто на "ти" з Linux, тому немає жодної потреби в еплівському мутанті iOS/macOS. Розробник у реальному житті або має в запасі мак чи айфон, або користується хмарними сервісами для тестування. Це давно вирішена задача.

Іронія в тому, що macOS, яку так люблять за "універсальність", у результаті виявляється менш універсальною, ніж звичайний Linux-хост:
ні нормального passthrough,
ні повноцінної віртуалізації чужих платформ,
лише sandbox і штучні обмеження.

Стосовно про(ре)гресу. macOS 26 Tahoe - остання ОС, яка підтримує x86. Наступна, 27-ма, буде останньою з Rosetta-2. Це напряму бʼє по розвитку CrossOver/Wine.
CrossOver платний і він того вартий, я не ставив за ціль запускати весь x86-софт, але деякі ігри йдуть цілком пристойно. Далі, схоже, будуть розвивати FEX/Box64, щось у стилі https://github.com/AndreRH/hangover
Rosetta-2 ніколи не була стратегією. Це був тимчасовий костиль, щоб продати перехід. Коли продажі ARM-маків наситились, костиль просто викидають, незалежно від того, скільки софту на ньому ще тримається.

Отримуємо планове звуження сценаріїв:
менше архітектур,
менше сумісності,
більше залежності від App Store і платних прошарків.
Новий софт під macOS x86 буде депріоритетизований, ARM-емулятора в macOS немає, тому на Intel-Mac логічно ставити Windows або Linux.
Intel-Mac фактично переходить у статус ретро-платформи: залізо ще живе, але екосистема вже мертва. І це рішення не технічне, а бізнесове, як завжди у Apple.

Для користувачів Apple тут нічого нового. Хто застав перехід з PowerPC, той це вже бачив. Головне екосистема, а екосистема завжди потребує грошей.