На рынке микроэлектроники царствуют две архитектуры: x86 и ARM (Advanced RISC Machine). И до недавнего времени они сосуществовали в идиллии — с лёгкими нотками конкуренции. Но недавно Apple ткнула палкой в это… болото, показав Apple silicon M1. Все техноблогеры визжали от счастья и отправляли цветы в кабинет Кука. It's a revolution, Jony Timmy.
Но Apple всего лишь ударила клюшкой туда, где шайба окажется, а не туда, где шайба находится сейчас. И не промахнулась.
Но на самом деле революция случилась раньше — в серверном сегменте (об этом я расскажу в следующей статье из цикла).
Содержание:
Да, ARM-архитектура давно пустила корни в сегменты рынка, где x86 годами удерживала монополию. Конъюнктура дуализма в микропроцессорных архитектурах начала разрушаться ещё до выхода M1 — уже были консьюмерские ARM ноутбуки (привет, Qualcomm), серверы и даже суперкомпьютеры. Об этом и поговорим в статье, ведь сейчас ARM на пороге глобальных перемен.
x86 и ARM — двое из ларца
Вряд ли я удивлю кого-то из читателей Хабра, сказав, что в мире есть две основные микропроцессорные архитектуры, от которых пошли почти все остальные: RISC и CISC.
|
Разнообразие RISC-подобных и CISC-подобных архитектур огромно: RISC-подобные: ARM (доминирующая), MIPS, POWER, SPARC, PA-RISC и Alpha; CISC-подобные: x86 (доминирующая), VAX, MC680x0, z/Architecture. Также уточню, что есть и другие, куда менее популярные архитектуры, например VLIW (Very Long Instruction Word), на которой работает линейка отечественных Эльбрусов. У неё ещё более длинные инструкции, чем у x86. |
Пожалуй, можно написать несколько книг про их различия, преимущества и недостатки. Некоторые авторы на Хабре уже публиковали интересные статьи (раз, два) на эту тему. Моя статья немного про другое, но чтобы общая картина сложилась, вкратце расскажу об отличиях x86 и ARM.
Итак.
Чаще всего разницу выискивают в способах проектирования, в длине команд, в энергоэффективности, в сложности ПО или в области применения.
Тезисы звучат примерно так:
Когда вендорам нужно сделать высокопроизводительное устройство с активным охлаждением и питанием от розетки, они выбирают x86. Там более длинные команды, на обработку которых уходит больше энергии, но зато сложность вычислений выше, а потому на x86 есть более точный и узкоспециализированный профессиональный софт.
Если же нужно что-то компактное, энергоэффективное и бесшумное, работающее от аккумулятора, то смотрят в сторону ARM и других RISC архитектур (привет смартфонам, маршрутизаторам и прочим многочисленным девайсам). Набор команд упрощен и имеет унифицированную длину, благодаря чему процессоры меньше греются и обходятся без активного охлаждения. Софт — проще, но для области применения ARM-процессоров этого достаточно.
Окей, эти тезисы имеют место быть, но настоящая разница — в наборах инструкций.
|
В наборе команд микроархитектуры x86 есть те, что отвечают за произвольное использование регистров и ячеек памяти. В ARM же есть специальные инструкции для операций над данными в регистрах (регистр-регистр) и отдельные инструкции для обмена данными между регистрами и памятью (нет косвенной адресации). Пресловутые длинные команды из мира CISC на самом деле разбиваются на несколько микроопераций и исполняются RISC ядром — вот тебе и x86. Титанических различий в архитектуре x86 и ARM под капотом не так уж и много. Это всё те же миллионы и миллиарды транзисторов, с помощью которых выполняются логические операции. |
Да, это не самое скандальное разоблачение на свете, но после разговоров со знакомыми сисадминами я понял, что далеко не все об этом знают.
Разница в проектировании — вот в чём SoC
Например, Intel Core i9-12900K или AMD Ryzen 7 4750G — это не CPU, как мы привыкли их называть, а APU (Accelerated Processor Unit), то есть процессор с интегрированной графикой (iGPU) на одном кристалле. Есть модели без встроенной графики, например, Intel Core i9-12900KF или AMD Ryzen 9 3900X — это как раз классические CPU. Но важно учесть, что даже классические CPU — не просто ядра с кэшем. Внутрь встроена логика северного моста, которую раньше на себя брал отдельный чип, распаянный на материнской плате.
А вот на ARM чаще всего другая логика — SoC (System-on-a-Chip) или система на кристалле. Это подход к созданию вычислительного устройства, когда на одной интегральной схеме находится де-факто целый компьютер: ядра CPU общего назначения; ядра GPU; специализированные ядра для обработки изображений (ISP), цифровых сигналов (DSP) и нейронных задач (NPU); память GDDR; кэш; контроллер памяти; модем; многоканальный радиочастотный блок; MultiMedia Hardware Accelerator (аппаратное ускорение); AI Accelerator; IO (ввод/вывод) и многое другое.
Различия связаны тем, что ПК или ноутбуки достаточно большие, чтобы установить в них платы расширения и чипсет, который включает в себя другие компоненты. Всё что нужно для быстрого выполнения команд встроено в процессор (кэш, северный мост), либо общается с ним по очень быстрым шинам PCI-e (видеоадаптеры, ОЗУ, южный мост). А почти вся площадь кристалла процессора выделяется под вычислительные нужды.
Носимая электроника — компактная. Внутри корпуса места мало, а вдобавок туда нужно установить устройства ввода-вывода (дисплей, сенсорная панель, кнопки, динамики, вибромоторчики, камеры, сканеры и другое), сим-карту, а также аккумуляторы для автономной работы и антенны. Поэтому большую часть решили интегрировать прямо в процессор. Всё ради экономии места и быстрого межпроцессорного взаимодействия. Чем дальше в лес, тем больше компонентов интегрируют в SoC.
Итого. Два основных различия современных x86 и ARM процессоров — в наборе инструкций и в физической реализации. Они мало чем отличаются с технической точки зрения, а при желании, если понизить вольтаж и частоты, срезать кэш, избавить от предсказателей переходов и выполнения команд вне очереди, их можно привести к одному знаменателю (вспоминаем x86 Android смартфоны на Intel Atom, и ведь работали).
шARM маленьких процессоров: как Intel прогадала с рынком
Синие долго упирались, не желая разрабатывать процессоры на ARM. Они прошляпили уходящий вагон сапсана, а когда выпустили собственную альтернативу на x86 (Intel Atom) — было поздно. Да, Android нормально работал на x86 процессорах, а некоторые производители, например Lenovo, выпускали годные смартфоны (K900).
Если с технической точки зрения процессоры Atom вполне могли дать конкурентное энергопотребление и производительность на ватт, то софт… С его адаптацией были проблемы. А как мы помним, из-за этой же причины в своё время померла очень неплохая Windows Phone, которая также поздно ворвалась в игру.
На самом деле у Intel было несколько вариантов выйти победителями:
Начать адаптировать x86 процессоры под смартфоны раньше. Если бы софт изначально писали под эту архитектуру, то, возможно, сейчас в наших смартфонах стояли процессоры Intel и AMD;
Выкупить ARM со всеми
потрохаминаработками и патентами. В те времена антимонопольная служба вполне могла бы одобрить сделку (как дела, Nvidia?). HP же поглотила одного из главных конкурентов (Compaq) в 2002 году;Начать полноценную разработку ARM процессоров для смартфонов. Тем более, что у них были процессоры XScale PXA с реализацией набора команд ARMv5TE. Но нет, они продали её компании Marvell за 600 миллионов долларов и сложили все яйца в
одну корзинуx86.
Но случилось, что случилось. Сначала ARM захватила рынок телефонов, позже — смартфонов и носимой электроники, а дальше начались нападки на вотчину x86: ПК и серверы.
Главная причина экспансии — ARM-процессоры быстрее прогрессируют. Не в последнюю очередь из-за модели лицензирования. Любая компания может купить у ARM лицензию на готовые ядра или архитектуру и создавать свои SoC, как это делают, например, Apple, Qualcomm и Samsung. Это даёт относительно низкий порог входа.
Архитектура x86 является открытой и бесплатной. Но готовые ядра Intel или AMD вам никто не продаст. При этом для некоторых функций всё равно понадобится покупать лицензию от Intel и AMD. То есть понимаете, какой порог входа? Вы с нуля начинаете конкурировать с двумя гигантами, которые разрабатывали процессоры десятилетиями.
Но вопрос, как мне кажется, не столько в самой архитектуре, а в том, сколько денег вкладывается в R&D (исследования и разработки).
Сравните сами.
Дисклеймер! Таблица ниже не претендует на точное сравнение, а сухие цифры не показывают реальной картины в рабочих или повседневных задачах. Главная цель — показать скорость прогрессии, а не столкнуть конкретные процессоры лоб в лоб. |
↓CUT↓
|
2010 ГОД. A4 даже рядом не стоит с топовым на тот момент Intel. Зато TDP всего 5W — хороший вариант для смартфона. | |
|
Apple A4 (32-bit): 45 нм, 149,000,000 транзисторов, 2 ядра, 1 ГГц, 512 KB кэш, TDP 5W, 0.5 GFLOPS, производительность на ватт — 42 pts. iGPU — 1.6-3.2 GFLOPS. |
Intel Core i7-970 (64 bit): 32 нм, 1,170,000,000 транзисторов, 6 ядер, 3.2-3.5 ГГц, 12 MB кэш, TDP 130W, 113.3 GFLOPS, производительность на ватт — 107 pts. Без iGPU. |
|
2012 ГОД. A6X сильно спрогрессировал, догнал по техпроцессу, но всё ещё сильно отстаёт по производительности и характеристикам. | |
|
Apple A6X (32-bit): 32 нм, 1,000,000,000 транзисторов, 2 ядра, 1,4 ГГц, 512 KB кэш, TDP 5W, 7 GFLOPS, производительность на ватт — 113 pts. iGPU — 51.2 GFLOPS. |
Intel Core i7-3930K: 32 нм, 2,270,000,000 транзисторов, 6 ядер, 3.2-3.8 ГГц, 12 MB кэш, TDP 130W, 230.9 GFLOPS, производительность на ватт — 141 pts. Без iGPU. |
|
2014 ГОД. A8 перегнал по техпроцессу, почти догнал по количеству транзисторов, сильно нарастил кэш. Очень мощный скачок, а TDP 5W, тогда как Intel прибавил 10 W. | |
|
Apple A8 (64-bit): 20 нм, 2,000,000,000 транзисторов, 2 ядра, 1.4 ГГц, 4 MB кэш, TDP 5W, 35 GFLOPS, производительность на ватт — 477 pts. iGPU — 115.2 GFLOPS. |
Intel Core i7-5930K: 22 нм, 2,600,000,000 транзисторов, 6 ядер, 3.5-3.7 ГГц, 15 MB кэш, TDP 140W, 406.8 GFLOPS, производительность на ватт — 158 pts. Без iGPU. |
|
2016 ГОД. Где-то здесь началась смена парадигмы. A10 нарастил ядра, частоты, перегнал по транзисторам и это всё с TDP 5W. | |
|
Apple A10 Fusion: 16 нм, 3,300,000,000 транзисторов, 4 ядра, 1.3-2.3 ГГц, 4 MB кэш, TDP 5W, 88.2 GFLOPS, производительность на ватт — 1,138 pts. iGPU — (FP32) 1200.6 GFLOPS. |
Intel Core i7-6900K: 14 нм, 3,200,000,000 транзисторов, 8 ядер, 3.2-3.7 ГГц, 20 MB кэш, TDP 140W, 563.5 GFLOPS, производительность на ватт — 221 pts. Без iGPU. |
|
2018 ГОД. TDP у A12X вырос в три раза, количество транзисторов тоже. Техпроцесс вырвался вперёд даже относительно компании AMD, у которой нет якорей из своих фабрик. Кэш — x2, частоты подросли, а графическое ядро в два раза мощнее Xbox One S (по заверениям Apple). Жаль, что нормальных игр не было. | |
|
Apple A12X Bionic: 7 нм, 10,000,000,000 транзисторов, 8 ядер, 1.6-2.5 ГГц, 8 MB кэш, TDP 15W, 240 GFLOPS, производительность на ватт — 1,180 pts. iGPU — (FP32) 1200.6 GFLOPS. |
Intel i9-9900K: 14 нм++, количество транзисторов неизвестно, 8 ядер, 3.6-5.0 ГГц, 16 MB кэш, TDP 95W, 588 GFLOPS, производительность на ватт — 384 pts. iGPU — (FP32) 423.2 GFLOPS. AMD Ryzen 7 PRO 2700X: 12 нм, транзисторов 4,940,000,000, 8 ядер, 3.4-4.1 ГГц, 16 MB кэш, TDP 95W, 357 GFLOPS, производительность на ватт — 297 pts, без iGPU. |
|
2020 ГОД. С выходом M1 стало очевидно, что ARM процессоры способны на большее. Он обошел топовые Intel Core i9-10900K и AMD Ryzen 9 5950X в одноядерных тестах Geekbench 5. С графикой тоже полный порядок. Но в мультиядерных тестах пока отставание, однако TDP многократно меньше. И это первый Apple silicon SoC, который попал в десктопный сегмент. | |
|
Apple M1: 5 нм, 33,700,000,000 транзисторов, 8 ядер, 2.1-3.2 ГГц, 12 MB кэш, TDP 14W, производительность на ватт — 2,047 pts. iGPU — (FP32) 2610 GFLOPS. |
Intel Core i9-10900K: 14 нм+++, количество транзисторов неизвестно, 10 ядер, 3.7-5.3 ГГц, 20 MB кэш, TDP 125W, 706.28 GFLOPS, производительность на ватт — 336 pts. iGPU — (FP32) 460.8 GFLOPS. AMD Ryzen 9 5950X: 7 нм, транзисторов 3,800,000,000, 16 ядер, 3.4-4.9 ГГц, 64 MB кэш, TDP 105W, 963 GFLOPS, производительность на ватт — 595 pts, без iGPU. |
Q1 2022 года |
Q4 2021 года |
А вот здесь наблюдается интересная картина. Да, M1 Ultra — это высокопроизводительное чудовище (де-факто это два процессора M1 Max). Он может побороться одновременно с топовыми процессорами и видеокартами уровня RTX 3070 (никаким 3090 тут и не пахнет, что бы ни говорила Apple), но TDP относительно M1 вырос в 7 раз. Появился кулер, питание от розетки и другие прелести из лагеря x86. | |
|
Apple M1 Ultra: 5 нм, 114,000,000,000 транзисторов, 20 ядер, 2.1-3.2 ГГц, 48 MB кэш, TDP 100W, производительность на ватт — данных нет. В среднем по трём мультикор тестам он в 3 раза превосходит базовый M1. Мощнейший 32-ядерный встроенный iGPU — (FP32) 21.2 TFLOPS. Apple заявляет, что M1 Ultra потребляет при пиковых нагрузках на 100 Вт меньше энергии, чем i9-12900K: около 60 Вт против 160 Вт у x86. |
Intel i9-12900K: 10 нм (Intel 7), количество транзисторов неизвестно, 16 ядер, 3.2-5.2 ГГц, 30 MB кэш, TDP 125W, 1.18 TFLOPS, производительность на ватт — 508 pts. iGPU — (FP32) 742.4 GFLOPS. |
|
И пару слов про недавний M2. MacBook Air с пассивным охлаждением тротлит, а MacBook Pro, у которого активное охлаждение, нет. Линейка Apple silicon M превращается… барабанная дробь… в симбионта из преимуществ и недостатков x86 и ARM. Когда выбираешься на уровень производительности ПК, растёт и | |
По таблице выше видно, что процессоры на ARM летели семимильными шагами, а вот x86 вальяжно развивались, никуда не торопясь. Я вижу несколько ключевых причин, почему так произошло.
Во-первых, это деньги и конкуренция.
Рынок процессоров для смартфонов в 2021 году вырос на 23% — до $30,8 млрд. В отдельную категорию выделяют рынок планшетов ($3 млрд), в котором 89% — это ARM, а остальное — x86. А за счёт нормальной модели лицензирования в лагере ARM огромная конкуренция: есть Apple Silicon, Qualcomm Snapdragon, MediaTek, Samsung Exýnos, Nvidia Tegra и Grace, а также Fujitsu и другие.
Все вендоры видят графики роста продаж и прибыли, а конкуренция побуждает их вкладываться в разработку, чтобы не вылететь с этого пира.
С 2017-ого года по 2021-ый поставки выросли с 40 млн единиц до более чем 200 миллионов — динамика роста впечатляющая.
Рынок x86 процессоров составил $74 млрд, но вырос не так значительно — всего на 11.6% за год. Здесь нужно учесть, что из-за COVID-19 смартфоны стали продаваться хуже, а ПК и ноутбуки для работы из дома — лучше.
Intel и AMD вдвоём сидят на суку и без жёсткой конкуренции медленно пилят его (да есть ещё производители, но их доли ничтожно малы). Были годы, когда Intel почти монополизировала рынок x86 (как раз, когда ARM перевернула игру). AMD несколько лет работала с убытками, закрывала линейки процессоров и сокращала штат. А монополия всегда тормозит прогресс.
Другая причина быстрой прогрессии — это цикл обновления устройств.
Игровой ПК вполне может работать 5 и более лет без обновления процессора: Intel Core i7-6700K (2015 года) позволяет нормально играть в современные игры, если видеокарта на уровне (ссылка на видео). Да, с новым процессором FPS будет выше, но разница не в два раза — речь о нескольких десятках процентов.
А теперь давайте взглянем на смартфоны флагманы 2015 года: iPhone 6S, Sony Xperia Z5, Samsung Galaxy S6, LG G4, Google Nexus 6P — ни один из них больше не обновляется, а встретить человека с семилетними смартфонами — непростая задача. Любая модель из среднебюджетного сегмента выиграет по всем параметрам. Вот и получаем, что нормальный цикл обновления в смартфонах (сейчас он замедлился) — около 2 лет. Поэтому и процессоры нужно обновлять быстрее и заметнее.
Всё это позволило за 12 лет ARM-процессорам пройти огромный путь: от 200-кратного отставания до вполне себе конкурентного уровня. Могу ошибаться, но есть ощущения, что дальше начнётся игра на выживание. Прошу заметить, что я не говорю о полном исчезновении x86 или об абсолютном преимуществе ARM. Есть ряд задач, где ещё долго не будет смены парадигмы. Но уже сейчас Intel и AMD придётся шевелиться.
Циклу быть
В следующей статье я расскажу про суперкомпьютеры и серверы на ARM, затрону тему операционных систем и поближе посмотрю на серверные процессоры, которые сделали революцию в производительности за пару лет до Apple M1.
Чего только стоит блейд-сервер HP, у которого 288 ARM процессоров и 1152 ядра :)
Комментарии (132)
lgorSL
02.08.2022 18:14+3Кстати, интересно сравнить 2020 год и arm против rysen:
У райзена в десять раз меньше транзисторов, но при этом в два раза больше ядер, кеш 64 Мб и в семь с лишним раз больше энергопотребление. Отличие в 70 раз на транзистор!
Мне кажется, подвох в том, что эппл выезжают на количестве транзисторов и как-то его разменивают на низкое энергопотребление.
Singrana
02.08.2022 21:00+6В той туче транзисторов у эппла еще видео, пачка всевозможных декодеров, нейроядра и т.д. Имхо, не совсем корректно по транзисторам сравнивать
FaustLab
03.08.2022 15:38вы так говорите как будто у x86 нет видео, пачки декодеров, avx/sse/mmx, кешей и т.д.Имхо не совсем корректно отказываться от сравнения по транзисторам.
kamitora
04.08.2022 08:06вы так говорите как будто у x86 нет видео, пачки декодеров
А это на самом деле очень спорный вопрос. У эппла как минимум есть что-то аппаратное для тренировки нейросетей - Neural Engine. Есть, вероятно, и другие специфические фичи, которые нужны были девелоперам от эппл. Но если брать тот же UVD от AMD, то его поддержка софтом сильно различается. И вообще пока все выглядит так, что в x86 напихана куча всего на все случаи жизни, а в условный M1+ забиты аппаратные блоки под специфический форкфлоу целевой аудитории маков. И последний вариант это сорт оф читерство.
Barseadar Автор
03.08.2022 09:58+3Важно не количество транзисторов, а то, как ты ими пользуешься :D (где-то в недрах МЦСТ)
Tarakanator
03.08.2022 11:42+1Энергопотребление примерно пропорционально кубу частоты. Так что зарезая частоту можно нехило повышать энергоэффективность.
К примеру на ноутбучных видеокартах количество вычислительных блоков больше, чем на такой-же десктопной. Именно для того, чтобы при меньших частотах получить более-менее равную производительность.
DeepFakescovery
02.08.2022 18:14+12так а где эти самые дешевые и производительные убийцы x86 на ARM ? Вы сравниваете апле и интел. Аппле еще дороже чем интел.
cyber_roach
02.08.2022 21:22И греются ноуты у аппл на арм даже сильнее чем на интел, сколько там было 108 градусов цельсия на новеньком М2 в работе)))))
Firz
02.08.2022 21:35+12А ткните ссылкой какая модель на интеле у них была на пассивном охлаждении, с которой сравнивались эти 108 градусов?
Если подразумевается последняя модель Air-а 2020 года с топовым для air-а i7-1060NG7 на борту, то чисто по процессорной мощности разница 6971 против 15181 попугаев, а если взять со стоковым i3-1000NG4, то у того вообще 3827 попугаев, а еще можно сравнить видеокарты, там еще больше разницы будет.
Так что как-то странно говорить что слабые, относительно новых М2, интелы греются меньше чем в разы более производительные М2.
garbagecollected
02.08.2022 22:11Но и такие новости имеют место быть. Интересно, из чего состоят эти термо-прокладки. Возможно, достаточно пропатчить ноут простой термопастой.
Firz
02.08.2022 22:21+6Я если честно не понимаю зачем они вообще этим занимаются(ну кроме как исключений в виде как раз всяких блогеров, которые могут всякой фигней заниматься, лишь бы просмотры были). Грубо говоря, у них есть ноутбук с довольно мощным процессором, который без активного охлаждения может еще и кочегарить на полную минут 5 до начала троттлинга(да и в максимальном троттлинге кстати ни разу не слабый), но если им нужно на полную его нагружать дольше чем на 5 минут(видео рендерить часами, к примеру), может им и не ультрабук тогда нужен с колхозингом термопрокладок, а что-то хотя бы с минимальным активным охлаждением.
Popadanec
03.08.2022 09:02Далеко не все покупающие понимают, что чудес не бывает. Если он тоньше и легче, дешевле(но с тем же ЦП), то за счёт чего то.
Funny_Meerkat
03.08.2022 10:31+2А в чём смысл проектировать и выпускать после тестов ноутбук, который троттлит?
Firz
03.08.2022 11:11+2Ну вот есть два устройства с пассивным охлаждением, одно может работать 5 минут на 100% мощности, а потом замедлиться до условных N%, другой всегда работает на стабильных N% мощности, я думаю понятно почему первый вариант лучше?
Tarakanator
03.08.2022 11:46+1Вот только за счёт меньшей температуры 2-е устройство будет ещё и жрать электричества меньше.
Да и цена радиатора не так уж велика по сравнению с кремнием.
Так что большой вопрос какой вариант лучше.Firz
03.08.2022 12:06-1Так у них будут одинаковые температуры, просто первое до этой температуры дойдет через 5 минут работы на 100%, а потом будет поддерживать её замедлившись до N%, а второе дойдет до этой температуры за условные 10 минут на N% мощности.
Про цену радиатора, если честно, не понял.Tarakanator
03.08.2022 12:32+1блин, я неправильно прочитал ваш предыдущий пост.
Тогда мой ответ будет проще: лучше тот, на котором не экономили на радиаторе. И он всегда может работать на 100%. Но конечно возможны варианты, исходя из ограничений к целевому устройству.Firz
03.08.2022 12:39Ну вот у них и есть устройства с нормальным активным охлаждением(MacBook Pro), кому нужно что-то серьезное делать со стабильной нагрузкой, а есть с пассивным(MacBook Air), кому нужен максимально тонкий и легкий вариант и кто не планирует на нем видео рендерить 24/7.
Tarakanator
03.08.2022 12:54+2Первый попавшийся сайт говорит что самые дешевые air стоит 120к, про стоит 160к. Разница 33%.
разница в весе 1290 против 1400грамм. разница 8%
Складывается впечатление что охлаждение урезали не чтобы сделать ноутбук аж на 8% легче, а чтобы те, кому нужно нормальное охлаждение заплатили на 33% больше.Победа маркетинга над здравым смыслом
Firz
03.08.2022 14:09Я не знаю что за первые попавшиеся модели вы сравниваете на первом попавшемся сайте, но разница между MacBook Air 2022 M2 и MacBook Pro 13 2022 M2 100$. Правда это разные устройства с разными поколениями матрицы и самого корпуса.
Tarakanator
03.08.2022 14:57+1Я смотрел для M1, чтобы характеристики были более схожими. А на сайте эпла цену для pro на M1 не показывает.
Посмотрел ещё на других сайтах pro вроде как 1300 официально стоил, аир 1000, итого теже 30% разницы.
Firz
03.08.2022 17:59https://www.apple.com/mac/compare/?modelList=MacBook-Air-M1,MacBookPro-13-M1,Mac-studio-2022
Из кардинальных отличий — у Pro сенсорный экран вместо ряда F-F1-F12 кнопок.
Tarakanator
03.08.2022 19:37вы про м2? там экраны разные и размеры чуть разные, поэтому я м1 сравнивал.
Firz
03.08.2022 20:29Нет, по ссылке те, о которых вы писали выше, M1 Air 2020 и М1 Pro 13 2020 (там же по ссылке вроде написано об этом несколько раз), основное их отличие друг от друга(если не учитывать охлаждение) это наличие у Pro сенсорного экрана вместо клавиш F1-F12, разница в цене становится понятнее?
Tarakanator
03.08.2022 21:40Ну определённо она становится обоснованней, но всё равно я считаю это победой маркетинга.
Barseadar Автор
03.08.2022 10:02В следующей статье буду рассматривать конкретные процессоры. Не забываем, что годы монополии x86 дают о себе знать, но видимо мы еще застанем время, когда можно будет купить мать от какой-нибудь MSI или ASUS с сокетом под ARM процессор Qualcomm или даже MediaTek.
anka007
04.08.2022 12:41Монополия была из-за того, что x86 довольно успешно решал задачу "возьми данные не знаю какие данные посчитай их так не знаю как". Остальные архитектуры были рассчитаны на более узкий круг задач, и довольно долго в них были предпочтительнее. С поправкой на стоимость решения, а она зависила от тиража.
Это ж получается, что в распространении г*кодеров виноват интел?! Процессоры слишком уж эффективно переваривали плохо написаный код. Или все было наоборот? Так как плохого кода стало слишком много, то набрал популярность процессор для обработки этого кода?
anka007
02.08.2022 18:19+3Китайцы (и прочие) лет через пять вполне могут подвинуть обоих RISC-V. Идеологически он выглядит перспективнее. А ARM потихоньку готовит софтовую почву "массовая программа может выполняться на разных процессорах" (понятно, что специализированный софт давно компилируют под что попало, лишь бы влезло и время отклика устраивало)
screwer
02.08.2022 18:41+28Актуальный сейчас ARM64 (aarch64) не более RISC чем x86. Т.е. точно такой же CISC.
VLIW ... У неё ещё более длинные инструкции, чем у x86
Hexagon объединяет инструкции в пакеты. Размер инструкции фиксирован, 4 байта. Размер пакета от 1ой до 4х инструкций, в зависимости от их типа. Т.е. от 4 (совсем не повезло с содержимым пакета) до 16 байт (супер повезло) Типичное значение 8 или 12 байт. При этом максимальная длина инструкции (без читерства с бесполезными префиксами) на x86 составляет 15 байт.
они выбирают x86. Там более длинные команды, на обработку которых уходит больше энергии, но зато сложность вычислений выше, а потому на x86 есть более точный и узкоспециализированный профессиональный софт.
Какая феерическая чушь! Дальше читать не стал.
Myclass
02.08.2022 20:49Так же подумал и в голове сравнение- экскаватор против кучи, но маленьких и энерго-малозатратных лопат.
beeruser
02.08.2022 22:04+7Актуальный сейчас ARM64 (aarch64) не более RISC чем x86. Т.е. точно такой же CISC
По каким признакам вы делаете такие выводы?
Как раз AArch64 даже ближе к «эталонному» RISC чем AArch32.
ARM — load/store архитектура, где основную массу составляют команды регистр-регистр.
Имеет фиксированную длину команд.
Load-op для обычных операций отсутствует, но есть некоторые специализированные load-op команды, как и CAS.Дальше читать не стал.
Вот тут соглашусь.
Те, кто пишут подобную бредятину («Там более длинные команды, на обработку которых уходит больше энергии, но зато сложность вычислений выше») обычно слабо представляют себе что это значит вообще.
mvv-rusА она там таки разная (на ARM -более слабая, обеспечивающая меньше гарантий)
А вы под одну гребёнку не гребите =)
ARM разные бывают. Например на ядрах Nvidia Carmel — Sequential Consistency. Более строгая чем у х86.screwer
03.08.2022 03:10+7По каким признакам вы делаете такие выводы?
Как раз AArch64 даже ближе к «эталонному» RISC чем AArch32.
Строго по определению. Reduced - это когда набор инструкций небольшой. Если у armv7 все инструкции можно было в одну небольшую табличку записать (и ещё одну для Thumb),. то у Aarch64 их просто дохрелион.
Вот прямо сейчас открыл Instruction Set. Для 32 битного перечисление базовых команд занимает 1,5 (полторы) страницы. Я их даже сосчитал - 34 штуки.
Для 64 битного 10 (десять) страниц. Их я тоже сосчитал 346 штук. Разница впечатляет ?
И ещё 11 страниц инструкций FPU. Их я уже считать не стал.
Имеет фиксированную длину команд.
Hexagon тоже имеет, но RISC он от этого не становится.
khajiit
03.08.2022 18:37Reduced — это когда набор инструкций небольшой
Если это утверждение верно, то i8086 был CISC в момент выпуска, а после выпуска 80(1|2|
3|…)86 внезапно стал RISC.
Очевидно, что это не так.
Следовательно, вы исходите из неверной трактовки. Скорее всего, из-за незнания истории термина.
Но вам это много раз объясняли, впрочем.
Безрезультатно.screwer
03.08.2022 21:36Если это утверждение верно, то i8086 был CISC в момент выпуска,
Да, CISC. С поправкой на технологии того времени (тысячи, максимум десятки тысяч транзисторов. Против миллионов в 90-х, и сотен миллионов в 00-х).
Давайте достанем линейку, да померяем ?
Если отбросить все вариации с флагами, размерностями, то у i8086 можно насчитать 68 базовых инструкций.
Теперь рассмотрим его современника, MOS 6502. У этого процессора прямо в инструкции закодированы операнды. Например TAY это аналог MOV A, Y, а TSX аналог MOV SP, X. Будем подобные дубликаты также считать за одну команду. Итого 26 команд.
Или вот ещё сравнение. У 6502 количество всевозможных опкодов, без imm параметров, всего 153 штуки. ВСЁ! Больше нету!!! А у i8086 их 65536 штук.
По-моему вполне наглядно, даже не смотря на то, что термины CISC/RISC тогда только "закладывались в проект".
Да блин! У 6502 даже сложения-вычитания без учёта переноса нет! Всего 3 регистра. Никакой ортогональности. Транзисторный бюджет в 10(!!!) раз меньше чем у i8086. Оголтелый примитивизм на марше.
а после выпуска 80(1|2|3|…)86 внезапно стал RISC.
386 стал RISC ? Это когда такое случилось ?
Следовательно, вы исходите из неверной трактовки. Скорее всего, из-за незнания истории термина.
Или нет
Но вам это много раз объясняли, впрочем.
Безрезультатно.
Вы меня с кем-то путаете.
khajiit
04.08.2022 00:38+2Да, CISC.
С этим никто не спорит.
386 стал RISC? Это когда такое случилось ?
Контекст. Не стоит выдергивать кусок из фразы.
то **i8086** был CISC в момент выпуска, а после выпуска 80(1|2| 3|…)86 внезапно стал RISC.
Из вашего определения, опирающегося исключительно на размер ISA — это напрямую следует. С новым поколением все прежние CISC должны становится RISC — и этому было любопытно, как такая мысль укладывается у вас голове.
Как и ожидалось, с кучей само-собой разумеющихся подпорок.Или нет
Хотите фокус?
Вы уверены, что значение имеет Complex/Reduced (length of) Instruction Set.
И не допускаете мысли, что речь может идти о Complex/Reduced (smth) Instruction Set.
Wiki, между тем, вполне однозначна:The goal of any instruction format should be: 1. simple decode, 2. simple decode, and 3. simple decode. Any attempts at improved code density at the expense of CPU performance should be ridiculed at every opportunity.[22]В источниках так же легко находится связка
reduced instructionиone-clock executing
Отсюда явно следует что опущенное слово —decoding complexity. Reduced (decoding complexity) Instruction Set.
Сложность, а не длина набора. Длина никак не оговаривается ни в одном случае, и может быть любой.
Как и количество поддерживаемых наборов, кстати.
Но сокращать сложность путем сокращения длины набора — первое, что приходит в голову и сразу дает эффект. Поэтому это заблуждение сильно распространено даже в англоязычной среде.Вы меня с кем-то путаете.
Возможно, обознался. Мои извинения, коль так.
beeruser
03.08.2022 22:55+5Строго по определению. Reduced — это когда набор инструкций небольшой.
Нет. Reduced это уменьшенный (урезанный), а вовсе не «небольшой».
А различие тут кардинальное. Нет никакого ограничения по количеству команд.
Небольшое число команд на заре RISC было вызвано лишь недостатком транзисторов.
Уменьшен набор был разделением операций на вычислительные и операции работы с памятью и как следствие выкидыванием ненужных команд load-op и rmw.
Это помогло создать более простое и эффективное кодирование инструкций, увеличить число регистров, что до сих пор является признаками RISC.
Я их даже сосчитал — 34 штуки.
А FPU/NEON/TZ/Thumb/JZL вы посчитать забыли?
Ух ты, какая избирательная забывчивость…
Вы не понимаете, к примеру, что MUL/MADD/MSUB/MNEG это одна и та же команда?
Просто чуть по другому конфигурируется блок умножителя.
Не нужно из-за этого заявлять о превращении RISC в CISC.
К RISC-V можно прикрутить хоть миллиард инструкций на все случаи жизни (благодаря VLE, кстати). Покуда они реализованы на RISC-принципах, никаким CISC он не станет.
Вот 6502, который вы описали выше — классический CISC, хоть и примитивный.
Как я и писал количество инструкций тут не играет никакой роли.
ADC
Add Memory to Accumulator with Carry
(indirect,X) ADC (oper,X) 61 2 6
(indirect),Y ADC (oper),Y 71 2 5*
Вот таких инструкций на RISC нет.
Даже на топовых чипах с десятками миллиардов транзисторов.
Потому что она противоречит принципам RISC.
Парадоксально, но факт — процессор с 3500 транзисторами выполняет более сложные команды чем процессор с 59 миллиардами транзисторов :)Hexagon тоже имеет, но RISC он от этого не становится.
Как и чёрная кошка не становится чёрной BMW.
Одного признака недостаточно.
Тот же ARMv7 имеет VLE кодирование Thumb2.
PS: Ещё раз стоит упомянуть что RISC/CISC это характеристика ISA.
Внутри такие (по крайней мере OoO) процессоры сейчас устроены одинаково.
LennyB
04.08.2022 11:34Взгляните для разнообразия на набор инструкций микроконтроллерного ядра Cortex-M4.
AquariusStar
04.08.2022 20:53+1Reduced - это когда набор инструкций небольшой.
Читал в одной книге. Упоминается, что часто путают трактовку слова reduced в данном контексте. И утверждается, что на самом деле это не сокращённый, а упрощённый. В данном контексте больше смысла. Так как в RISC убраны ряд видов операций, которые характерны только для CISC. А также отсутствует очень сложный декодер команд (широко встречается у Intel и AMD). Но число команд может быть большим.
mvv-rus
02.08.2022 19:11+9Скандальное — это кликбейтно, да. Но технический уровень от этого, бывает, страдает.
Например, в статье забыто сравнение моделей памяти в плане синхронизации порядка записи из кэша нескольких процессорных ядер. А она там таки разная (на ARM -более слабая, обеспечивающая меньше гарантий), и это много нам открытий чудных готовит при использовании на ARM неблокирующих алгоритмов, выполняющихся параллельно на нескольких ядрах.
AnthonyMikh
03.08.2022 21:30+2и это много нам открытий чудных готовит при использовании на ARM неблокирующих алгоритмов
Некорректно написанных неблокирующих алгоритмов, вы хотели сказать.
mvv-rus
03.08.2022 21:37Слово «некооректно» требует уточнения: для каких условий?
Тут речь идет об алгоритмах, некорректных для модели памяти ARM, но вполне корректных и, главное, работающих много лет на x86 c ее более сильной моделью памяти.
А при переносе могут вылезти сюрпризы. Причем, в силу предметной области искать и отлаживать такие сюрпризы будет, мягко говоря, трудно.
Поэтому чем больше разработчиков об этом будут знать, тем лучше. А вот в статье об этом аспекте не сказано, и это жаль.AnthonyMikh
03.08.2022 23:25+2Тут речь идет об алгоритмах, некорректных для модели памяти ARM, но вполне корректных и, главное, работающих много лет на x86 c ее более сильной моделью памяти.
Строго говоря, корректность многопоточных программ на, как минимум, C и C++ рассматривается относительно модели памяти этих языков, а она у них таки слабая. То, что эти старые алгоритмы работали, как положено, говорит лишь о том, что их пользователям в каком-то смысле повезло.
anka007
04.08.2022 12:08Это не так работает. Как правило, конечным пользователям не нужно ни железо, ни софт, ни уж тем более алгоритмы по отдельности. Пользователю нужно решение его задачи. Связка х86+вот эта программа на этом компиляторе решает его задачу, ARM+эта же программа дает непредсказуемые сбои, причем очень тяжело отлавливаемые.
Если уж говорить про С и С++, то в их стандартах (и компиляторах) заложено слишком много implementation depended для безболезного перехода с одной архитектуры на другую. Даже переход gcc <-> llvm в рамках одной архитектуры не всегда проходит гладко.
Sap_ru
04.08.2022 13:09+1При попытке работать с моделью памяти языков вы упрётесь в зависимость от компилятора и всё равно потеряете кросс-платформенность, т.е. перейдёте к учёту модели памяти конкретной платформы. На том же C++ написать понастоящему кросс-платформенный многопоточный код только с учётом модели памяти языка практически невозможно. Всё равно найдутся платформы (вроде многопроцессорных ARM, PowerPC, и всяких интересных вариантов SPARC), где вы не сможете написать сколько-либо эффективный код не прибегая ко всяким intrinsic фишкам, pragma, аттрибутам и прочему. Даже если код можно будет написать без использования этого всего, то его эффективность будет сразу ниже на порядок или несколько порядков, и такой код не будет иметь практического смысла.
Даже Java на всём обилии платформ не может гарантировать свою модель памяти и на всяких экзотических реализациях рекомендует использовать те или иные подходы и примитивы, иначе или модель памяти не гарантируется, или потеря производительности такая, что использование некоторых примитивов не имеет смысла.AnthonyMikh
04.08.2022 14:54При попытке работать с моделью памяти языков вы упрётесь в зависимость от компилятора и всё равно потеряете кросс-платформенность, т.е. перейдёте к учёту модели памяти конкретной платформы.
И, конечно же, у вас есть конкретные примеры для того, чтобы подкрепить вашу точку зрения?
Gumanoid
02.08.2022 20:05Advanced RISC Machine
ARM это больше не акроним.
dmitryvolochaev
02.08.2022 20:36+9ARM это просто РУКА?
Gumanoid
02.08.2022 21:53+1
eurol
03.08.2022 13:36Китайцы с aliexpress не знали этого раньше, поэтому можно было купить «рука совет по развитию». [ARM development board]
Popadanec
03.08.2022 14:16Сейчас поиск сделали ещё более отвратительным. Раньше хоть найти можно было, то что нужно. Сейчас порой приходится вручную перебирать, вместо поиска. Не удивлюсь, если у них серьёзно просела выручка из за этого.
DaemonGloom
03.08.2022 15:02Проверяйте, на какой домен вас перекинули, когда вы зашли на сайт. На .ru всё плохо, на .com поиск всё ещё терпимый.
Myclass
02.08.2022 20:50+10Так в чём заключается
Скандальное разоблачение
elve
03.08.2022 08:08+1я полагаю вот в этом =)))
Титанических различий в архитектуре x86 и ARM под капотом не так уж и
много. Это всё те же миллионы и миллиарды транзисторов, с помощью
которых выполняются логические операции.Myclass
03.08.2022 14:24+1Никогда не подумал-бы. Даже и не знаю, как после этого в глаза производителей процессоров смотреть.
TheDenis
03.08.2022 15:58+2До самого скандального так и не докопались – на атомарном уровне все процессоры сделаны из атомов кремния, которые неотличимы друг от друга.
Solexid
02.08.2022 21:32+1Если что как минимум все райзены давно SoC, причем настолько что их можно поднять вообще без южного моста(чипсета) www.igorslab.de/en/a-ryzen-without-one-chip-set-operates-without-whats-behind-the-knoll-activator
Celestial_Parallax
02.08.2022 22:31+12Почему-то в статье автор обошёл вниманием тот факт, что x86 это ещё и громадная legacy архитектура из большого количества древних команд, которые тянут ради совместимости с прошлыми версиями. Мне кажется, что именно это сейчас является одним из основных препятствий для развития данной архитектуры.
SergeyMax
03.08.2022 09:25Какие конкретно команды вам не нравятся?
Akon32
03.08.2022 09:42Да хотя бы fwait. А ещё были какие-то двоично-десятичные операции из 4х битного калькулятора, которые, к счастью, в amd64 выкинули.
SergeyMax
03.08.2022 09:54+1fwait ведь давно удалена, и является синонимом nop сейчас. Каким образом она является одним из препятствий для развития архитектуры?)
Akon32
03.08.2022 10:29-2Так ведь процессоры её должны поддерживать? Это как минимум лишние транзисторы.
Даже если fwait заменяется компилятором на опкод nop, есть ещё замечательные (в своё время) инструкции типа fadd, fmul, fstp и т.д., которые сейчас - хлам. 80-битные вещественные числа, к обработке которых открывают доступ эти старые инструкции (по сравнению с современными), нужны не очень часто. В arm их вовсе нет.
SergeyMax
03.08.2022 12:08+1Так ведь процессоры её должны поддерживать? Это как минимум лишние транзисторы.
Это наверняка что-то вроде нескольких байт в таблице декодера опкодов.
80-битные вещественные числа, к обработке которых открывают доступ эти старые инструкции (по сравнению с современными), нужны не очень часто
Ну то, что в ARM их нет, означает только то, что компилятор при случае навалит гору кода для корректной работы с такими числами)
nmrulin
03.08.2022 00:09ARM это типичная "подрывная технология" из известного учебника по бизнесу. Когда гиганты не обращают внимание на новую технологию , потому что она не приносит много прибыли. Когда обращают, оказывается, что корпорация слишком большая, "распилов" много, управлять трудно, поэтому она не может работать на новом фронте так же эффективно, как компании-новички.
Собственно у Intel тут был выход купить уже готовую компанию и проинвестировать в неё. А если бы они сами стали развивать ARM , то привнесли бы в своё подразделение неэффективность(для новой технологии) всей корпорации.
В своё время Kodak разработали первый цифровой фотоаппарат, но это не помогло им преуспеть в этом направлении.
Myclass
03.08.2022 00:51+1В своё время Kodak разработали первый цифровой фотоаппарат, но это не помогло им преуспеть в этом нанаправлении.э
Это часто больше тупость или недальновидность отдельно взятых менеджеров и как в кодак случае ещё и нежелание убивать свой уже рабочий основной бизнес.
K0styan
03.08.2022 01:19+1У Intel была линейка StrongARM в своё время. В пору расцвета КПК и первых коммуникаторов. Но - предпочли продать Marvell-у.
chaynick
04.08.2022 11:22У интела была и линейка "убийцы x86-64" Itanium. И где он? В МЦСТ?
K0styan
04.08.2022 16:26Итаниум никогда особенно популярным не был. А вот StrongARM и его наследники серии XScale долго лидировали в КПК. Их подкосило распространение коммуникаторов, в которых лучше смотрелись менее мощные, зато более экономичные SoC от Texas Instruments и Samsung.
alex103
03.08.2022 05:54+3а встретить человека с семилетними смартфонами — непростая задача.
ну почему же.. - вот он я.. (Lenovo S660)
))
elve
03.08.2022 08:12+1Дата анонсирования 2014-02-24. Он у вас восьмилетний. Вы не подходите в выборку =). Как и я с ZenPhone 2.
Admz
03.08.2022 08:27Ну зачем вы бьёте по больному. Сейчас такую технику не выпускают (к сожалению)...
Эх, были времена :-)
Barseadar Автор
03.08.2022 10:40Это же как раз на Intel Atom девайс был, ЕМНИП :) Как работает? Живой ещё?
elve
03.08.2022 12:02+3Живой. Третий аккумулятор донашивает. В нем, как и в большинстве телефонов, ломаться особо нечему. Людей толкают к "прогрессу" распухающие до неприличия приложения, которым нужно все больше ресурсов чтобы просто запуститься.
anka007
05.08.2022 11:59Как вы это делаете? В среднем живет два года. Каждый раз новая причина замены.
R7R
03.08.2022 14:19+1Lenovo S660
Lumia 950 XL, October 6, 2015.
Уже не основной телефон, но используется активно.
lowpolyfoxai
04.08.2022 11:30+1У меня как второй аппарат Lumia 640ds, главное на нее не ставить обнову от 2019 года а то начинает так тупить, что ужас. Так бы и юзал до сих пор, если бы не отвалившийся Whatsapp и странные клиенты телеги
Barseadar Автор
04.08.2022 11:31В своё время ходил с Lumia 920, тоже очень нравился, но со временем отказался из-за обнов и софта
R7R
04.08.2022 14:46+1В своё время ходил с Lumia 920
Lumia 920 у меня третий аппарат — на случай, если я забуду дома первый и второй :)
Лежит в ящике на работе и ждет своего часа, зарядить — дело нескольких минут.
Забавно, что все основные функции смарта отлично выполняет, в отличи от второго айфона и нокии 2009 года — по тем можно только звонить :)Barseadar Автор
04.08.2022 15:14Главное, чтобы аккум не умер, лучше держать заряженным на 50-80% :)
R7R
04.08.2022 15:37лучше держать заряженным на 50-80%
Да, я в курсе, спасибо. Заряжаю раз в месяц, держит заряд хорошо.
А вот с Lumia 950 XL все хуже — акк таки дохнет, заряжать надо ежедневно.
(с заменой сложно — мой конкретный аппарат хочет работать только с родными аккумуляторами, с китайцами начинает глючить, самопроизвольно выключаясь после нескольких часов работы)
coolmiha
03.08.2022 08:51+9Любая компания может купить у ARM лицензию на готовые ядра или архитектуру и создавать свои SoC
Простите, больше не любая
thevlad
03.08.2022 10:17+2Да уж, ну вы и замахнулись. Все современные высоко производительные ядра процессоров, построены по схеме в которой главным компонентом является Out-of-Order engine. По сути, он отвечает за спекулятивное исполнение всего, что только можно(предсказание ветвлений, параллельное выполнение независимых веток инструкций, префетчинг дотсупа к памяти и т.д). И внутри этот движок оперирует некоторыми микро-инструкциями в которые транслируются исходная ISA(instruction set architecture, то что по русски называется набором команд или ассемблером процессора). Поэтому CISC, там или RISC, не имеет никакого решающего значения, влияет это всего лишь на транзисторный бюджет декодера, который и так достаточно минорный. Что имеет значение, так это то насколько продвинутый OoO движок вам удалось сделать. Intel и AMD в этом условно говоря "собаку съели". Но вот и Apple подтянулось в их клуб, при этом какую бы ISA они ни взяли, вопрос с точки зрения производительности - глубоко вторичный. Сила RISC и ARM в частности, это когда никакой слишком высокой производительности на такт не надо, и можно сделать тупой и простой процессор который будет оперировать ISA, без каких либо OoO прослоек. Тогда действительно мы получаем, и уменьшенный транзисторный бюджет, и меньшее энергопотребление, и относительно более высокую частоту, а так же производительность.
khajiit
03.08.2022 19:11+2Поэтому CISC, там или RISC, не имеет никакого решающего значения
Давайте представим, для простоты, что в декодеры разом загружается кеш-линия.
ISA влияет, грубо, тем, сможете ли вы это сделать, или будете загружать по одной команде.
Во втором случае получается, что добавить еще один декодер — нужно вылизать остальные настолько, чтобы их не хватало. Или добавить больше сложных инструкций и сделать конвейры длинее, что неминуемо скажется на производительности. И это без учета сложностей остальной внутренней кухни.
В первом — вы просто клепаете больше декодеров, пока ядро справляется.Каждый, кто занимался разгоном, знает, что зависимость мощности от частоты — степенная.
Поскольку функция степени растет быстрее чем произведения, то незначительно сбросив частоты вы можете увеличить ширину ядра вдвое, оставшись в том же теплопакете.
Другими словами, в первом случае вы можете разменять частоту на транзисторный бюджет, и загрузить большее количество (хоть и менее частотных) ИУ, получив гораздо больше производительности на ватт.Происходит так потому, что CISC-инструкция должна пройти не менее одной стадии конвейра, прежде, чем во второй декодер станет возможно загрузить вторую инструкцию — пока не будет считана инструкция, не будет понятно, где она заканчивается.
Четвертый декодер вступит в игру, когда первый, возможно, уже выпустит декодированную команду с конвейра.В то время как RISC-декодеры начинают декодировать все загруженные в них инструкции одномоментно. И, благодаря своей простоте и вытекающему из нее меньшему количеству стадий, примутся за вторую кеш-линию, тогда, когда CISC только-только пережует одну простую инструкцию.
Именно в этом проблема CISC-декодера. Он очень туго масштабируется. Нельзя загрузить в пучок декодеров сразу всю кеш-линию, если вы не знаете, какой декодер откуда должен начать читать данные.
thevlad
03.08.2022 20:43Ох... В исходном посте ясно же описано, что ISA никакой современный производительный процессор не исполняет. ISA преобразуется один раз декодером в микро-инструкции, микро-инструкции сохраняются в кэше микро-инструкций, когда OoO ядро надо получить данные по инструкциям они берутся из кэша. И естественно, даже декодирование исходной ISA происходит, ни так как вы описываете. Декодер должен быть один, так как вам нужно пройтись по всем инструкциям и получить из них один "поток исполнения". И работает он примерно так - на вход загружается буфер, на выходе за счет "параллелизма логических элементов"(то есть скорость декодирования гораздо выше чем инструкция-такт), получается нужный связанный набор микро-инструкций. Для CISC из-за переменной длины инструкций сделать хороший декодер, сложнее чем для RISC, что выливается в некоторый дополнительный транзисторный бюджет. Но на фоне остальных блоков эффект от увеличения достаточно минорный.
khajiit
04.08.2022 22:21+1ISA преобразуется один раз декодером в микро-инструкции, микро-инструкции сохраняются в кэше микро-инструкций
Это вы описали uOPs cache. Но он не всеобемлющ, это всего лишь очень маленький кеш.
Декодер должен быть один
Или вы под декодером понимаете сразу всю конвейерную группу, или застряли во времена 486. Потому как два конвейерных декодера уже были в Pentium, четверть века назад.
В любом случае, присущая RISC регулярная структура набора команд позволяет декодировать параллельно любое количество инструкций, хватило бы мощей все это корректно выполнить.
то есть скорость декодирования гораздо выше чем инструкция-такт
Синхронный конвейр на дюжину стадий с производительностью декодирования гораздо выше чем инструкция-такт?
Знаете, если вы смогли решить проблему сброса конвейра, фатально бьющую по производительности, просто декодером, без хитрых эвристик и нейросетей в предсказателе ветвлений, спекулятивного исполнения и прочего, и прочего — то почему ваши процессоры еще не взорвали рынок?И работает он примерно так — на вход загружается буфер, на выходе за счет "параллелизма логических элементов" <…>
Ну, с этим параллелизмом обратно к синхронному конвейру, зависимостям данных и вычислимым частям CISC-инструкций.
Нет, вы правы в том, что аппаратные компараторы используются при декодировании и работают они асинхронно. Но только в этом.
Для CISC из-за переменной длины инструкций сделать хороший декодер, сложнее чем для RISC
Вы буквально на несколько предложений выше сказали:
скорость декодирования гораздо выше чем инструкция-такт. А теперь говорите о большой сложности.thevlad
04.08.2022 23:36>Это вы описали uOPs cache. Но он не всеобемлющ, это всего лишь очень >маленький кеш.
"Маленький" зависит от вероятности необходимости повторного декодирования и связанных с этим задержками. 2К uop это совсем не маленький.
>Или вы под декодером понимаете сразу всю конвейерную группу, или
> застряли во времена 486. Потому как два конвейерных декодера уже были в
> Pentium, четверть века назад.Pentium был классическим супер-скаляром, в котором если была возможность две соседние инструкции могли исполнится параллельно. Опять же никакой абстракции над исходной ISA, в виде OoO(хотя бы register renaming) и построения динамического графа исполнения там не было. Все это начали подвозить только в Pentium III. Под декодером я понимаю функциональный блок который на входе получает буфер, а на выходе выплевывает микро-инструкции удобоваримые остальными частями OoO движка.
>Синхронный конвейр на дюжину стадий с производительностью декодирования >гораздо выше чем инструкция-такт?
Не понимаю о чем вы говорите. Давайте условимся, что рассматриваем некоторый современный процессор с развитым OoO. Это означает, что у вас по определению есть:
некоторый механизм построения динамического графа исполнения (зависимостей инструкций)
качественное предсказание ветвлений с средней вероятностью по больнице где-то 99%. Применяя предсказания ветвлений, программа разворачивается в граф исполнения
есть некоторое окно инструкций, которые еще "в воздухе", то есть декодированные и к которым применен первичный механизм разрешения зависимостей в графе исполнения. Если мы говорим про классику, то это будет register renaming, с регистровым файлом от 100 элементов. Соответственно, примерно столько же инструкций внутри этого окна.
front-end дополняет этот граф исполнения сверху, то есть делает префетч на подгрузку инструкций и их декодирование, преобразование в микро-инструкции. В более продвинутом варианте у нас скорее всего даже есть кэш микро-инструкций, который даже не смотря на свой небольшой размер, будет существенно снижать нагрузку на декодер.
back-end состояит из execution units(integer/fp) и load/store. Каждый свободный unit получает от OoO движка микро-инструкцию и ее входящие параметры. Эта инструкция для которой входные зависимости уже готовы, OoO движок это знает так как у него есть граф исполнения(в простейшем случаи это реализация в духе register renaming). Таким образом back-end всегда оптимально загружен во "всю ширину". Если нам попался плохой участок кода, с длинной цепной зависимостью, то да их придется исполнить одна за одной. Но обычно граф исполнения, гораздо более разряжен, что позволяет исполнять значительное количество инструкций параллельно.
OoO за счет "окна инструкций", которые содержат текущий кусок графа исполнения, позволяет сделать развязку front-end и back-end. По сути нам важно лишь чтобы средний throughput front-end и back-end совпадали.
самая плохая вещь, это сброс графа исполнения OoO конвеера из-за не предсказанного ветвления, что заставляет отбрасывать спекулятивность и "раскручивать" другую ветку
>Ну, с этим параллелизмом обратно к синхронному конвейру, зависимостям данных >и вычислимым частям CISC-инструкций.
>Нет, вы правы в том, что аппаратные компараторы используются при >декодировании и работают они асинхронно. Но только в этом.
Декодер в OoO подходе это просто штука, которая преобразует некоторый буфер в входной набор микро-инструкций и обладает нужной пропускной способностью. Под "параллельностью" я естественно имею ввиду реализацию в виде комбинаторно-регистровой схемы, которая декодирует с пропускной способностью гораздо больше чем инструкция за такт. (компаратор это к слову по определению аналоговое устройство, и как его применять в данном вопросе цифровой схемотехники, я не представляю. а так да, цифровая схема, состоит из параллельно работающих логических элементов и регистров)
>Вы буквально на несколько предложений выше сказали:
скорость >декодирования гораздо выше чем инструкция-такт. А теперь говорите о >большой сложности.Естественно, чтобы получить IPC >> 1, необходима скорость декодирования значительно больше 1, для любого декодера. Реализация декодера(как функционального блока в рамках OoO процессоора) для CISC сложнее, из-за переменной длины инструкций. Естественно, это будет выливаться как в усложнение алгоритмов, схемотехники, так и увеличение транзисторного бюджета. Но принципиально это ничего не меняет. Даже в самом оптимистичном сценарии, вы сэкономите 5-10% транзисторов, от бюджета всего ядра.
LordDarklight
03.08.2022 11:05+2Статью про софт не будьте написать. Так как тему сложного софта на x86 подняли и так и оставили в стороне. А нынче наступает эпоха, когда ARM процессоры (архитектура) врываются уже на вотчину x86 систем - с появлением Windows 11 ARM (условно всё раньше началось - но это, скорее пробы пера) - позволяющую запускать как софт созданный для ARM систем, так и софт для x86 систем (в эмуляции - условно скрытой с глаз виртуальной машине) - что уже позволяет использовать сложный софт и на вотчине ARM система - мощности то ARM чипов заметно подросли!
Apple тоже пошла путём перехода с x86 на ARM процессоры в своих десктопных и серверных системах - но тут всё куда жёстче - без вариантов перевели всю ОС на ARM - и включили эмуляцию для старого софта x86. Тут уже разделение по сложности софта для разных платформ не выглядит уже значимым!
Есть и обратная тенденция - ARM софт запускают на x86 системах. То есть начался процесс симбиоза платформ на одном софтверном обеспечении. И, хоть, пока это ещё всё в зачаточном состоянии - но если не тенденция не загнётся - следующее поколение ОС (обоих лагерей) могут уже создаваться с обобщённой поддержкой всех популярных платформ, а новый софт под эти ОС будет уже уже изначально проектироваться сразу под все эти платформы (заодно тут ещё и экосистему Linux сейчас под себя начали подминать - ещё один слой симбиоза софта) - как дальше будут развиваться платформы и какая выживет в итоге?
Может это будет открытая RISC-V - ведь эпоха экспоненциального развития ARM, по слухам, уже заканчивается - и спустя лет 10 там тоже начнётся застой.... успеет ли ARM окончательно перетянуть на себя одеяло?
Вот про ОС Linux тоже ни слова пока не сказали. А ведь чем интересна эта ОС так как раз многоплатформенностью - тут есть и RISC и CISC системы. Ядро Linux можно и на принтере запустить - не говоря уже о x86 и ARM компьютерах или смартфонах - везде работает. Да, конечно, прикладной софт так просто уже не запустишь - но было бы желание исходники и библиотеки - можно было бы адаптировать. А в эпоху кроссплатформенной разработки и специальных платформ как .NET и JVM - делать это сало куда проще.
Это я всё к тому - что сейчас наступает эпоха кроссплатформенного софта - и даже если изначально он не создавался под разные платформы - на помощь приходит скрытая виртуализация - и программы запускаются даже не на своей родной архитектуре железа. То есть - софт перестаёт быть якорем, удерживающим на плаву ту или иную архитектуру - и если эта тенденция сохранится - то что же будет лет через 10? Останется ли потребность в нескольких архитектурах процессоров? Или наоборот - вырвутся всё-новые и новые архитектуры и для разных задач будут выбирать наиболее оптимальную - но уже без софтверных ограничений!
И это я ещё не приплёл сюда тенденцию к смещению вычислений в облака! А облачные серверы - это отдельная индустрия - здесь алгоритмы проще всего делать крос-платформенными и даже создавать кластеры из разных платформ, распределяя задачи по ним, исходя из критериев эффективности той или иной архитектуры - и тут будет уже своя конкуренция - и не факт что в итоге какая-то из архитектур не затмит остальные - и всё серверное оборудование плавно не заменят на новую единую архитектуру. А потребителей так ничего и вовсе не заметят - и в этом как раз не будет лишних якорей, тормозящих этот процесс!
А раз вычисления будут больше в облака уходить - то клиентским системам вообще не нужны будут сложные программы - клиентские архитектуры начнут "деградировать" - в угоду меньшего энергопотребления и стоимости. Тут архитектура x86 тогда вообще обречена.
Но есть пока одно исключение: Игры! Да - есть тенденция тоже вносить их в облака - но пока я на это смотрю очень скептически. Ибо тут очень большой трафик (а с ростом разрешения картинки он будет расти неимоверно) и очень высокая требовательность в лагам и стабильности связи - а тут пока всё очень плохо. Сейчас с 8K картинкой без компрессии (с потерями) не справляется даже короткий локальный видео кабель - чтобы обеспечить 120 кадров в секунду - а что уж говорить о сети Интернет - сейчас там относительно стабильную игру можно получить только в FHD. А что будет с 16K? А ведь они рано или поздно придут. Скажете - зачем так много - это уже извращение! Возможно - но всё-равно придут. А Интернет сети не резиновые - уже сейчас там всё очень плотно - и с какого-то момента роста трафика прогресс развития сетей просто не будет за ним успевать!
А уж если говорить о VR и AR технологиях - то они к лагам очень чувствительны (и тут уже желательна 16K картинка для каждого глаза - т.е. 32K) - транслировать такой рантайм контент без лагов по сети в ближайшем будущем вовсе не возможно! И не фак что пока на это даже предпосылки будут! А лаги тут не допустимы!
Вот тут мощное локальное вычислительное оборудование окажется востребованным! Но вряд ли это будет x86 - специфичные задачи будут требовать специфичного адаптированного решения. VR и AR и 3D не базируются на x86 архитектуре (у них она своя - и свои унифицированные API), но пока всё упирается в драйверы - они пока ещё заточены под x86. Но, возможно, в недалёком будущем всё изменится - и игровые консоли переползут на ARM архитектуру (будут оптимизированные драйверы и для PC) - ведь первая ласточка в лице Nintendo Switch то уже есть!
Но облачное серверное применение, как и игровая сфера - это всё-таки темы для отдельных статей!
anka007
03.08.2022 12:24В плане гибкости RISC-V нет равных: имея один базовый набор команд, архитектура может быть расширена большим количеством дополнений разной степени эффективности. Можно создать высокопроизводительную числодробилку с поддержкой всего и вся, можно микрошку для battery-less IoT. И софт потом создается в рамках одной архитектуры, одного контекста разработки.
VelocidadAbsurda
03.08.2022 15:06+2Так ли важна общая архитектура у числодробилки и микроконтроллера? Нынешние примеры на ARM показывают обратное: программисты под Mac «просто программируют в xcode» что для Intel, что для Apple Silicon, программисты микроконтроллеров хоть и заявляют «я освоил ARM», на деле программируют периферию конкретного вендора, при переходе с какого-нибудь STM на NXP общая архитектура ядер не помогает практически никак (а, к примеру, переход с ARM GD32F на RISC-V GD32VF не особо и ощущается). Разница в архитектурах, ощутимо торчащая в софт - 8-битные времена (плохо скрываемый компиляторами зоопарк способов организации памяти/стека/итд).
anka007
03.08.2022 17:36Пока окружение risc-v только-только формируется, посмотрим что будет в итоге.
Но бинарная совместимость по софту у микрика и числодробилки звучит не так уж и плохо с точки зрения пользователя.
VelocidadAbsurda
03.08.2022 17:55+1Так она уже есть в рамках ARM, но что толку, что у какого-нибудь термостата, телефона и мака на М1 общая архитектура? Да, каждая отдельная инструкция переносима, но код в целом - всё равно нет, т.к. окружение, периферия, решаемые задачи - всё разное.
uvic
03.08.2022 15:43+1Мне кажется у автора неверный посыл - что архитектура x86 устаревает.
И в качестве доказательства он приводит то, что каждая вновь появляющаяся архитектура все быстрее и быстрее её догоняет.
Apple вообще понадобилось для этого 4-5 итераций ( выпусков новых моделей процессоров на своей архитектуре ).
Доказательством устаревания x86 было-бы то, какая-то архитектура её уверенно обошла по быстродействию, а не просто очень быстро догнала.Имхо - правильный вывод, что роль архитектуры ВООБЩЕ становится не важна:
Проектирование процессоров все более автоматизируется.
Роль опытной команды разработчиков и наработанных годами оптимизаций архитектуры снижается по мере роста числа транзисторов в процессоре:
Как программу на языке высокого уровня в 100 строк можно ускорить в разы переписав на хард ассемблере.
А переписанная на ассемблере программа в 10 000 000 строк ( если такое было-бы вообще возможно ) скорее всего проиграет программе написанной на языке высокого уровня и откомпилированной оптимизирующим компилятором.-
Человечество набирает опыт сильных и слабых сторон тех или иных решений в проектировании процессоров.
Например - малое множество простых команд раздувает размер программы. И кэши работают менее эффективно ( в них меньше влазит ).
Богатое множество команд - сложности с их интерпретацией внутри процессора.
И т.д. и т.п.
Грубо говоря - можно выдумать свою архитектуру.
Взять современный САПР, учебник где написано как делать ( и как делать не стоит ), пару миллиардов долларов. Допилить в LLVM компиляторе нужную кодогенерацию. И за 3-4 итерации ( выпусков новых моделей процессоров на своей архитектуре ) догнать лидера.И упереться в техпроцесс - из которого большего быстродействия не выжмешь.
То же самое с другой архитектурой и третьей...P.S. Что-то похожее как JIT компиляция быстро прогрессировала, догнала предварительную компиляцию, но так превзойти её не смогла. В чем то один подход на пару процентов лучше. В чем-то другой. А в общем-то паритет.
Barseadar Автор
03.08.2022 15:53В следующей статье я разберу серверные ARM-процессоры, где в некоторых моделях производительность (пиковая и на Ватт) — выше за единицу стоимости и на потребляемую энергию. А потребление энергии — архиважный момент в дата-центрах. Есть серверные ARM-процессоры со 128 ядрами уже сейчас, что улучшает консолидацию ресурсов, а у той же AMD проц EPYС Bergamo со 128 ядрам только в планах на 2023 год. TDP там будет 320 Ватт, а не 250. В общем, я приготовил много интересного :)
uvic
03.08.2022 16:00Я не знаю - но как-то подозреваю что у ARM все хуже в плане межпроцессорного взаимодействия. И возможностей виртуализации ( x86 уже на какую глубину в этом продвинулся? - виртуальная машина из виртуальных машин виртуальных машин ; ))) )
Думаю отними у x86 эти возможности и он сравняется с ARM в производительности на Ватт.
Но это только мои выдумки. Если получится - осветите их в новой статье.Barseadar Автор
03.08.2022 16:17Насчёт межпроцессорного взаимодействия тоже буду рассказывать, уже есть суперкомпьютеры с процессорами ARM (спойлер: один из них был самым мощным в мире до недавнего времени). Интерфейсы I/O, заложенные в архитектуру, и шины более чем позволяют создавать суперкластеры с тысячами нод :)
kamitora
04.08.2022 01:11Расскажите пожалуйста и о том как у армов с максимальной производительностью на ядро в алгоритмах без аппаратного ускорения. В ситуации когда вот прямо завтра выходит новый видеокодек, поддержки которого нет ни в x86 ни в арм, и он не паралелится, и нужно выбрать процессор для максимально быстрого кодирования.
anka007
03.08.2022 18:26Проблема производительности в том, что задача общего назначения написана абы как абы кем. Как только задача становится более-менее определенной, то ее решение сразу оптимизируется и подбирается/создается подходящее железо. х86 - это процессор для задач общего назначения, там применено огромное число оптимизаций для ускорения белого шума из кода. Удивительно, но работает. ARM не ставил себе целью решать задачи общего назначения, у него была вполне конкретная сфера применения. Но так уж исторически сложилось, что именно эта сфера начала активно расти и уже много где пересекается с задачами для х86. ARM успешно рос вместе со своей сферой, и теперь много где может успешно заменить х86. При этом сохраняя относительно низкое потребление, заложеное в него изначально.
Myclass
03.08.2022 19:36@uvic мне ваш вывод не только нравится, но я уверен, что ход мыслей у вас правильный. Построить то, что уже существует - нелегко но в принципе- возможно. Выйти на новый уровень - тут другими талантами надо владеть. Хотя и лидеров в той или иной теме иногда с трона тоже скидывают. Примеров тоже немало. Спасибо за ваши слова. Такого объяснения я не слышал.
MikkiKre
03.08.2022 16:39+1А не кажется ли вам что мы медленно, но уверенно движемся к ARM? Смартфоны уже давно там, cloud-провайдеры предлагают сервера, осталось только десктопы обновить и всё, прощай x86?
Barseadar Автор
03.08.2022 16:42ИМХО. Если x86 будет двигаться в том же темпе, то да, через какое-то время Intel и AMD могут потерять рынок ПК, серверов и консолей (если не перейдут на ARM, конечно).
LordDarklight
03.08.2022 19:03Microsoft и Apple уже смотрят в строну ARM (Apple уже активно переходит, Microsoft пока осторожничает и не сильно спешит).
AMD уже тоже потихоньку смотрит в сторону ARM и покупает профильные компании.
nVIDIA полностью на стороне ARM так - что вот всё пытается её купить с потрохами!
Intel.... вот тут всё туманнее - информации про освоение ARM Интелом очень мало - но вероятно проекты есть - но пока они засекреченные и не большие! Тут очень много репутационных рисков. Но если да - они сильно промедлят - то со временем то займутся официальным выпуском систем на ARM архитектуре, но уже в роле сильно отстающего (как когда-то были дела у AMD когда делили рынок x86 архитектуры - тогда на плову AMD помогли оставить наработки удачные 64битной архитектуры и инструкции AMD 3DNOW! - ныне уже устаревшие; у других старых вендоров x86 решений в загашнике ничего стоящего не нашлось и их выкинули с рынка данной архитектуры - им нечем было закрепить своё право) - но это всё дела давно минувших дней. Так что с Intel пока всё не ясно - если мир десктопа и серверов окончательно сдвинется в сторону ARM (а на это явно потребуется ещё минимум пара десятилетий) - то дела у Intel будут не очень хороши, но это не означает, что они не сумеют перестроиться - талантливых инженеров и программистов у Итнтела предостаточно, как и финансовых ресурсов и силы влияния - если всё не профукают окончательно - то выплывут. Тем более, что через 30 лет у ARM может начаться такой же застой, как у x86 процессоров лет 20 назад. Может к тому моменту ARM уже и не будет такой уж перспективной платформой, а на рынке уже будут активно действовать другие конкурирующие архитектуры - та же RISC-V или ещё какая-нибудь, что появится за эти 30 лет (может что-то совсем новое - на основе продвинутого AI и ультрамногопоточгных нелинейных вычислений - как когда-то случилось с видеокартами). Вот Intel тогда может попробовать сразу сделать ставку на новую архитектуру. Тем более, что к тому моменту прикладной софт в большинстве своём будет уже ориентироваться на кроссплатформенную разработку и не будет таким уж чувствительным к разным платформам - а ОС могут сразу разрабатываться с поддержкой разных архитектур процессоров!
Armmaster
03.08.2022 19:02+2Тема поднята интересная и важная, но статья грешит множеством неточностей и лакун. Например, делается такое утверждение:
Например, Intel Core i9-12900K или AMD Ryzen 7 4750G — это не CPU, как мы привыкли их называть, а APU (Accelerated Processor Unit), то есть процессор с интегрированной графикой (iGPU) на одном кристалле
и далее:
А вот на ARM чаще всего другая логика — SoC (System-on-a-Chip) или система на кристалле
Это какое-то кривое сравнение, я бы сказал в корне неверное. Все современные процессоры от Intel, Amd, а также ARM-чипы - это SoC'и. APU - это некоторый термин, придуманный скорее в маркетинговых целях, по сути обозначающий, что в состав конкретного SoC'а входит GPU. Т.е. можно считать APU подвидом SoC'а, но никаких "других логик" тут нет и в помине.
В статье, как мне кажется, расплывчато сформулировано то, а почему всё же АРМ стал побеждать. Да, есть преимущества в лицензировании, но почему тогда не MIPS, или какой-нибудь OpenRISC, например? Или почему тот же Intel не смог предложить нужные продукты? Ведь на серверных и десктопных рынках у него это до последнего времени прекрасно получалось. Всё же важно подчеркнуть, что лицензирование от Arm важно не просто чисто экономически, но даёт производителям гибкость в создании специализированных SoC, что и было драйвером роста Arm-экосистемы. И компания ARM смогла предложить здесь хороший компромисс в соотношении цены лицензий и развитости предоставляемого IP.
DustCn
04.08.2022 16:25-3Очередное маркетинговое дерьмо, в которой маркетолог изнасиловал инженера. Степень погружения в тему просто потрясает, зато хайповых заголовков и утверждений тьма тьмущая.
Barseadar Автор
05.08.2022 12:12Всегда рад конструктивной критике. Давайте общаться в рамках этикета Хабра, а не превращать его в vc :)
yri066
05.08.2022 09:45В этом году сменил телефон OnePlus 5 (2017года) на snapdragon 835 и установил Kali Linux и был удивлен как отлично работают десктопные программы (например Firefox) и количеством адаптированного софта под arm. В данный момент держу на нем домашний сервер Minecraft.
Rezzet
Благо мы живем не в 2010, а в 2022, когда уже есть CMake, кросскомпиляция, компиляторы которые умеют генерировать код под любую платформу, куча открытого софта и библиотек, если в 2010 годы было вообще непонятно как обеспечить поддержку проекта в хкоде и вижуалстудии, то сейчас это делает щелчком пальца, ну почти. Сложность разработки кроссплатформенных программ понизилась в разы, если не на порядки. Даже для внутренних программ поддержка мака и виндовс считается чем-то самой собой разумеющимся. Так что если будут две конкурирующих платформы станет только лучше. Добавить RISC-V, MIPS и прочее станет значительно проще, чем при переходе от одного монополиста. Сейчас даже поддержка линукса, с его мемными 1,5% процентами пользователей, становится чем-то само собой разумеющимся, не у всех и не всегда, но тем не менее. Даже микрософт уже пилит софт для линукса. Я считаю, и с этим можно спорить, что устойчивость в многообразии.
napa3um
Пусть расцветают сто цветов, пусть соревнуются сто школ!
larasage
Лишь бы не оказалось, что это часть истории под названием «Пусть змея высунет голову»... :)
Admz
Однако для рядового потребителя эти "сто школ" выливаются в такие муки выбора "правильной" техники. Пусть уж лучше 2-3, и голова не болит. И найдут техническиу и моральную поддержку и там и там. А если сто?
hyperwolf
А рядовой пользователь и так не выбирает, а берет то, что советует реклама и друзья
napa3um
Да, в том и дело, что большинство мук выбора в жизни людей - это навязываемые маркетологами муки :).
Myclass
У вас есть другой вариант, который на выходе обязательно лучший результат выдаст? Думаю уже тысячелетиями доказано, что конкуренция делает это лучше. И да, иногда этой конкуренции может быть и много, как например с приложениями по всевозможным темам.
napa3um
Не очень понял, чему именно вы возражаете. Мы живём в эпоху перепроизводства, когда предложения уже не удовлетворяют потребности, а стимулируют спрос. Конкуренция, по сути, идёт "за цвет упаковки" (эмоцию приобретения), это немного не потребительские качества, это лечение психоза, который маркетологами же и вызван. Такова жизнь, и эта ситуация - ни для кого не секрет :).
Большинству пользователей на самом деле "подошёл" бы любой современный процессор, прям вообще любой, но искусственные маркетинговые ограничения (в том числе пресловутое запланированное устаревание) задают постоянный градиент "роста". Человечество разогнало экономику, и не в силах её остановить :).
(Поймите меня правильно, это просто грустная философия, а так я и сам пишу этот комментарий с ноутбука на M1-Pro, и мне приятно похвастаться этим :))
Myclass
Я вас понимаю. В этом-то и загвоздка, что мы думаем, что можно любую какашку разрекламировать и всё - рынок захвачен. А оно не так. Часто для этого приводится пример с IE, и тем, как Microsoft пропихивала его везде. Но IE выполнял свои функции и удовлетворял пользователей.
Как бы мы не думали про других невысоко, но в общем своём люди выбирают в своей массе то, что их потребности удовлетворяет, а не то, что им кто-то втюрить хочет. И да, на рекламу уходит много денег. Но ведь и в приватной жизни так.
Нам кроме 7 маек и трусов летом ничего и не надо. Но нет - покупаем шорты, рубашку поло, очки итд. и обязательно с каким-нибудь брендом. Рациональность в нашей жизни только меньшая часть нашего поведения. Большая- это эмоции и чувства. Это было всегда. Булочку в средневековье покупали уверен чаще, если запах из пекарни на всю улицу 'слышен' был, а не там, где по составу она тоже кусок теста была, но с меньшим запахом. Поэтому конкуренция самоопределяется. Количество игроков регулируется само. Как? В каждом случае по разному.
napa3um
Нет, я так не думаю :). И мысли мои вовсе не о "невысокости" людей, вы явно не со мной спорите, а с каким-то очень чётко кем-то нарисованным чучелом, за которое вы меня принимаете :).
Myclass
Извиняюсь, просто ваши слова
мне не понятны вообще никак. Что такое разогнали? Я уверен, что Вы не думаете, что IPhone, Боинг или квантовый компьютер с потолка подают? Каждые новый продукт новая технология или методика - это жестокая конкуренция, это уйма вложенных денег и времени. И Ваши последние слова доказывают неспособность Вами-же высаазанной идеи, приведённой мною выше.
И ещё. Зачем экономику останавливать? Когда такое требование вообще ставилось на нашей планете, что его невозможно исполнить? Вы не хотите ещё лучших процессоров, лучших фраймеворков, лекарств, ещё быстрых коммуникаций, и например боллее удобных и безопасных транспортных средств? Ответ почему-то могу себе представить.
napa3um
Да вообще-то не особо хочу, мне бы существующие потребить хоть когда-нибудь, успеть похотеть их. Моя жизнь не такая насыщенная, как ваша, видимо :).
Myclass
Сам себе каждый день в голове говорю, что надо меньше есть, а потом накрывается стол и....я не могу себе отказать. ????
Но вас понимаю. Можно себя отдельно взятого сдерживать и не покупать 10 лет новый мобильник, и на машине ездить пока совсем не заржавеет. И некоторые это делают. Знаю таких. Другие вообще пренебрегают любыми новшествами. Их меньше. Но и таких тоже знаю. Но. Ведь мы не остановим этим прогресс. Он будет с нами или без нас. Но, он будет идти безостановочно вперёд. И ожидать, что жить без прогресса или почти без него захотят все - такому не быть. От слова никогда.
Но каждый из нас вправе это делать. Но ожидать от других то, что сами не делаем - так себе предложение.
napa3um
Вы сами придумали, что я что-то кому-то запрещал или предлагал делать (или что я рассуждал об необходимости или даже возможности остановить движение цивилизации) :). Никто не
Tuvok
Есть экономика, которая двигает прогресс, который делает нашу жизнь лучше, а есть экономика, которая двигает прогресс ради прогресса, а порой и просто ради "больше денег". А вот чтобы оправдать эти "больше денег" и приходится прикрываться "прогресс ради прогресса", который не делает нашу жизнь лучше, а только внешне выглядит таковым. И вот в этом смысле я согласен с предыдущим участником.
svr_91
А в результате, все просто пишут код на javascript для браузера/электрона (что тот же браузер)
f1inx
Все это было и в 2000, а если исключить CMake (кроме него существовал давно automake/autoconfig) то и в 90x с кросскомпиляцией проблем не было. Наоборот скорее общее число поддерживаемых архитектур с того времени заметно уменьшилось...
anka007
Кросскомпиляция возникла чуть позже вообще компиляции. Каждая новая машина разрабатывалась на другой машине, и комплятор для новой машины пишется одновременно с разработкой железа, потому что новая машина без <кросс>компилятора и минимального набора ПО не нужна наверное с 80х. Ну может 90е, с тех пор как одним ассемблером стало невозможно реализовать минимальный набор ПО новой вычислительной системы.
Rezzet
Все так, только вот сложность этого занятия была значительно выше. Собрать что-то написанное с использованием autoconfig тот еще квест.