Результаты процессоров Эльбрус в geekbench

Кастую знающих схемотехнику в тред. Возьмем комбинационную схему, которая выполняет действие за 10 нс (100 МГц). Если это возможно, разделим действие на 2 или 3 стадии и получим тактовую частоту 300 МГц. Суммарное время выполнения останется 9-11 нс

Если это имеет смысл, если это удобно, конечно стоит бороться за тактовую частоту. Но из моего примера, сказать что 300 МГц лучше чем 100 МГц это глупость полная, надеюсь никто это не подразумевал

Хорошее уточнение - при прочих равных. Но если цикл длится дольше просто потому что неудобно делить его для более высокой тактовой - никакого недостатка тут нет

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

Мне кажется, в Эльбрус кидаются какахами потому что какие то сведения от критиканов могли ускользнуть, но я не осуждаю их

Те кто работают с FPGA не дадут мне соврать, что там даже 100 МГц может дать больше производительность, чем Core i7 частотой 4 ГГц

FPGA не дадут мне соврать, что там даже 100 МГц

Это если на fpga фиксированная реализация конкретной задачи. А если на ней сделать процессор?

никакого недостатка тут нет

Тактовая частота (ТЧ) жизненно необходима для быстрого исполнения длинных цепочек зависимостей. Другими словами, чем ниже ILP, тем важнее ТЧ.

Так же с повышением ТЧ увеличивается кол-во выполняемых операций в единицу времени при примерно одинаковой площади кристалла, что положительно сказывается на соотношении попугаи/площадь. Стоимость экземпляра зависит от площади. Поэтому, без поднятия ТЧ нельзя конкурировать с другими производителями из-за низкого соотношения попугаи/стоимость на рынках не критичных к энергопотреблению процессора.

Конечные автоматы это фиксированная задача? Считаю никакие принципы не меняются, схемотехника имеет свои принципы и пределы

Я к тому, что выдаёшь за аргумент сравнение прямой реализации задачи на fpga с программной на процессоре. Это не является аргументом, тк вся разница в производительности тут идёт из того факта, что одно - процессор, а второе это фиксированная логика.

Понимаю, заметил к чему ты клонишь, что курица - не птица

Это в общем то мне совсем не интересно.

Но спасибо за заботу:)

Это в общем то мне совсем не интересно.

Тогда зачем ты пишешь в тему про «Это в общем то мне совсем не интересно»?

Мне не интересно что какая-то хрень super simd в Vliw2 так как весь Vliw это simd с рюшечками

Я не знаю даже какое это имеет отношение к теме.

Я не знаю даже какое это имеет отношение к теме.

Вот и я не понимаю. Цитирую тебя.

У. Vliw есть проблемы из-за которых их перестали использовать даже в видеокартах

Зачем ты это пишешь, если «Это в общем то мне совсем не интересно»?

Мне не интересно что какая-то хрень super simd в Vliw2 так как весь Vliw это simd с рюшечками

Я не знаю даже какое это имеет отношение к теме.

Также не понятно что вам не понятно

Я не знаю даже какое это имеет отношение к теме.

super-SIMD/VLIW2 опровергает твоё утверждение.

У. Vliw есть проблемы из-за которых их перестали использовать даже в видеокартах

Тебе есть что возразить или «Это в общем то мне совсем не интересно»?

super-SIMD/VLIW2

Как?

Они уже используются в живых картах?

Они уже используются в живых картах?

Xbox Series X и PlayStation 5.

А? У тебя программируемый процессор == fpga, или что?

Я про схемотехнику, про фундаментальные принципы

Т.е. нет

Ок

А где написано что там VLIW будет?

Делаем Эльбрус популярным на ютубе: https://youtu.be/7LQgLl_89Po

Т.е. нет

Обе консоли поступят в продажу в 4 квартале этого года. Navi 2X тоже обещают выпустить до конца года.

А где написано что там VLIW будет?

Ты не поверишь. В моём первом сообщении тебе. В патенте всё написано. Типичный срок разработки новой микроархитектуры составляет 3-4 года. Eсли посмотришь на даты в патенте, то всё встанет на свои места. Больше подробностей будет после релиза Navi 2X или консолей, но кое-что можно урвать со слайдов.

https://images.anandtech.com/doci/15591/Navi2x_PPW.png

Microarchitecture Innovation

Improve Perf-per-Clock (IPC)

IPC можно поднять двумя способами, суперскалярность или VLIW. Так как речь про GPU, то суперскалярность сразу отпадает.

В Эльбрус-12/16 обещают завезти суперскалярные штуки, возможно сперва скромные какие-то, самые актуальные оптимизации будут. Получается, зря скулили и кидались какахами

Патенты иногда делают просто так и затем не применяют в продукте.

Т.е. доказательств и ссылки что там Vliw у вас нет.

Ок.

Т.е. доказательств и ссылки что там Vliw у вас нет.

Кто о чём, а вшивый о бане.

Мы обсуждали АМД.

Я ни в кого не бросался.

Более того я ни разу не критиковал Эльбрус

У вас я спрашивал почему не МИПС. Главные проблемы VLIW, которые видит такой ламер по ЦПУ, как я: Оптимизировать нужно отдельно для каждой модели и версии отдельно Нормально в JIT не оптимизировать а это 99% энтерпрайза.

Вы как всегда уходите от ответа.

Ссылка есть что там Vliw?

Вы как всегда уходите от ответа.

А ты как всегда не читаешь, что тебе пишут. Ибо «Это в общем то мне совсем не интересно».

Ссылка есть что там Vliw?

Я уже написал, что подробности будут после релиза. AMD публикует ISA на свои GPU. Довольствуйся тем, что сейчас есть, а это патент и этот текст на слайде.

Improve Perf-per-Clock (IPC)

Я уже объяснил, что это значит.

У. Vliw есть проблемы из-за которых их перестали использовать даже в видеокартах

Повторю, не всё так однозначно, так как использование VLIW в GPU продолжается и характеризуется как Innovation.

Я уже написал, что подробности будут после релиза.

Вы как всегда уходите от ответа.

Ссылка есть что там Vliw?

VLIW в GPU продолжается и характеризуется как Innovation.

В Цпу тоже было Innovation пока не выкинули

Ссылка есть что там Vliw?

Давай я тебе в 3 раз повторю. Релиз будет в 4 квартале этого года, а там и будут ссылки.

Лет 10 назад меня поразила производительность одного сигнального процессора на базе VLIW (американский DSP), он на 200 МГц уделывал Core 2 Duo на 2+ Ггц. Причем к такому выводу пришел не я, а куда более опытные программисты DSP в конторе где я работал

На такой задаче как FFT мне казалось там есть встроенный аппаратный блок для этой задаче, оказалось там просто обычный VLIW был

Вот сижу и думаю, как же так, мне на ЛОРе говорят что чем больше МГц тем лучше, а оказалось иначе, что даже 10 кратное отставание по частоте может быть «недостаточным для слива»

Всё как я говорил в предыдущих постах, но никакого «нарушения законов физики» нет, просто это обычная… схемотехника

Т.е. доказательств и ссылки что там Vliw у вас нет.

Читд

Вы зачем мне все это рассказываете?

Если мы о видеокартах АМД, то «волшебный Vliw» почему-то отстает от карт Нвидии уже много лет работая на те-же частотах

А то, что ДСП заточены под одну задачу обгоняет на ней процессор это нормально.

Вы на нем ГЦЦ соберите, сравним время сборки с и386. Думаете ДСП догонит или вообще сойдет с дистанции?

Или вы намекаете что Vliw только в ДСП нормально работает?

Но из моего примера, сказать что 300 МГц лучше чем 100 МГц это глупость полная

Нет, в твоём примере как раз 300МГц - это в три раза лучше, чем 100. Ты описал конвейер. Задержка (latency) осталась прежней, а пропускная способность (throughput) увеличилась втрое (потому что следующую порцию данных можно пихать через 3нс, а не через 10нс).

Если мы о видеокартах АМД, то «волшебный Vliw» почему-то отстает от карт Нвидии уже много лет работая на те-же частотах

numas13 трижды повторил, неужели надо 4? )))

Если мы о видеокартах АМД, то «волшебный Vliw» почему-то отстает от карт Нвидии уже много лет работая на те-же частотах

VLIW закончился на HD6000. В 2009 я помню выбирал между HD5750 и GTX450, по fps они не то что не отсевали а были впереди nvidia. Но драйвер fglrx под linux был полный мусор. Современные GCN это вроде RISC SIMD.

С Nvidia тоже всё не однозначно, но менее понятно чем с AMD, так как у них всё секретное. В Turing сделали следующее:

Turing adds a second parallel execution unit next to every CUDA core that executes these instructions in parallel with floating point math.

Как это сделано не знаю. Скорее всего не суперскаляр (все же помнят печь geforce 400?), а планирование потоков, но кто знает, вдруг тоже VLIW? Вот будет умора. xD

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

У вас есть ссылка в которой говорится что АМД выпустит карту на Vliw?

Предыдущий аналитик слился.

Теперь ваша очередь?

Не о том срач, видеокарты «мне общем то не совсем интересно» (с), интересны теоретические основания невозможности VLIW догнать результаты Intel. По мне так это одно и тоже, просто решено иначе. И не более того

Нужны теоретические основания, сравнимые с «невозможностью вечного двигателя»

Мне не совсем интересны патенты о которых писал слившийся аналитик.

Обсуждение VLIW как вы могли догадаться мне интересно.

Нужны теоретические основания, сравнимые с «невозможностью вечного двигателя»

Я несколько раз перечислил почему Vliw будет отставать от cisc и risc по моему ламерскому мнению и ни одного аргумента против я не увидел.

В видеоквртах теоретически можно обойти многие проблемы так как ни Java ни чего подобного для них не требуется.

Почитал ваш спор. Вы оба не правы. Высокая тактовая конечно лучше при прочих равных, но cisc/risc и vliw - это не равные условия, по частоте их сравнивать смысла нет.

То, что vliw dsp быстрее core2 вполне предсказуемо - обработка однообразного потока данных хорошо ложится на vliw.

Так что vliw вполне могут быть быстрее cisc, при определённых условиях. Если получится сделать компилятор, который будет создавать эти условия, будет круто.

Я несколько раз перечислил почему Vliw будет отставать от cisc и risc по моему ламерскому мнению и ни одного аргумента против я не увидел.

Всё не так однозначно и зависит от разных факторов. Так как мы говорим про специфичное применение GPU (игровые консоли), то ставка на SIMD RISC оказывает медвежью услугу для AMD, т.к. консоли используют GPU для графических задач, в которых большой ILP, а SIMD RISC расчитан на ILP 1. GPU необходимо хранить контекст для сотней тысяч запущенных потоков. Но т.к. в SIMD RISC условное время N выполнения потока очень велико, то площадь/энергия тратиться на хранение их контекста. Эту проблему можно решить увеличив IPC. Для определённых задач можно добавить дополнительное ALU с ограниченным, но часто используемым, функционалом. Тем самым сократить время N в два раза в идеальных условиях. Что сделает возможным сократить траты на хранение контекста тоже в два раза. Другими словами, обменять площадь ранее использованную для хранения (SRAM) на вычисления (ALU). Можно пойти ещё дальше и улучшить планировщик. Сделать так, что он запускал 2 потока по 1 инструкции в широкой команде на этих двух ALU, тем самым дополнительно закрыть пустышки в коде.

ATI/AMD ранее использовала VLIW в своих GPU не просто так, это давало огромную выгоду в производительности на малой площади. В 2007-2008 году, после появления CUDA (Initial release June 23, 2007), в AMD тоже решили пойти по этому пути и начали делать GCN (launched on January 9, 2012) для GPGPU вычислений. Как мы уже знаем, у AMD не вышло занят свою долю. Nvidia практически монополист на этом рынке.

Мне просто интересно, что может CISC на лету, что не может VLIW на этапе компиляции. Допускаю что тут есть серьезная проблема, которую в треде никто не сформулировал

Мне просто интересно, что может CISC на лету, что не может VLIW на этапе компиляции.

Если под CISC ты подразумеваешь OoOE, то динамически планировать операции с переменной задержкой в рамках небольшого окна (skylake 97 queue и 224 ROB для микропераций) и кучей нюансов (PRF, Load Buffer, Store Buffer). Статическое планирование не всегда может использовать спекулятивное исполнение. К тому же спекулятивный код снижает плотность кода, увеличивает нагрузку на регистры, ALU и подсистему памяти.

Важно понимать одно, не существует универсального решения. CISC/RISC/VLIW, IO/OoOE — обладают как положительным, так и отрицательными качествами. В зависимости от требований/условий разработчики выбирают то, что лучше подходит для решения поставленной задачи.

Взять тот же Эльбрус. Разработка сложной аппаратуры дороже разработки сложного компилятора. У МЦСТ/ИНЭУМ нет такого финансирования/кадров, чтобы разрабатывать производительный OoOE. Представьте OoOE от них с частотой ещё ниже чем у Эльбрусов и большими сроками разработки.

что может CISC на лету, что не может VLIW на этапе компиляции.

Если более обще: что можно сделать в рантайме, чего нельзя на этапе компиляции? Очевидно - нельзя получить статистику исполнения кода (в частности, переходов).

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