MISC и форт-процессоры.
Двачую этого просвещенного. MISC проиграл эволюционную войну RISC - следовательно, он inferior и ненужен. Микроядра проиграли монолитам и тоже ненужны.
Посоны, вот обесните мне. У интелов куча команд на все случаи жизни, но по сути дела это макросы которые в самом процессоре декодируются на набор простых команд. У армов такой хуйни нет, и вся эта ебола ложится на плечи компилятора. Так уот, эти макросы интеловские они же один хуй выполняюся не за один такт а как набор мелких команд. Нахуй они тогда нужны если прироста в производительности нету? Нахуя пихать на камень то что должен делать компилятор?
А что, VLIW не может быть CISC?
> У армов такой хуйни нет
У армов тоже микрокод, прямо начиная с ARM1. Просто его там меньше, и по возможностям он тоже сильнее ограничен.
> эти макросы интеловские они же один хуй выполняюся не за один такт
Зато они позволяют процессору более эффективно планировать эти микрооперации по execution-unit-ам.
Ты немного не понимаешь, что это за команды. Это не элементарщина типа r1 <- r2 + r3, а ядрёный хардкор типа коммутации регистров с блоками процессора. Ну, типа, битовая маска отправляется на управляющий регистр АЛУ и у тебя add unit делает вычитание с переносом, еще одна маска на регистр коммутатора - и этот unit соединяется с нужными регистрами.
К тому же, декодер инструкций занимается еще много чем, например, раскидывает операции по разным блокам, ибо суперскалярность, и переименовывает регистры, ибо в ABI их, допустим, шестнадцать, а технология позволяет, допустим, сто двадцать восемь. Ты думаешь, что у тебя код сбрасывает регистры в стек, а нихуя, они туда, конечно, попадают, но проц просто отодвигает их в один из скрытых регистров и дальше берет их уже оттуда. Еще, если не ошибаюсь, современные интелы умеют переводить короткие бранчи в условное исполнение, как в ABI армов.
Что касается того, зачем это нужно. Во-первых, обратная совместимость. Первые процы amd64 годами использовались в 32-битном режиме, и должны были сохранять конкурентоспособность, даже в ущерб будущему, так что одни и те же блоки должны были использоваться обоими ABI. Во-вторых, навороченные инструкции экономят место в кэше инструкций - а он очень ограничен. Я могу ошибаться, но вроде как исполнительные блоки внутри проца работают на кратно большей частоте, чем сам проц, так что далеко лезть за инструкциями они не могут, упираясь в скорость света. Ну и в-третьих, в ARM-ах тоже есть что-то типа микрокода, просто он намертво зашит еще на этапе проектирования проца и не меняется :)
Кстати, идея писать напрямую на микрокоде известная, называется VLIW и использовалась интелами в EPIC (итаниумах), амд в радеонах и долбоёбами в эльбрусах. Говорят, Итаниумы знатно соснули просто за счет того, что написать под них эффективный компилятор оказалось невозможно.
> У армов такой хуйни нет
Есть. Как минимум, простая операция "прочитать число из памяти" делится на этапы "узнать физический адрес по виртуальному" и на непосредственно чтение.
>MISC проиграл эволюционную войну RISC - следовательно, он inferior и ненужен.
Это было всего лишь сражение за рынок general purpose CPU. Войта еще толком не начиналась.
>Микроядра проиграли монолитам и тоже ненужны.
Микроядра -- это вообще исторический курьез уровня модели OSI. Куча дополнительной сложности just for the sake of it. Экзоядра ftw.
Так а че там с MISC этим вашим?
Ну там, как на нем писать сложные программы, есть шансы язык уровня C++ там или лисп какой со всеми плюшками компилировать?
Что там с когерентным доступом к памяти?
>амд в радеонах
Кстати, последние тераскейлы в игрулях первое время таки уделывали ранний GCN. Собственно, с VLIW на жирный SIMD (который был у нвидии еще с 8000 серии, лал) перешли чисто по причине compute, потому что у vliw архитектуры исполнительные блоки простаивали, когда речь не шла об обработке трехмерных векторов.
Кстати, в свете глобального фрактала отсосов предсказательных приборчиков в штеудах и армах , которые на поверку оказались дырявыми, только старина Itanium и его EPIC архитектура с честью выдержали проверку.
Вот на месте МЦСТ я бы все силы бросил на эльбрус и хотя бы до 3ггц его дотянул (сейчас у каждого подвального завода в китае можно, и даже есть IP которые продадут), но жадные коррумпированные тридварахи такие тридварахи.
Вот на месте МЦСТ я бы все силы бросил на эльбрус и хотя бы до 3ггц его дотянул (сейчас у каждого подвального завода в китае можно, и даже есть IP которые продадут), но жадные коррумпированные тридварахи такие тридварахи.
>Кстати, в свете глобального фрактала отсосов предсказательных приборчиков в штеудах и армах
У интела еще и гипертред провалился полностью.
>Тео де Раадт (Theo de Raadt) публично предупредил о наличии серьёзной уязвимости в реализации HyperThreading, рекомендуется отключить эту опцию для
>любых компьютеров, где может выполняться недоверенный код (например, JavaScript-код интернет-сайта).
>https://marc.info/?l=openbsd-tech&m=152910536208954&w=2
Ну то есть это говно было мертворожденным изначально, и работало только потому, что всем было похуй на безопастность. Могли бы и защищенный режим памяти не вводить вообще. Еще бы производительность подняли бы.
>Могли бы и защищенный режим памяти не вводить вообще. Еще бы производительность подняли бы.
И так люди живут. Причем то на то и выходит: выигрыш от отсутствия MMU примерно равняется потерям от введения промежуточной регистровой VM.
>Могли бы и защищенный режим памяти не вводить вообще.
Напоминаю о такой старинной проблеме как фрагментация кучи (области "heap memory"). В таком случае она будет общей на всех.
>Напоминаю о такой старинной проблеме как фрагментация кучи (области "heap memory"). В таком случае она будет общей на всех.
Не думаю что это такая уж большая проблема.
Как минимум всякие дотнеты ее давно и успешно решают.
Ну и вообще, приложения не склонны рандомно херачить память, ибо это затратно.
Что кстати на скринах?
>И так люди живут. Причем то на то и выходит: выигрыш от отсутствия MMU примерно равняется потерям от введения промежуточной регистровой VM.
Тащемто, выигрыш не только в прямой производительности, но и в транзисторном бюджете, и в простоте подсистемы памяти\кешей.
А запускать рандомный бинарный код на реальном железе - идея очень плохая, как заниматься сексом с бомжом.
Такая ерунда никогда не должна была иметь место на ПЕРСОНАЛЬНЫХ компьютерах.
Но мы быть можем может сейчас что-то с этим зделать...
Разработать свою, особую архитектуру, без легаси. Заточенную под сорт лисповой VM, и с тегированной памятью. Лолз.
>Разработать свою, особую архитектуру, без легаси.
Разработали еще при царе Горохе. Та же Xtensa из проприетарщины или недавний открытый RISC-V. Пожалуйста, можешь повыкидывать все свистоперделки.
>Заточенную под сорт лисповой VM, и с тегированной памятью.
Тоже еще в 90х было готово, пикрелейтед. Без этих ваших Лиспов, правда - нефиг людей смущать.
> Ну и вообще, приложения не склонны рандомно херачить память, ибо это затратно.
Ты к нам из начала девяностых пишешь? Хотя нет, строчкой выше ты дотнеты упоминаешь.
>А запускать рандомный бинарный код на реальном железе - идея очень плохая, как заниматься сексом с бомжом.
>Такая ерунда никогда не должна была иметь место на ПЕРСОНАЛЬНЫХ компьютерах.
В итоге мы к этому и придем. Вот только реализация, боюсь, тебе не очень понравится.
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
А может кто-нибудь ссылок по этому накидать? Я все собираюсь сделать в симуляторе простейший процессор на отдельных микросхемах с низкой интеграцией (что-то уровня 7400), но никак не могу даже с набором команд определиться.
Понравился подход J1 http://www.excamera.com/files/j1.pdf Но у него адресное пространство маленькое. Можно растянуть инструкции этого процессора до 32 разрядов, но будет неэффективно использоваться память. Делать 24-разрядный?
Не знал про эту подробность, но оно и неудивительно. Замена fixed function пайплайна на VLIW ядра вроде как очевидное решение, учитывая, что шейдерам из -надцати инструкций другого и не надо, а Итаниум к тому времени еще не сдох. Вот что не понятно, так это почему эти самые ядра при их простоте нельзя перевести на новый техпроцесс, клокнуть где-нибудь на 6ГГЦ и снова побороться рынок =/
Я как-то читал постмортем в нескольких частях от программиста фэйлового ларашмеле, там упоминалось, что разработчики цпу сами программировать не умеют и лепили горбатого, делая процы по советам гуру векторных оптимизаций. Поищи, занимательное чтиво.
>Вот что не понятно, так это почему эти самые ядра при их простоте нельзя перевести на новый техпроцесс, клокнуть где-нибудь на 6ГГЦ
Шейдерные ядра у них и так хорошие, у них в игорях с растеризаторами проблемы.
Не проблема аще, можно переделать гарбаж коллектор в дефрагментатор памяти и пускать его в случае oom.
Даже не считая андроеда, аппле уже всё сделало - в аппсторе байт-код конпелируют из байт-кода под каждый девайс. Если не допускать запуск неподписанного кода, то можно и без mmu обойтись и вообще оставить от ОС только экзоядро. Но нахуя? На mmu потери порядка 15% максимум, а современные ядра вообще clockless и тоже не мешают. Не считая мелтдауна, с современным нативным стаком все и так збс.
Извините, опечатался, нативный код из байт-кода, конечно.
А что относится к растеризатору? Я как-то не вижу, где кроме gpgpu и какой-нибудь тесселяции проявляются слабости VLIW (т.е. херовая оптимизация при бранчащемся коде).
>А что относится к растеризатору?
Он треугольник разбивает на фрагменты, которые отправляются в пиксельный шейдер, интерполирует вершинные атрибуты, и делает z и стенсил тест, собирает фрагменты в MSAA.
>Я как-то не вижу, где кроме gpgpu и какой-нибудь тесселяции проявляются слабости VLIW
В шейдерах VLIW провалился, потому что AMD делала систему комманд с упором на векторы из четырех значений, а на практике такие операции не так часто встречаются. Поэтому сейчас там скалярные операции (в смысле SIMD юнит считает сложение в четырех потоках, а не сложение двух 4-векторов).
Но нахуя? На mmu потери порядка 15% максимум, а современные ядра вообще clockless и тоже не мешают. Не считая мелтдауна, с современным нативным стаком все и так збс.
И крака.
Вопрос именно в том и состоит, нахуя, если всеравно поверх ВМ крутится, а проц дырявый.
> Он треугольник разбивает на фрагменты
Все еще не понятно. Разве нельзя это перевести на fixed function и сэкономить часть теплопакета?
> а на практике такие операции не так часто встречаются
Неинтуитивно, но в принципе этого следовало ожидать. Благодарю за науку. Разве что то, что ты описываешь, называется не SIMD, а MIMD.
У тебя неверные, навеянные пропагандой вендоров представления о производительности современных ВМ. Когда ты видишь сравнение бенчмарков, например, шарпа с крестами, знай, что в 2018 году в кодеках и численных методах лучшие конпеляторы, бывает, делают где-то в 3-10 раз более медленный код, чем средние ассемблерщики. И ситуация к лучшему уже не изменится - математики с инженерами из ИТ ушли и разработка принципиально новых автоматических оптимизаций почти заглохла. Накроешь весь софт гондоном дотнета - и будет у тебя новый ноут не четырнадцать часов работать, а восемь, и все равно будет падать и ломаться, потому что баги в оптимизаторах тоже встречаются, а заклинить всю систему софтинам мешает как раз mmu.
1 У тебя неверные представления о том как работает обсолютное большинство кода, написанное вовсе не на ассемблере.
2 Есть мнение, что, хоть на бинарных кодах ты пиши, когда ты добавишь все необходимые проверки безопасности и корректности данных, скорость твоя станет в ровень с высокоуровневыми языками.
3 Не пишут на ассемблере ничего сложнее 10 команд по переключению цп в нужный режим или для взлома дырявой виртуальной памяти.
> Не пишут на ассемблере ничего сложнее 10 команд по переключению цп в нужный режим или для взлома дырявой виртуальной памяти.
Загугли libavcodec/x86, например, теоретик.
Хотя я в целом ты прав, компиляторы асм в обычных приложениях догоняют. А в специальных автоматическая векторизация сосет, и если уж не асм, то хотя бы интринсики - это необходимый минимум.
Расскажите лучше о MCP и Burroughs large systems.
libavcodec не на асме ниразу хотя очевидно асм там широко используется.
А векторные расширения чтобы юзать совсем необязательно асм использовать.
И очевидно что сорта системного кода может и должно без ВМ запускаться. И чтобы код из ВМ мог его использовать.
>Разве нельзя это перевести на fixed function
Это и так fixed function. Сейчас только альфа-смешивание потихоньку делают шейдерным (на мобилках уже почти везде, на десктопе - у интелов последних).
>Разве что то, что ты описываешь, называется не SIMD, а MIMD
Это именно SIMD, потому что инструкции во всех тредах одинаковые и исполняются одновременно. Различается только контекст треда - маски исполнения и содержимое регистров. Внутри там обычные векторные блоки вроде SSE, по несколько штук на один исполнительный модуль.
Когда я пишу о 3-10 раз разнице, я имею ввиду именно то, как конпеляторы пытаются использовать векторизатор. Хуево у них получается. Даже когда пишешь напрямую интринсики, никогда не знаешь, когда сволочи решат спиллить регистры. А упоминаемый мною дотнет мне пару месяцев назад скомпилировал FFT с использованием FPU, как делали диды. Такшта ассемблер бывает самым разумным решением.
Понял. У меня, получается, о гпу ложные представления, буду учиться :(
Что то фигня, что другое фигня.
Самая правильная система команд это Everest.
Лет через 20 или 25 она убъёт всех конкурентов.
Самая правильная система команд это Everest.
Лет через 20 или 25 она убъёт всех конкурентов.
>Everest
Это гда она такая?
В ПЛИС
Так это не Цп. Толку от нее?
>Так это не Цп. Толку от нее?
Ты чего-то не понимаешь. Сегодня FPGA, через несколько лет ASIC. А другие архитектуры больно, мучительно и медленно умрут.
>Так это не Цп
Скоро будет на ЦП:
https://www.allaboutcircuits.com/news/intel-to-introduce-new-cpu-fpga-hybrid-chip-supported-by-acceleration-stack/
>Ты чего-то не понимаешь. Сегодня FPGA, через несколько лет ASIC
Эм.
Асик это ЦП же будет или что?
Если система команд управляет плисиной, то как может быть асик в принципе не плисиной?
Что несешь вообще.
Короче суть такова, сайлинкс зделоли жирную SOCку "все в одном" навроде айбиэмовских камней для ихних мейнфреймов только еще с плисиной внутри. Вроде как для всяких новомодных сириус бизнес применений вроде соседнего нейроночки тредика.
Это типа усатые свитера теперь смогут вылезать из своих нии за 20 000 и пиздовать в барбершопы?
Не взлетит. Во-первых, чипсеты под межделмашевские камни сами по себе дичайше дорогие - самая дешевая материнка марки Талос на один сокет обойдется в $1500 минимум. Во-вторых, прикладной софт типа кодеков и opencv до сих пор слабо под них оптимизирован, так что ускорять пока нечего, боттлнек скорее всего будет в другом месте. Ну и в-третьих, кто эти ПЛИСы программировать будет? Это ж совершенно отдельный скилл, в котором нубы и середнячки вообще пользы не принесут, т.к. нужно обогнать оптимизированный вусмерть код на cpu/gpu, используя на порядок более слабую железку. Будет вам очередной дата сайенс - море хайпа и отсутствие рабочих мест.
> Во-первых, чипсеты под межделмашевские камни сами по себе дичайше дорогие - самая дешевая материнка марки Талос на один сокет обойдется в $1500 минимум.
Не межделмашевские,а по принципу межделмашевских, то бишь куча ядер разного назначения и плис все на одном кристалле.
И под весь этот зоопарк хилинх обещает тулзы чтобы такой на гвидоне с OpenCL пишешь говнокод не задумываясь о бренности байтолюбства и оно само там умными конпеляторами по ядрам разного назначения оптимизируется и в плис пердолится.
>Что несешь вообще.
Это не я несу, это интел собирается альтеровские FPGA ядра внутри своих процов ставить.
Та на здоровье. Пусть себе ставят.
Ты мне скажи, Everest это что, система для программирования ПЛИСов?
Что в ней такого особенного?
И можно ли ее считать системой команд в принципе? Если речь о ПЛИСе идет.
>Everest это что
Рабочее название будущей SOC от хилинхов, в которой на одном кристалле объединены плис и вычислительные ядра разного назначения.
Пиздец.
Мы туту о системе команд говорили, о модели выполнения.
А тут ты со своей плис залез.
А, ну да, раскидать инструкции по юнитам компиляторы не могут, а по софтовым ядрам вдруг смогут. Звучит как очередные интеловские маняфантазии. По релизу выяснится, что гпу дешевле и быстрее, а те, кто умеет в плисы лучше слепят партию на порядок более эффективных асиков за те же деньги. А все сделанные плисины альтера отправит в НИИ говна и торфа, приучать студней к плохому.
Наша цель — создать микропроцессор для использования в проекте Хамелеон.
Что такое хамелеон?
Хамелеон это POSIX сервисы поверх микроядра L4. Нечто вроде ядра Линукс. Только попроще.
Кстати, о системе команд - вот та система команд, которая обозвана "Эверест", она спроектирована так, чтобы могла расширяться почти бесконечно. Это одна из её особенностей.
Дабы не плодить сущностей,
POSIX:
- старое костыльное говно которое тормозит прогресс;
- непрерывно эволюционирующий стандарт, не теряющий актуальности и показатель адекватности и зрелости любой операционной системы поддерживающей этот стандарт;
Есть ли альтернативы стандарту, сколько в нём плохих, по нынешним временам, решений.
Спрашивать у ебанутых в софтаче смысла не вижу
POSIX:
- старое костыльное говно которое тормозит прогресс;
- непрерывно эволюционирующий стандарт, не теряющий актуальности и показатель адекватности и зрелости любой операционной системы поддерживающей этот стандарт;
Есть ли альтернативы стандарту, сколько в нём плохих, по нынешним временам, решений.
Спрашивать у ебанутых в софтаче смысла не вижу
>Есть ли альтернативы стандарту
Есть альтернативы POSIX.
а альтернатив СТАНДАРТУ нет. Стандарт безальтернативен в виду своей стандартности.
>- старое костыльное говно которое тормозит прогресс;
Для 99% юзкейсов его возможностей достаточно. Ради одного процента отщепенцев курочить приемлимо-стройную систему, которая со своей задачей справляется, смысла нет.
Это тот мужик с ютуба, который не может двух слов связать? И который спиздил UTF-8 и обозвал это уродство "бесконечно расширяемой системой команд"? И думает, что если оно взлетит, оно не превратится в такую же бесконечно расширяемую помойку, как набор инструкций x86?
А с чего бы ей превратиться в помойку?
Если б не требования обратной совместимости, x86 тоже мог бы стать хорош, а не тем, чем он сейчас является.
>А с чего бы ей превратиться в помойку?
>Если б не требования обратной совместимости, x86 тоже мог бы стать хорош, а не тем, чем он сейчас является.
От требований обратной совместимости?
>Если б не требования обратной совместимости, x86 тоже мог бы стать хорош, а не тем, чем он сейчас является.
Пфах.
https://3dnews.ru/971788
>Исследователи выявили новую уязвимость процессоров Intel на базе Hyper-Threading
Это говно полное дыр и костылей. Всегда им было.
Хотя, ладно, Pentium MMX и AMD K6-2 были довольно неплохими.
> Это говно полное дыр и костылей. Всегда им было.
Любая архитектура со временем становится говном, полным дыр и костылей. И есть два варианта: либо наплевать на юзеров и кучу существующего бинарного кода, сделав что-то новое, либо тащить костыли дальше. Интел решил тащить костыли, и тащит их достаточно качественно, поэтому x86, несмотря на все ее недостатки, до сих пор "архитектура по умолчанию".
> Интел решил тащить костыли, и тащит их достаточно качественно
Да ладно, действительно качественно тащит. А вот если в один момент они решатся отказаться от совместимости, то всем остальным будет не до смеха. Т.ч. надо молиться, чтобы Интел и дальше трепетно относился к обратной совместимости.
>Да ладно, действительно качественно тащит.
Это последний то парад критических уязвимостей в фундаментальной конструкции механизмов многопоточности спекулятивного выполнения и виртуальной памяти, всего того что и делает х86 такой потентной, это качественно тащит?
Ну если говорить о том, что i386 функционал работает как надо, то да, тащит, лол. Но это не так на самом деле. Со старым ПО ты сосьнеш.
> парад критических уязвимостей в фундаментальной конструкции механизмов
Ты так говоришь, как будто они только в x86 есть. Это фундаментальная проблема существующего дизайна, и совершенно никаким местом не проблема набора инструкций.
>Ты так говоришь, как будто они только в x86 есть. Это фундаментальная проблема существующего дизайна, и совершенно никаким местом не проблема набора инструкций.
Я тут об архитектуре говорю. Сами по себе наборы инструкций ничего не значат, очевидно же. Они неразрывно связанны с архитектурой.
> это качественно тащит?
Ты вообще представляешь как x86 работает внутри? На уровне триггеров, сумматоров и прочей чешуи. Что такое "критический путь" знаешь? Уж насколько я не люблю x86, но то, что сделала Интел, это волшебство.
Да, x86 это говно, но говно вкусное, изысканное и отборное. А всё остальное хуже.
>> это качественно тащит?
>Ты вообще представляешь как x86 работает внутри? На уровне триггеров, сумматоров и прочей чешуи. Что такое "критический путь" знаешь? Уж насколько я не люблю x86, но то, что сделала Интел, это волшебство.
Как оказалось это глючный костыль. Который если чинить теряет фактически всякий смысл.
>Да, x86 это говно, но говно вкусное, изысканное и отборное. А всё остальное хуже.
Ок.
> Они неразрывно связанны с архитектурой.
Подавляющее большинство инструкций - микрокодированные, регистров давным давно на порядок больше, чем в ISA. Где там что связано-то?
>Где там что связано-то?
В кристалле профессора.
Там транзисторы всякие проводочки.
>Подавляющее большинство инструкций - микрокодированные, регистров давным давно на порядок больше, чем в ISA. Где там что связано-то?
Обновлением микрокода, кстати, последние 10ток критических уязвимостей в интел х86 не чинятся.
>Могли бы и защищенный режим памяти не вводить вообще.
И где Вы дауны беретесь то такие?
Ты хоть блядь знаешь сколько ты должен механизму виртуальной памяти? Мразь ты конченая, иди сука учить теорию. Дяди из DEC старались сука, а ты говно тут несешь такое. Съеби однако нахуй обратно.
>Ты хоть блядь знаешь сколько ты должен механизму виртуальной памяти? Мразь ты конченая, иди сука учить теорию. Дяди из DEC старались сука, а ты говно тут несешь такое.
Это ты инженерам интела претензии предъявляй.
>Как оказалось это глючный костыль. Который если чинить теряет фактически всякий смысл.
Все процессоры глючный костыль, если убрать все эти волшебные дырявые приборчики - тут же перенесетесь на машине времени в середину двухтысячных когда в потолок 3-4Ghz уперлись.
https://riscv-basics.com/
Господи, как же я взоржал! Зашевелились, сучьи дети. Ничего, второе пришествие божественной MIPS-архитектуры не за горами, готовьтесь занять свое место на свалке истории со своими LDMIAEQ SP!, {R4-R7, PC}.
Я плохо улавливаю твою мысль.
Гипероптимизации ломающие ключевые механизмы безопасности (из за которых весь сыр бор с х86) как-то связанны с тактовыми частотами?
Поднятие тактовых частот с 3ггц до 5 ценой 4хкратного роста энергопотребления это очень важное достижение?
Очевидно, что если бы мы не упирались в тактовую частоту, отказаться от всяких предсказателей в процессорах было бы гораздо легче.
> 3ггц до 5 ценой 4хкратного роста энергопотребления
Например, энергопотребление десктопа меня мало волнует. С серверами и носимыми устройствами все сложнее, да, но там и задачи лучше параллелятся.
Нет, не очевидно.
Ты какую-то дичь несешь.
>Например, энергопотребление десктопа меня мало волнует.
Киберкотлета?
Что ты в этом треде вообще забыл?
Так уж и быть. Вставлю свои 5 копеек. Я думаю что ARM архитектура взлетит в начале 20-30х годов этого века. Например Nvidia Tegra TK1 выглядит очень привлекательно. Тем более раз уж мы взяли курс на IOT и нейронки. Да и если сравнить энергопотребление оного ARM девайса то оно значительно ниже чем у аналогичного x86-го, так что будет логичным предположить что ARM и до десктопов доберется (не сразу конечно, но как понадобиться жестко экономить энергию, то тогда это вполне возможно). Тем более ARM не требует в большинстве случаев активного охлаждения, не теряя в производительности. Тогда возможно появятся крутые штуки на их основе, типо сверхтонких ультрабуков, или десктопов размером с Raspbery Pi (только с производительностью как у intel xeon)
> Да и если сравнить энергопотребление оного ARM девайса то оно значительно ниже чем у аналогичного x86-го,
Нет.
Одинаково, до неск процентов.
> ARM архитектура взлетит
Да вокруг тебя уже сотни ARM-процессоров, куда уж больше-то взлетать?
но его нет в моей пекарне
>как-то связанны с тактовыми частотами?
Да. с невозможностью их дальнейшего увеличения и увеличения с их помощью производительности. Со все большим и большим отставанием скорости оперативы от процессора.
А нахера тебе он нужен?
К 8 версии архитектуры - такое же блотанутое говно с легаснёй, дырами и миллиардом системных регистров, как и штеуд. Производительность на ватт +- такая же только при никакой однопоточной.
Типичный кукурузный многояд, со степенью кукурузности ещё хуже чем на фуфиксах, если мысленно довести тактуху до их уровня.
> но его нет в моей пекарне
Далеко не факт. Он может быть в твоей мыши, в твоей клаве, в твоем мониторе, и даже твоей вроде бы x86-материнке.
Честно, не знаю куда такой трэд заебенить потому оставлю его здесь,
Я просто нихуя не знаю, а почитав срач можно хотя бы понять в каком направлении копать
Норм конторы под свой софт создают свои микропроцессоры.