MISC и форт-процессоры.

>>1211255
Двачую этого просвещенного. MISC проиграл эволюционную войну RISC - следовательно, он inferior и ненужен. Микроядра проиграли монолитам и тоже ненужны.

Посоны, вот обесните мне. У интелов куча команд на все случаи жизни, но по сути дела это макросы которые в самом процессоре декодируются на набор простых команд. У армов такой хуйни нет, и вся эта ебола ложится на плечи компилятора. Так уот, эти макросы интеловские они же один хуй выполняюся не за один такт а как набор мелких команд. Нахуй они тогда нужны если прироста в производительности нету? Нахуя пихать на камень то что должен делать компилятор?

>>1211242 (OP)
А что, VLIW не может быть CISC?

>>1211415
> У армов такой хуйни нет
У армов тоже микрокод, прямо начиная с ARM1. Просто его там меньше, и по возможностям он тоже сильнее ограничен.

> эти макросы интеловские они же один хуй выполняюся не за один такт
Зато они позволяют процессору более эффективно планировать эти микрооперации по execution-unit-ам.

>>1211415
Ты немного не понимаешь, что это за команды. Это не элементарщина типа r1 <- r2 + r3, а ядрёный хардкор типа коммутации регистров с блоками процессора. Ну, типа, битовая маска отправляется на управляющий регистр АЛУ и у тебя add unit делает вычитание с переносом, еще одна маска на регистр коммутатора - и этот unit соединяется с нужными регистрами.

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

Что касается того, зачем это нужно. Во-первых, обратная совместимость. Первые процы amd64 годами использовались в 32-битном режиме, и должны были сохранять конкурентоспособность, даже в ущерб будущему, так что одни и те же блоки должны были использоваться обоими ABI. Во-вторых, навороченные инструкции экономят место в кэше инструкций - а он очень ограничен. Я могу ошибаться, но вроде как исполнительные блоки внутри проца работают на кратно большей частоте, чем сам проц, так что далеко лезть за инструкциями они не могут, упираясь в скорость света. Ну и в-третьих, в ARM-ах тоже есть что-то типа микрокода, просто он намертво зашит еще на этапе проектирования проца и не меняется :)

Кстати, идея писать напрямую на микрокоде известная, называется VLIW и использовалась интелами в EPIC (итаниумах), амд в радеонах и долбоёбами в эльбрусах. Говорят, Итаниумы знатно соснули просто за счет того, что написать под них эффективный компилятор оказалось невозможно.

>>1211415
> У армов такой хуйни нет
Есть. Как минимум, простая операция "прочитать число из памяти" делится на этапы "узнать физический адрес по виртуальному" и на непосредственно чтение.

>>1212963
Так а че там с MISC этим вашим?
Ну там, как на нем писать сложные программы, есть шансы язык уровня C++ там или лисп какой со всеми плюшками компилировать?
Что там с когерентным доступом к памяти?

>>1211439
>амд в радеонах

Кстати, последние тераскейлы в игрулях первое время таки уделывали ранний GCN. Собственно, с VLIW на жирный SIMD (который был у нвидии еще с 8000 серии, лал) перешли чисто по причине compute, потому что у vliw архитектуры исполнительные блоки простаивали, когда речь не шла об обработке трехмерных векторов.

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

Вот на месте МЦСТ я бы все силы бросил на эльбрус и хотя бы до 3ггц его дотянул (сейчас у каждого подвального завода в китае можно, и даже есть IP которые продадут), но жадные коррумпированные тридварахи такие тридварахи.

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

>Тео де Раадт (Theo de Raadt) публично предупредил о наличии серьёзной уязвимости в реализации HyperThreading, рекомендуется отключить эту опцию для
>любых компьютеров, где может выполняться недоверенный код (например, JavaScript-код интернет-сайта).
>https://marc.info/?l=openbsd-tech&m=152910536208954&w=2

Ну то есть это говно было мертворожденным изначально, и работало только потому, что всем было похуй на безопастность. Могли бы и защищенный режим памяти не вводить вообще. Еще бы производительность подняли бы.

>>1213043
>Могли бы и защищенный режим памяти не вводить вообще. Еще бы производительность подняли бы.
И так люди живут. Причем то на то и выходит: выигрыш от отсутствия MMU примерно равняется потерям от введения промежуточной регистровой VM.

>>1213043
>Могли бы и защищенный режим памяти не вводить вообще.
Напоминаю о такой старинной проблеме как фрагментация кучи (области "heap memory"). В таком случае она будет общей на всех.

>>1213133
>Напоминаю о такой старинной проблеме как фрагментация кучи (области "heap memory"). В таком случае она будет общей на всех.
Не думаю что это такая уж большая проблема.

Как минимум всякие дотнеты ее давно и успешно решают.

Ну и вообще, приложения не склонны рандомно херачить память, ибо это затратно.

Что кстати на скринах?

>>1213101
>И так люди живут. Причем то на то и выходит: выигрыш от отсутствия MMU примерно равняется потерям от введения промежуточной регистровой VM.
Тащемто, выигрыш не только в прямой производительности, но и в транзисторном бюджете, и в простоте подсистемы памяти\кешей.

А запускать рандомный бинарный код на реальном железе - идея очень плохая, как заниматься сексом с бомжом.
Такая ерунда никогда не должна была иметь место на ПЕРСОНАЛЬНЫХ компьютерах.

Но мы быть можем может сейчас что-то с этим зделать...

Разработать свою, особую архитектуру, без легаси. Заточенную под сорт лисповой VM, и с тегированной памятью. Лолз.

>>1213336
> Ну и вообще, приложения не склонны рандомно херачить память, ибо это затратно.
Ты к нам из начала девяностых пишешь? Хотя нет, строчкой выше ты дотнеты упоминаешь.

>>1213336
>А запускать рандомный бинарный код на реальном железе - идея очень плохая, как заниматься сексом с бомжом.
>Такая ерунда никогда не должна была иметь место на ПЕРСОНАЛЬНЫХ компьютерах.
В итоге мы к этому и придем. Вот только реализация, боюсь, тебе не очень понравится.
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

>>1211255
А может кто-нибудь ссылок по этому накидать? Я все собираюсь сделать в симуляторе простейший процессор на отдельных микросхемах с низкой интеграцией (что-то уровня 7400), но никак не могу даже с набором команд определиться.
Понравился подход J1 http://www.excamera.com/files/j1.pdf Но у него адресное пространство маленькое. Можно растянуть инструкции этого процессора до 32 разрядов, но будет неэффективно использоваться память. Делать 24-разрядный?

>>1213040
Не знал про эту подробность, но оно и неудивительно. Замена fixed function пайплайна на VLIW ядра вроде как очевидное решение, учитывая, что шейдерам из -надцати инструкций другого и не надо, а Итаниум к тому времени еще не сдох. Вот что не понятно, так это почему эти самые ядра при их простоте нельзя перевести на новый техпроцесс, клокнуть где-нибудь на 6ГГЦ и снова побороться рынок =/

>>1213043
Я как-то читал постмортем в нескольких частях от программиста фэйлового ларашмеле, там упоминалось, что разработчики цпу сами программировать не умеют и лепили горбатого, делая процы по советам гуру векторных оптимизаций. Поищи, занимательное чтиво.

>>1213457
>Вот что не понятно, так это почему эти самые ядра при их простоте нельзя перевести на новый техпроцесс, клокнуть где-нибудь на 6ГГЦ

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

>>1213133
Не проблема аще, можно переделать гарбаж коллектор в дефрагментатор памяти и пускать его в случае oom.

>>1213336
>>1213401
Даже не считая андроеда, аппле уже всё сделало - в аппсторе байт-код конпелируют из байт-кода под каждый девайс. Если не допускать запуск неподписанного кода, то можно и без mmu обойтись и вообще оставить от ОС только экзоядро. Но нахуя? На mmu потери порядка 15% максимум, а современные ядра вообще clockless и тоже не мешают. Не считая мелтдауна, с современным нативным стаком все и так збс.

>>1213462
Извините, опечатался, нативный код из байт-кода, конечно.

>>1213459
А что относится к растеризатору? Я как-то не вижу, где кроме gpgpu и какой-нибудь тесселяции проявляются слабости VLIW (т.е. херовая оптимизация при бранчащемся коде).

>>1213464
>А что относится к растеризатору?
Он треугольник разбивает на фрагменты, которые отправляются в пиксельный шейдер, интерполирует вершинные атрибуты, и делает z и стенсил тест, собирает фрагменты в MSAA.
>Я как-то не вижу, где кроме gpgpu и какой-нибудь тесселяции проявляются слабости VLIW
В шейдерах VLIW провалился, потому что AMD делала систему комманд с упором на векторы из четырех значений, а на практике такие операции не так часто встречаются. Поэтому сейчас там скалярные операции (в смысле SIMD юнит считает сложение в четырех потоках, а не сложение двух 4-векторов).

>>1213462
Но нахуя? На mmu потери порядка 15% максимум, а современные ядра вообще clockless и тоже не мешают. Не считая мелтдауна, с современным нативным стаком все и так збс.
И крака.
Вопрос именно в том и состоит, нахуя, если всеравно поверх ВМ крутится, а проц дырявый.

>>1213479
> Он треугольник разбивает на фрагменты
Все еще не понятно. Разве нельзя это перевести на fixed function и сэкономить часть теплопакета?

> а на практике такие операции не так часто встречаются
Неинтуитивно, но в принципе этого следовало ожидать. Благодарю за науку. Разве что то, что ты описываешь, называется не SIMD, а MIMD.

>>1213491
У тебя неверные, навеянные пропагандой вендоров представления о производительности современных ВМ. Когда ты видишь сравнение бенчмарков, например, шарпа с крестами, знай, что в 2018 году в кодеках и численных методах лучшие конпеляторы, бывает, делают где-то в 3-10 раз более медленный код, чем средние ассемблерщики. И ситуация к лучшему уже не изменится - математики с инженерами из ИТ ушли и разработка принципиально новых автоматических оптимизаций почти заглохла. Накроешь весь софт гондоном дотнета - и будет у тебя новый ноут не четырнадцать часов работать, а восемь, и все равно будет падать и ломаться, потому что баги в оптимизаторах тоже встречаются, а заклинить всю систему софтинам мешает как раз mmu.

>>1213505
1 У тебя неверные представления о том как работает обсолютное большинство кода, написанное вовсе не на ассемблере.
2 Есть мнение, что, хоть на бинарных кодах ты пиши, когда ты добавишь все необходимые проверки безопасности и корректности данных, скорость твоя станет в ровень с высокоуровневыми языками.
3 Не пишут на ассемблере ничего сложнее 10 команд по переключению цп в нужный режим или для взлома дырявой виртуальной памяти.

>>1213513
> Не пишут на ассемблере ничего сложнее 10 команд по переключению цп в нужный режим или для взлома дырявой виртуальной памяти.
Загугли libavcodec/x86, например, теоретик.

Хотя я в целом ты прав, компиляторы асм в обычных приложениях догоняют. А в специальных автоматическая векторизация сосет, и если уж не асм, то хотя бы интринсики - это необходимый минимум.

>>1213516
libavcodec не на асме ниразу хотя очевидно асм там широко используется.
А векторные расширения чтобы юзать совсем необязательно асм использовать.
И очевидно что сорта системного кода может и должно без ВМ запускаться. И чтобы код из ВМ мог его использовать.

>>1213505
>Разве нельзя это перевести на fixed function
Это и так fixed function. Сейчас только альфа-смешивание потихоньку делают шейдерным (на мобилках уже почти везде, на десктопе - у интелов последних).
>Разве что то, что ты описываешь, называется не SIMD, а MIMD
Это именно SIMD, потому что инструкции во всех тредах одинаковые и исполняются одновременно. Различается только контекст треда - маски исполнения и содержимое регистров. Внутри там обычные векторные блоки вроде SSE, по несколько штук на один исполнительный модуль.

>>1213516
>>1213520
Когда я пишу о 3-10 раз разнице, я имею ввиду именно то, как конпеляторы пытаются использовать векторизатор. Хуево у них получается. Даже когда пишешь напрямую интринсики, никогда не знаешь, когда сволочи решат спиллить регистры. А упоминаемый мною дотнет мне пару месяцев назад скомпилировал FFT с использованием FPU, как делали диды. Такшта ассемблер бывает самым разумным решением.

>>1213558
Понял. У меня, получается, о гпу ложные представления, буду учиться :(

Что то фигня, что другое фигня.

Самая правильная система команд это Everest.
Лет через 20 или 25 она убъёт всех конкурентов.

>>1215296
>Everest
Это гда она такая?

>>1215583

В ПЛИС

>>1215666
Так это не Цп. Толку от нее?

>>1216058
>Так это не Цп. Толку от нее?

Ты чего-то не понимаешь. Сегодня FPGA, через несколько лет ASIC. А другие архитектуры больно, мучительно и медленно умрут.

>>1216058
>Так это не Цп
Скоро будет на ЦП:
https://www.allaboutcircuits.com/news/intel-to-introduce-new-cpu-fpga-hybrid-chip-supported-by-acceleration-stack/

>>1216741
>Ты чего-то не понимаешь. Сегодня FPGA, через несколько лет ASIC
Эм.
Асик это ЦП же будет или что?
Если система команд управляет плисиной, то как может быть асик в принципе не плисиной?

>>1216749
Что несешь вообще.

>>1216885

Это типа усатые свитера теперь смогут вылезать из своих нии за 20 000 и пиздовать в барбершопы?

>>1216885
Не взлетит. Во-первых, чипсеты под межделмашевские камни сами по себе дичайше дорогие - самая дешевая материнка марки Талос на один сокет обойдется в $1500 минимум. Во-вторых, прикладной софт типа кодеков и opencv до сих пор слабо под них оптимизирован, так что ускорять пока нечего, боттлнек скорее всего будет в другом месте. Ну и в-третьих, кто эти ПЛИСы программировать будет? Это ж совершенно отдельный скилл, в котором нубы и середнячки вообще пользы не принесут, т.к. нужно обогнать оптимизированный вусмерть код на cpu/gpu, используя на порядок более слабую железку. Будет вам очередной дата сайенс - море хайпа и отсутствие рабочих мест.

>>1217136

> Во-первых, чипсеты под межделмашевские камни сами по себе дичайше дорогие - самая дешевая материнка марки Талос на один сокет обойдется в $1500 минимум.

Не межделмашевские,а по принципу межделмашевских, то бишь куча ядер разного назначения и плис все на одном кристалле.

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

>>1216864
>Что несешь вообще.
Это не я несу, это интел собирается альтеровские FPGA ядра внутри своих процов ставить.

>>1217155

Уже:

https://ark.intel.com/products/series/125191/Intel-Xeon-Scalable-Processors

>>1217155
Та на здоровье. Пусть себе ставят.

Ты мне скажи, Everest это что, система для программирования ПЛИСов?

Что в ней такого особенного?

И можно ли ее считать системой команд в принципе? Если речь о ПЛИСе идет.

>>1217205
>Everest это что

Рабочее название будущей SOC от хилинхов, в которой на одном кристалле объединены плис и вычислительные ядра разного назначения.

>>1217209
Пиздец.

Мы туту о системе команд говорили, о модели выполнения.
А тут ты со своей плис залез.

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

>>1217209
>Рабочее название будущей SOC от хилинхов,

Ха-ха-ха.

http://everest.l4os.ru/

>>1217642

Хамелеон это POSIX сервисы поверх микроядра L4. Нечто вроде ядра Линукс. Только попроще.

>>1217224

Кстати, о системе команд - вот та система команд, которая обозвана "Эверест", она спроектирована так, чтобы могла расширяться почти бесконечно. Это одна из её особенностей.

>>1217667
>Есть ли альтернативы стандарту
Есть альтернативы POSIX.
а альтернатив СТАНДАРТУ нет. Стандарт безальтернативен в виду своей стандартности.

>>1217735
https://xkcd.com/927/

>>1217667
>- старое костыльное говно которое тормозит прогресс;

Для 99% юзкейсов его возможностей достаточно. Ради одного процента отщепенцев курочить приемлимо-стройную систему, которая со своей задачей справляется, смысла нет.

>>1217665
Это тот мужик с ютуба, который не может двух слов связать? И который спиздил UTF-8 и обозвал это уродство "бесконечно расширяемой системой команд"? И думает, что если оно взлетит, оно не превратится в такую же бесконечно расширяемую помойку, как набор инструкций x86?

>>1217896

А с чего бы ей превратиться в помойку?
Если б не требования обратной совместимости, x86 тоже мог бы стать хорош, а не тем, чем он сейчас является.

>>1218200
>А с чего бы ей превратиться в помойку?
>Если б не требования обратной совместимости, x86 тоже мог бы стать хорош, а не тем, чем он сейчас является.

От требований обратной совместимости?

>>1218200
>Если б не требования обратной совместимости, x86 тоже мог бы стать хорош, а не тем, чем он сейчас является.
Пфах.

https://3dnews.ru/971788
>Исследователи выявили новую уязвимость процессоров Intel на базе Hyper-Threading

Это говно полное дыр и костылей. Всегда им было.

Хотя, ладно, Pentium MMX и AMD K6-2 были довольно неплохими.

>>1218220
> Это говно полное дыр и костылей. Всегда им было.
Любая архитектура со временем становится говном, полным дыр и костылей. И есть два варианта: либо наплевать на юзеров и кучу существующего бинарного кода, сделав что-то новое, либо тащить костыли дальше. Интел решил тащить костыли, и тащит их достаточно качественно, поэтому x86, несмотря на все ее недостатки, до сих пор "архитектура по умолчанию".

>>1218278
Да ладно, действительно качественно тащит. А вот если в один момент они решатся отказаться от совместимости, то всем остальным будет не до смеха. Т.ч. надо молиться, чтобы Интел и дальше трепетно относился к обратной совместимости.

>>1218729
> парад критических уязвимостей в фундаментальной конструкции механизмов
Ты так говоришь, как будто они только в x86 есть. Это фундаментальная проблема существующего дизайна, и совершенно никаким местом не проблема набора инструкций.

>>1218738
>Ты так говоришь, как будто они только в x86 есть. Это фундаментальная проблема существующего дизайна, и совершенно никаким местом не проблема набора инструкций.

Я тут об архитектуре говорю. Сами по себе наборы инструкций ничего не значат, очевидно же. Они неразрывно связанны с архитектурой.

>>1218729
> это качественно тащит?

Ты вообще представляешь как x86 работает внутри? На уровне триггеров, сумматоров и прочей чешуи. Что такое "критический путь" знаешь? Уж насколько я не люблю x86, но то, что сделала Интел, это волшебство.

Да, x86 это говно, но говно вкусное, изысканное и отборное. А всё остальное хуже.

>>1218745
>> это качественно тащит?

>Ты вообще представляешь как x86 работает внутри? На уровне триггеров, сумматоров и прочей чешуи. Что такое "критический путь" знаешь? Уж насколько я не люблю x86, но то, что сделала Интел, это волшебство.
Как оказалось это глючный костыль. Который если чинить теряет фактически всякий смысл.

>Да, x86 это говно, но говно вкусное, изысканное и отборное. А всё остальное хуже.
Ок.

>>1218742
> Они неразрывно связанны с архитектурой.
Подавляющее большинство инструкций - микрокодированные, регистров давным давно на порядок больше, чем в ISA. Где там что связано-то?

>>1218750
>Где там что связано-то?
В кристалле профессора.
Там транзисторы всякие проводочки.

>>1218750
>Подавляющее большинство инструкций - микрокодированные, регистров давным давно на порядок больше, чем в ISA. Где там что связано-то?
Обновлением микрокода, кстати, последние 10ток критических уязвимостей в интел х86 не чинятся.

>>1213043
>Могли бы и защищенный режим памяти не вводить вообще.

И где Вы дауны беретесь то такие?
Ты хоть блядь знаешь сколько ты должен механизму виртуальной памяти? Мразь ты конченая, иди сука учить теорию. Дяди из DEC старались сука, а ты говно тут несешь такое. Съеби однако нахуй обратно.

>>1218749
>Как оказалось это глючный костыль. Который если чинить теряет фактически всякий смысл.

Все процессоры глючный костыль, если убрать все эти волшебные дырявые приборчики - тут же перенесетесь на машине времени в середину двухтысячных когда в потолок 3-4Ghz уперлись.

>>1225461
Я плохо улавливаю твою мысль.
Гипероптимизации ломающие ключевые механизмы безопасности (из за которых весь сыр бор с х86) как-то связанны с тактовыми частотами?

Поднятие тактовых частот с 3ггц до 5 ценой 4хкратного роста энергопотребления это очень важное достижение?

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

> 3ггц до 5 ценой 4хкратного роста энергопотребления
Например, энергопотребление десктопа меня мало волнует. С серверами и носимыми устройствами все сложнее, да, но там и задачи лучше параллелятся.

>>1211242 (OP)
Так уж и быть. Вставлю свои 5 копеек. Я думаю что ARM архитектура взлетит в начале 20-30х годов этого века. Например Nvidia Tegra TK1 выглядит очень привлекательно. Тем более раз уж мы взяли курс на IOT и нейронки. Да и если сравнить энергопотребление оного ARM девайса то оно значительно ниже чем у аналогичного x86-го, так что будет логичным предположить что ARM и до десктопов доберется (не сразу конечно, но как понадобиться жестко экономить энергию, то тогда это вполне возможно). Тем более ARM не требует в большинстве случаев активного охлаждения, не теряя в производительности. Тогда возможно появятся крутые штуки на их основе, типо сверхтонких ультрабуков, или десктопов размером с Raspbery Pi (только с производительностью как у intel xeon)

>>1225682
> Да и если сравнить энергопотребление оного ARM девайса то оно значительно ниже чем у аналогичного x86-го,
Нет.
Одинаково, до неск процентов.

>>1225682
> ARM архитектура взлетит
Да вокруг тебя уже сотни ARM-процессоров, куда уж больше-то взлетать?

>>1225787
но его нет в моей пекарне

>>1225588
>как-то связанны с тактовыми частотами?

Да. с невозможностью их дальнейшего увеличения и увеличения с их помощью производительности. Со все большим и большим отставанием скорости оперативы от процессора.

>>1244233

А нахера тебе он нужен?

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

Типичный кукурузный многояд, со степенью кукурузности ещё хуже чем на фуфиксах, если мысленно довести тактуху до их уровня.

>>1244233
> но его нет в моей пекарне
Далеко не факт. Он может быть в твоей мыши, в твоей клаве, в твоем мониторе, и даже твоей вроде бы x86-материнке.