Комментарии 47
Поделитесь своими регалиями в проектировании процессоров? Человек замахнувшийся на то чтобы советовать ведущим корпорациям наверно имеет множество достижений?
Гугл показывает странное https://www.google.com/search?q=Александр+Бобров
Напомнило.
В одной компании, где я работал, был проект. И было в том проекте некоторое количество интересных решений (на уровне отдавать в ответе сервиса всегда 200 ОК, а ошибку класть в поле error ответа, а если ответ успешный, то его класть в поле data, конечно же сериализовав его предварительно в строку). И когда я спросил у коллег, откуда это все взялось, мне ответили, что актер какой-то написал. Даже ссылку на статью про него скинули.
Один вопрос: почему вы считаете, что так будет лучше, и что инженеры Intel до этого не додумались и уже не проверили это всё? Насколько я знаю, передовые инженеры в разработке процессоров знают или английский, или китайский, даже если их неродной язык ;)
Влажные фантазии.
Очень советую учить английский и сначала много-много читать и задавать вопросов себе, интернету и коллегам.
А на самом деле использование сложных видов адресации данных, связано с малым количеством регистров, поэтому та команда, которая могла бы выполнятся за 1 такт, выполняется за 4 и более
Банальность:
Если не понимать, что много тормозов проистекает не в процессоре, а в реализованной программе, то и выводы по увеличению «производительности» не будут правильно сделаны.
P.S. Есть/были процессоры архитектуры MISC (0-адресная система команд) подобие внутреннего кода использованного в Java, C# так вот они вполне неплохо конкурировали с регистровыми RISC процессорами в тесте CoreMark
но т.к. и их код команд смогли с помощью JIT, AOT хорошо перекладывать на регистры, то поэтому они особо и не сделали своей погоды, а создавать инструментальную экосистему ещё и для них мало кому улыбалось. :)
Как это повлияет на транзисторный бюджет? Например автоматы на троичной логике могли бы вытеснить двоичную по скорости вычисления задач, но при переносе на физику двоичная по совокупности факторов побеждает. Может тут тоже не настолько всё на поверхности, если учитывать частности?
Если у кого есть возможность и главное желание, переслать и по желанию перевести на английский язык данную статью, представителям компаний Intel и АМД, очень интересно их мнение по этому поводу.
И да, если она им покажется интересной, на авторские выплаты не претендую, а вот от вознаграждения за идею не откажусь.
А ваши знания о проектировании процессоров разве не позволяют вам достойно зарабатывать? Какой размер вознаграждения вас-бы устроил?
Вообще то, компьютер в новой концепции, вообще не нуждается в материнской плате. В самом простом исполнении это алюминиевый лист, к которому прикручены 4 чипа.
Шедеврально! :)
У ней внутре неонка (c)
Не, про неонку это чуть дальше:
... стандартный переходник, в котором находятся светодиоды и фотодиоды ничего сложного и дорогого. Просто с одной стороны светодиод переводит сигнал на контакте в свет, а с другой стороны свет фотодиод переводит обратно из света в сигнал на контакте.
При частоте шины 4 Ггц ...
Ну очень просто перевести электричество в свет и свет в электричество на четырех гигагерцах, элементарщина же, пффф. Несколько сложнее четырех микросхем на алюминиевом листе, но тоже ничего сложного. Осталось прикрутить на тот же лист дорожки и все Интел, ты банкрот!
4 цапы, которые надо крутить - Цапу крути, цапу!
Для чего нам нужен конвейер с одновременной обработкой нескольких потоков одним ядром? А это необходимо для того, что пока выполняется команды одного потока, в этот самый такт происходит подготовка операндов для команд другого потока, который будет выполняться следующим, и в этот же такт происходит сохранение результатов работы команд, которые обрабатывались тактом ранее.
это сейчас примерно так и работает в современных процессорах
Каждое ядро процессора одновременно обрабатывает сразу 4 машинные команды. Т.е. сразу обрабатывается блок размером 16 байт. На обработку каждого блока команд отводится 1 такт процессора. Что дает увеличение производительности более чем в 2 раза. (часть команд фоновые, поэтому только в 2 раза увеличение)
В каждом блоке не могут одновременно использоваться несколько одинаковых команд. За исключением самых простых и часто используемых. (Это позволит тому же АЛУ выполнять параллельно 4 команды, без усложнения схемы. Ведь они не повторяются, а для каждой команды есть свой вычислительный блок.)
Каждое ядро одновременно выполняет 8 потоков, после выполнения команды одного потока, происходит переключение на выполнение команды другого потока и так по кругу. Такой конвейер позволяет обеспечить быстродействие выполнения блока из 4 команд за один такт процессора. Переключение потоков происходит мгновенно, просто переключая страницы регистров.
эти ограничения превращают процессор в SIMD архитектуру, для которой нельзя будет писать полностью параллельный произвольный код. такие фокусы действительно дают очень мощное ускорение по сравнению с классическими процессорами, но по другой схеме - это называется SIMD GPGPU, по-простому "считать на видеокартах"
и там действительно x100 и даже x1000 производительность, только для такого процессора нужно особым образом организовывать данные и код (CUDA/OpenCL), поэтому эта архитектура ещё не заменила классические CPU (но nVidia активно топит в эту сторону)
просто так любой код ни под ваш вариант SIMD ни под правильный SIMD GPGPU не скомпилировать
p.s. не по наслышке, занимаюсь программированием видеокарт 10 лет
Кринж (извините).
Походу автора заморозили где-то в конце 1970-х годов.
Узким местом современных процессоров семейства х86 является старая система команд и очень малое количество регистров общего назначения.
НЕ является. Система команд в современных OoO процессорах практически не имеет значения. Функционально, возможности х86 / arm / risc-v примерно равны.
Это только удобство для компилятора / программиста.
Команды перекодируются в МОП-ы, регистры переименовываются (и их сотни уже).
Внутри OoO процессоры х86 / arm работают одинаково (с высоты птичьего полёта).
Путем понижения тактовой частоты процессора до 2,5 Мгц, а вычислитель наоборот разгоняем до 5. Тогда он сможет за 1 такт обработать и операцию с одного ядра и с другого.
2,5МГц - достойная цель для 2022г. В Z80 уже было 3,5МГц.
Каждое ядро процессора одновременно обрабатывает сразу 4 машинные команды. Т.е. сразу обрабатывается блок размером 16 байт.
Процессоры х86, как и ARM, обрабатывают блок 32 байта.
Будучи в криокамере, вы наверное пропустили, но современные процессоры уже выполняют 6-10 команд за такт. А Эльбрус вообще 50 :)
В основном из за этого, выполнение некоторых машинных команд увеличивается с 1 до 4 и более тактов процессора.
Например команда, mov eax, [ebx+ecx*4+342]
Такая адресация вычисляется за такт начиная с 486.
1700 контактов у последних моделей процессоров, ну это уже слишком много и как при этом можно увеличивать количество процессоров?
Половина контактов это подводка питания.
https://en.wikichip.org/wiki/amd/packages/socket_am4#Pin_Map
В общем налицо полное непонимание вопроса, либо осознанный глум (искал тег "юмор").
В первом случае рекомендую написанное забыть и начать изучение вопроса с устройства простого DLX.
"CISC-овость" isa может ограничивать компилятор в оптимизациях. Для наглядности можно посоединять инструкции. Например пусть будет mul/add строго как одна целая 3-операндная операция и ещё добавим "фичу" - все операции работают только с памятью, регистры не доступны. Так можно долго играть пока внутрь процессора компилятор не переедет
"CISC-овость" isa может ограничивать компилятор в оптимизациях
Я и написал "Это только удобство для компилятора / программиста."
В основном различия имеются в SIMD наборах, но не кардинальные.
Например пусть будет mul/add строго как одна целая 3-операндная операция
Это как раз базовая RISC операция, которая со скрипом попала в SIMD набор х86.
Вы наверно не так поняли
Я о том что
Isa НЕ только для удобства компилятора / программиста
Каждый раз когда говорят что ISA не имеет значения - мне непонятно в насколько широких рамках это утверждение считается истинным утверждающим
Вы же использовали слово "только" - значит считаете что ISA можно вообще любой сделать и при этом это никак не повлияет на количество необходимых оптимизаций для ISA с более сложными инструкциями?
Соответственно, в данном случае, я довожу ситуацию до абсурда
В примере с mul-add я имел ввиду не только добавить mul-add, но и убрать add и mul
То есть если убирать самые простые инструкции и добавлять более комплексные то появятся накладные расходы:
1.Раскладывание на мопы
2.Генерация бОльшего числа мопов потому что многие задачи требующие ряда простых инструкций могут неожиданно решаться за бОльшее число сложных инструкций. Как например сделать xor через умножение
3.БОльшее число мопов потребует элиминации большего ....числа мопов
Я однозначно много чего ещё не учёл
Но всё таки вы наверно имели ввиду что в среднем по больнице текущие ISA +- одинаковы и ухудшать их настолько явным образом точно не будут и в этом смысле ISA сейчас несёт малую роль
При увеличении количества регистров до 256 на указание номера каждого необходим 1 байт.
Кстати, а вы знаете, что в нынешних процессорах физических регистров уже больше этого?
(В Sunny Cove размер ROB=352: https://en.wikichip.org/wiki/intel/microarchitectures/sunny_cove )
Поздравляю, вы изобрели хреновенький VLIW. Почитайте про его недостатки, и почему не взлетело. Ну а я просто пару пунктов:
Почему бы не пойти дальше и не оставить только одну команду, а операцию по подготовке данных оставим процессору. Он в железе это сможет реализовать быстрее и энергоэффективнее на несколько порядков. Вы думаете он там целый такт умножает число на 8 чтобы исполнить режим адресации "х*8"? Умножение числа на 8 (<< 3) в железе это вообще просто "проводочки перемапить", вряд ли такое будет хоть как то влиять на критический путь любой команды. Зачастую дополнительное время на исполнение более сложных команд вообще только за счет их размера и получается, а тут все команды гигантские.
А почему 4 субкоманды? И что будем делать когда возникнет нужда увеличить до 8? Программы то под 4 написаны. Сейчас есть такое что от нового cpu автоматически старые программы начинают работать чуть чуть быстрее, даже без поднятия тактовой частоты. А тут так не получится, под новый cpu все программы придется перекомпилировать, плюс как то еще интероп чтобы работал - из программы скомпилированной под 8 вызвать функцию (в другой библиотеке) скомпилированной под 4, и получить результат.
Когда все субкоманды предполагается менеджить программисту, на него перекладывается огромный головняк связанный с тем что данные которые мы уже начали считать для команды которая там будет через несколько операций, могли измениться. И компилятор очень часто не сможет просто доказать что эти два указателя никогда не будут ссылаться на одну область памяти например (чтобы начать вычисления над одним тогда как по второму вот вот произойдет запись). А у языков программирования есть модели памяти и прочие обязательства перед программистом. В такую модель команд будет просто не сделать нормальный (эффективный) компилятор с/с++, он будет просто постоянно вынужден прожигать циклы чтобы обеспечить корректность (завершать запись прежде чем начинать чтения для следующих команд). И опять же, в железе это сделать относительно просто, по крайней мере можно увидеть что мы поломали данные которые уже считали недавно и сбросить конвейер (начать заново), получить замедление в этом конкретном случае (в случае если произошел алиасинг), а в основном случае все будет хорошо запайплайнено.
Повторюсь, это все минусы VLIW архитектуры и причина почему она не взлетела.
Откуда тут реализация? У автора уровень знаний школьника 4 класса в году эдак 86. Автор вообще крайне слабо разбирается в элементарных вещах. А ты хочешь от него реализацию процессора на верилоге или VHDL.
Пусть автор напишет реализацию, прошьет в FPGA и выложит результат. И сразу будет все видно.
Офтипик, но утомила это чушь про то, что идея ничего не стоит. Это говно-идея ничего не стоит, а годная идея стоит ого-го!
Посетила бы меня в 2010 году идея прикупить биткоинов, ух я бы сейчас жил!
Так не пришла в голову идея. Потому и не купил. Пришла бы, точно купил, я примерно в те годы Кийосаки начитался и как раз искал во что бы такое проинвестировать некоторую сумму денег, чтобы оно через 10-20 лет стало стоить дороже.
И откуда нам знать, что сам Александр Бобров изрек сие именно в декабре 2022? )
«В 2 раза увеличить скорость обработки (до 2 операций на ядро в такт процессора)» Вообще-то все современные процессоры уже давно как выполняют несколько операций одновременно. Суперскалярность передаёт вам привет. И тем более, что Intel, что AMD имеет несколько конвейеров (многопоточность aka multithreading или фирменный Intel Hyper Threading).
«Уменьшить сложность процессора в 2 раза» Относительно чего? Если саму систему команд x86-64, то её невозможно упрощать в силу её природы. Если декодер команд, то получите процессор Atom или какой-нибудь древний 80386. Оставьте это дело матёрым разработчикам процессоров. Они знают все тонкости для наращивания производительности.
«Уменьшить энергопотребление в 4 раза (по отношению с той же производительностью текущих процессоров)» Попробуйте поспорить с физикой.
«Уменьшить количество контактов процессора в 10 раз» Чего, &№#%$? Предлагаете отказаться от периферии вообще? Мне, разработчику ПЛИС, видно, что даже 900 контактов микросхемы бывает мало. Потому что значительная часть контактов уходит на питание. Процессоры не исключение. Я и не говорю, что модули ОЗУ сжирают огромное количество контактов.
«Создаст возможность масштабирования путем простого увеличения количества процессоров и блоков памяти» Ну как-то все масштабируют, увеличивают. Но только те, кто реально делает процессоры, прекрасно понимает, что тупое масштабирование может оказаться вредным и приведёт к снижению производительности.
Почитал мельком оставшуюся часть статьи. Большая часть — это бред сивой кобылы. Остальная и так реализована в процессорах и давно работает.
В общем, советую вам изучить материалы по процессорам, в том числе и современным.
Автору статьи я бы посоветовал начать с данной книги:
Если у автора проблемы с английским, то можно данную книгу найти в русском переводе.
Я джва года хочу такой процессор!
А почему нет возможности грабить корованы?
Тут все критикуют статью, но есть тут одна идея, над которой думал ещё лет 15 назад, и вроде ещё ни где не видел реализованной: Это 1) отказаться от кеша (он занимает много места на кристалле и потребляет энергию) и 2) одно ядро будет выполнять много потоков по мере того, как данные будут приходить из памяти. В результате каждый поток будет очень медленным, но количество потоков будет очень большое и канал работы с памятью будет полностью нагруженным, в чём возможно будет выгода. Но это будет довольно специфический процессор далеко не для всех задач, но в чём-то особенный.
Rakesh тоже так думает
идея, над которой думал ещё лет 15 назад, и вроде ещё ни где не видел реализованной
одно ядро будет выполнять много потоков по мере того, как данные будут приходить из памяти
Поздравляю, вы изобрели GPU (а ещё раньше были векторные процессоры)
отказаться от кеша
Чтобы полностью убить всю производительность?
Представьте что 1000 ядер хочет прочитать байтик из внешней памяти одновременно, вместо того чтобы достать его из своей локальной памяти.
(он занимает много места на кристалле и потребляет энергию)
Любой блок занимает место на кристалле и потребляет энергию.
Кэш это не кнопка вкл/выкл.
Путём подбора параметров размер * Ассоциативность * физ. реализация ячейки достигается требуемый баланс.
Ранние GPU имели очень мало кэша (несколько кб на "ядро").
И им хватало (до поры до времени) - десятки / сотни потоков на "ядро" компенсировали латентность памяти, пока не наступила эра GPGPU.
Нет, нет, вы путаете. У GPU, грубо говоря, один поток команд на ядро, который выполняется множеством АЛУ одновременно + магия ветвления. А здесь наоборот, много потоков команд на ядро. И в ядре один детектор команд и один алу и множество контекстов потоков. В этом случае тысячи уже не ядер, а потоков не могут обратиться к памяти одновременно, а только один поток. И пока ожидается ответ памяти, ядро переключается на другой поток. Так понимаю, может пригодиться в специфических задачах, где не нужна большая скорость одного потока, а распараллеленность и низкое потребление.
Любой блок занимает место на кристалле и потребляет энергию.
Только если он работает. В современных процессорах отключаются блоки, которые не активны в данный момент, что позволяет экономить энергию. А кеш используется всегда.
Прямо из Github перепечатываете? xD
Нет, нет, вы путаете. У GPU, грубо говоря, один поток команд на ядро, который выполняется множеством АЛУ одновременно + магия ветвления.
Я ничего не путаю, потому как знаком с GPU не понаслышке. А вот вам стоит разобраться с принципами его работы.
GPU, который вы себе выдумали, не может скрывать латентность памяти.
А чтобы скрыть латентность памяти, каждое ALU (в значении "work-item") выполняет десятки потоков команд, последовательно переключаясь между ними.
К примеру каждый SIMD юнит (32 work-items) в DCU на AMD RDNA обрабатывает до 20 потоков команд одновременно, т.е. до 80 wavefronts на DCU (4xSIMD).
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf
(Стр.9)
"The fetched instructions are deposited into wavefront controllers. Each SIMD has a separate instruction pointer and a 20-entry wavefront controller, for a total of 80 wavefronts per dual compute unit. Wavefronts can be from a different work-group or kernel"
Каждый Wave Controller имеет PC, буфер инструкций и другие связанные параметры (исключения и т.п.)
А кеш используется всегда.
Вы хоть представляете себе сколько потребляет запрос данных из внешнего ОЗУ?
Желание полностью избавиться от кэша (или любой локальной памяти) сравнимо с попыткой снизить вес машины путём снятия с неё колёс.
Ребята, это фарш с Many Task Architecture с моего Github.
И, RDNA не MTA:
Each SIMD has a separate instruction pointer and a 20-entry wavefront controller
не 20-entry simd cache
Кстати, с точки зрения количества объектов и их свойств и отношений нет предмета проще, чем архитектура процессорной техники.
Всем удачи в дальнейших исследованиях моего github
Всем спасибо за конструктивное обсуждение.
Микропроцессоры будущего поколения