Михаил Усоцкий

Снижение частоты вполне реально. Столь длинный массив на кристалле микросхемы непросто синхронизировать. Именно по этой причине видеокарты, VLIW-процессоры и любой вычислительный узел с параллельным вычислением работают всегда на пониженной частоте. Хотя на практике производитель может пойти на ухищрения и хитрости. Например, вместо вычисления одновременно 8 элементов будет четыре раза по два элемента. Это как пример. Есть реальный пример: Pentium 4, внутри АЛУ у него 16-разрядный. Для вычисления 32-разрядного элемента АЛУ выполняет в две стадии. Зато можно повысить частоту. Именно этим и объясняется столь длинный конвейер.

А критику Торвальдса я как-то могу понять. AVX512 фактически дублирует существующие, используя более длинные регистры. Ещё читал разные материалы по поводу. AVX512 разбит на части, и будет поддерживаться в разных моделях по-разному. Представляете, какой геморрой будет у разработчиков компиляторов? Хотя, в общем, система команд x86/x86-64 всегда славилась бардаком (удивительно, что они ещё умудряются быстро выполнять команды). Я и не говорю о трудностях разработчиков уже конечных программ, как САПР, мультимедийные редакторы и прочее. Это, получается, надо указывать дополнительно, какие именно процессоры нужны. Это сильно сужает выбор. Но он прав, что лучше улучшать технологию в многопоточности. Ведь не каждый день будете вычислять матрицу 4х4. А вдруг захотите вычислить матрицу 5х5? Проблема. А многопоточностью всегда можно управлять. Например, я всегда отдаю предпочтение многопоточной реализации в разработке. Проще разрабатывать и контролировать. Когда ненужна высокая производительность, можно отключить ненужные ядра. Да. Я забыл добавить, что увеличение команд для x86/x86-64 неизбежно приводит к росту размера памяти микроопераций, который находится в процессоре.

А если всё-таки нужна такая длинная операция, то тогда это лучше передать ускорителю вычислений. Например, видеокарты. Они давно умеют с этим работать. И регистры у них очень длинные. Можно реализовать в виде APU, как у AMD. Это куда практичней.

Сейчас большинство сложных микросхем проектируют на ПЛИСе, используя языки VHDL или Verilog (SystemVerilog). Это единственный способ более-менее быстро разработать и проверить работоспособность своей реализации. После проектирования они могут запустить пробную партию для испытаний. Если прошли испытания - запускают в серию, нет - отправляют на переработку, исправлять блоки (либо заменить, либо переместить в пределах одного кристалла). Расписывать схему потранзисторно нет смысла, да и много времени уйдёт. Поэтому потранзисторно схему расписывают только те, которые составляют IP-блоки или библиотеки на более низком уровне, чем VHDL или SV. А оборудование на основе этого уже достаёт нужный набор шаблонов и расставляет их в соответствии реализацией разработчика в нужном порядке.

В Itanuim существует определённое количество регистров в 128 штук. 32 из них статические, а остальные - динамические под регистровые окна. В SPARC регистровые окна представляют собой классический барабан, зависящий от реализации производителя, и дают программисту в распоряжении только 31 логический регистр (+ нулевой регистр). А физических регистров там могут легко доходить и до не скольких сотен. У МСЦТ R500 количество физических регистров 132, как я помню. Но может быть выделено небольшое количество регистров-окон. То есть для SPARC можно оптимизировать архитектуру под конкретные задачи, где хранимые данные можно не гонять сразу в ОЗУ, при работе программ с различной глубиной вызовов и стека.