Эльбрусы снова делают

Даже умножение матриц 20x100, 100x20, или 200000x200000 требует трёх разных алгоритмов и поэтому три независимые версии кода.

Разные версии кода – они для любого процессора разные. Мы обсуждаем ситуацию, когда код (сишный) один и тот же, но суперскаляр за счёт знания данных может сделать оптимизацию лучше, чем компилятор.

Что-то вроде такого: https://habr.com/ru/articles/490458/

Он и должен быть выше, но вам не следует ориентироваться на Интел и сравнивать с её продуктами. Вам нужно сравнивать с тем, что можно сделать в идеальном сценарии с тем, что делает компилятор автоматически.

А Интел - это для маркетологов. Для этого берёте SPEC, тюните вручную до посинения, потом обучаете компилятор генерировать такой код. Вместо «SPEC” подставьте ваш любимый набор тестов, который пользуется уважением ваших потенциальных заказчиков.

«Как жаль, что все, кто знает, как управлять страной, уже работают таксистами и парикмахерами».

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

Лично мне, сразу видится стратегическое - безопасность

Проблема не в том, что они делают процессор, а в том, что архитектура для него неподходящая. ТБВ можно перенести на спарки от МЦСТ, и сидеть довольными - тот же результат будет достигнут без необходимости пердолить мертворожденный VLIW общего назначения.

Будущее уже наступило, и прокачанные ИИ с легкостью взламывают сверхзащищенные структуры государств:

Побольше слушай маркетинговый бред и выдумки политиканов. Реальность в том, что ИИ находит некоторое подмножество лежащих на поверхности багов, которых оказалось достаточно много. Всё.

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

Он и должен быть выше, но вам не следует ориентироваться на Интел и сравнивать с её продуктами. Вам нужно сравнивать с тем, что можно сделать в идеальном сценарии с тем, что делает компилятор автоматически.

Как измерить идеальное состояние?

Для этого берёте SPEC, тюните вручную до посинения, потом обучаете компилятор генерировать такой код.

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

Код программы от входных данных почти всегда не зависит.

Зато путь исполнения зависит.

Кстати, тесты с предсказателем переходов показали, что он даёт выигрыш почти на всех задачах около 2%.

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

Чем они сложнее и больше?

Почитай спецификации docx и odt.

https://habr.com/ru/articles/575302/

По ссылки манипуляции и подлог, о чем есть превосходный комментарий

Ещё раз: весь мировой опыт процессоростроения говорит о том, что VLIW для процессоров общего назначения - это тупик. И это совпадает с автором статей с критикой эльбруса, совпадает с мнением мировых специалистов по CS и осестроению, и даже с мнением Бабаяна, который этот эльбрус изобрел. Ты же просто затыкаешь уши продолжаешь отрицать объективную реальность, потому что это наше, а значит оно не пахнет; у нас свой особый путь, и так далее. А все, кто говорят - враги народа.

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

Или ты про то, что если дать совсем говнокод, то должно быть падение производительности в 3 раза как на Интеле, а не в 15 как на Эльбрусе с lcc-1.25?

любой Эльбрус на DDR3-1600 должен обеспечивать 50GB/s/chip

https://www.altlinux.org/Эльбрус-16C

Пропускная способность шины памяти до 200 Гбайт/с

Ну на бумаге...

Почитай спецификации docx и odt.

Там обычный zip и xml. Ничего такого, что требовало бы миллиардов операций в секунду для показа пользователю.

Ещё раз: весь мировой опыт процессоростроения говорит о том, что VLIW для процессоров общего назначения - это тупик.

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

Ты же просто затыкаешь уши продолжаешь отрицать объективную реальность, потому что это наше, а значит оно не пахнет; у нас свой особый путь, и так далее.

Нет. Я ещё со времён Трансметы считаю, что этот путь верный.

Там обычный zip и xml. Ничего такого, что требовало бы миллиардов операций в секунду для показа пользователю.

На ноль поделил.

В середине 20 века

Аналогия не является доказательством. И мне не интересно устраивать с тобой демагогию.

Нет. Я ещё со времён Трансметы считаю, что этот путь верный.

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

Но вот возможно ли разогнать Эльбрус до 4,8ГГц хотя бы теоретически — пока вопрос открытый.

P4 на 3ГГц появился в 2002м и был на 130 нм. Эльбрус на куда более совершенном техпроцессе имеет вполовину меньшие частоты. Очевидно, для 4ГГц он слишком жирён, и скорее всего _вне_ зависимости от техпроцесса.

Эльбрус на куда более совершенном техпроцессе имеет вполовину меньшие частоты. Очевидно, для 4ГГц он слишком жирён, и скорее всего вне зависимости от техпроцесса.

P4 у Интела примерно 8-й процессор. Эльбрус практически первый.

На 3мкм Z80 был 20МГц, а Интел тогда не более 10МГц. Тоже надо было делать глубокие выводы о тупиковости 8086?

Это не имеет прямого отношения к разработке процессора общего назначения.

RISC-V там не обязан быть, можно хоть PDP-11.

Тоже надо было делать глубокие выводы о тупиковости 8086?

Да многие и делали, в т.ч. и в самом Интеле.

предсказатор говно потому что компилятор говно. мне тот же gcc только с помощью пинков по жёппе удалось заставить использовать cmov вместо ветвления. отчасти потому что дегенераты из штеуда всегда производят чтение памяти даже если условие не выполняется. приходится делать

mov rax, &dummy_variable
cmov rax, регистр с адресом
mov ..., [rax]

аналогично с записью.

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

я тут как раз сижу и процессор придумываю, поэтому что-то имею сказать.

у пня4 ну оооочень специфический и длинный конвейер, сделанный руками. делали его куча грамотных людей, а в МЦСТ работают с теми с кем могут. поэтому многие решения ну вот такие какие есть.

плюс накладываются видимо ограничения библиотеки элементов, потому что наши пишут на верилоге. или на систем верилоге. а тут загвоздка вот какая.

Тот же сумматор на 64 бита на верилоге нормально не написать. Вот тут схема:

https://ee.usc.edu/~redekopp/ee457/slides/EE457Unit2b_FastAdders.pdf

С andn на 5 входов, пусть каждый из них делает ~2 FO4 задержки, нам надо сходит в первый слой(4), оттуда во второй(8), в третий(12), оттуда во второй(16), в первый(20), и наконец выходные два гейта: 24 FO4. На 28нм FO4 ~= 25пс. то есть цикл сумматора 625пс+потери, что автоматом дает нам частоту не выше 1400 Мгц.

Чтоб идти дальше нужно использовать домино-логику. https://digitalvlsidesign.wordpress.com/wp-content/uploads/2019/01/chapter5-dynamic-logic-circuits.pdf

там на странице 46 (385 в книге) нарисован неполный блок ускорения переноса. нет сигналов P и G, P делается тривиально, G надо подумать. плюс надо путь сброса тока в обход комбинаторной логики добавить при падении доминошки. ~17 FO4, т.е. 450пс, 2 Ггц есть.

но! на верилоге это или не пишется, или пишется с лютой болью практически как на ассемблере графическую программу делать. А кроме верилога никто вообще не может в домино-логику.

Дальше надо делить слогатор на стадии по 16 бит например. У пня4 так и сделано из-за чего

add eax, ebx
add eax, ecx
shl eax, 5

идут без задержки, потому что на каждой стадии свой перенос. а вот

add eax, ebx
shr eax, 5

даст остановку конвейера потому что сдвиг из непросчитанных битов

У нас попросту нет ни инструментов для такой работы ни специалистов которые могут на себя такое взвалить.

я тут как раз сижу и процессор придумываю

Очень интересно, сам тоже думаю, но с другой стороны, llvm пытаюсь изучать, для своей ISA.
У тебя ISA своя?

Тот же сумматор на 64 бита

По словам Gemini на Kogge-Stone - «~8 уровней логики 10.0 – 12.8 FO4»

даст остановку конвейера

«Автор утверждения прав в том, что на Pentium 4 связка ADD -> Сдвиг вызывала тормоза. Но он ошибся в физике процесса: конвейер останавливался не из-за «непросчитанных битов переноса», а из-за того, что блок сдвига в Pentium 4 был архитектурно «медленным» (работал на обычной частоте), а сумматор — «быстрым» (работал на удвоенной).»

Да и сегодня такой код везде выполнится без проблем.

уровень логики != FO4. только очень простые схемы дают небольшой прирост logical effort относительно увеличения количества входов.

опять же, что такое «уровень логики». на входе у тебя and и хor для получения побитовых сигналов P и G первого уровня. P следующего уровня это p0p1p2p3, G=g3+p3g2+p3p2g1+p3p2p1*g0. тут тоже 2 уровня. уровней 3: 4 бита, 16бит и 64 бита. Итого только по пути «вверх» у на 1+3 * 2=7 операций.

На обратном пути считаем частные переносы. Это формула типа g3+p3g2+p3p2g1+p3p2p1g1+p3p2p1p0c0. Тут как минимум две операции. Это 2*2+выходные 2 ключа=6. Итого 7+6=13. Но эти операции != 1 инвертору, у них побольше 1 будет.

Врёт гемини короче. Вот поэтому на верилоге подобную дрянь и не написать. А наши пишут, стараются. И китайцы стараются. Вон сделали проц opensource, 800мгц на 28нм. Затем поднапряглись, догнали до 2Ггц. Дальше всё, жопа.

Поскольку память сегодня является главным узким местом, обычно производители процессоров максимизируют пропускную способность и минимизируют задержки к памяти как высший приоритет. Всё остальное по остаточному принципу. Поэтому 95% от того, что может по спекам выжать память это норма. У Эльбруса какой-то косяк. Может кэши не могут поддерживать достаточную параллельность (она определяется задержкой памяти и скоростью процессора генерировать операции с памятью), может запросы отправляются не по тому назначению для разрешения адреса, может NOC недостаточно быстрая), да я много могу накидать идей почему это может происходить. Разработчики должны сесть и провести грамотный анализ …

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

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

А ты пробовал бенчмарк сделать с cmov и без него, с ветвлениями от компилятора?

С бенчмарками для таких ситуаций всё плохо, потому что очень сильно зависят от данных.

Вот наглядно: https://habr.com/ru/articles/490458/

CMOV: 1190 ms
переход с однородными данными: 837 ms
переход с случайными данными: 1662 ms

А для Эльбруса предсказатель меньше помогает, потому что в нём есть операция подготовки перехода. Поэтому единственная ситуация, когда он действительно хорошо помогает, это когда между получением адреса перехода и переходом нельзя сделать ничего полезного. Что-то вроде

f = get_f(a, b, c);
f();

Тогда с предсказателем при повторном вызове будет заранее прочитан кусок памяти по адресу предыдущего результата get_f.

Там комментарии сильно потерли, суть полностью потерялась. Я говорил что работы в любых областях это замечательно, но началась знакомая история про «всё своё» и прочую независимость и величие.

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

Нужно ли уточнить почему такие изделия будут абсолютно неконкурентоспособными в финансовом плане? Я действительно не понимаю смысл отверточной сборки из зарубежных комплектующих, если никакой технологической независимости это вообще не дает, даже испольхуемое оборудование импортозависимо на 101%, изделия на выходе получаются заметно хуже и оооочень сильно дороже.

да пробовал. для этого надо всего-то сказать гцацу что у меня амуде-процессор. причем какой-то кокретный, где вес cmov ниже jmp. выигрыш есть, но есть нюансы. в частности гцаца не будет использовать cmov там где нужно условно работать с памятью изза того что интеловские свинопотамы сделали так, что «If the source operand is a memory operand, then regardless of the condition, the memory operand is read. This indicates that if the memory read operation would generate a fault (#GP or #PG), then even though the condition may be false, the fault occurs.»

на cmov можно сделать условную запись и чтение памяти с опорой на мусорную переменную в стеке(или пару - 0 на чтение и хз что на запись чтоб баги не ловить). тогда будет 3 инструкции на чтение(mov a,&dummy,cmov a,b,cmov a,[a]) и 3 на запись. но кто это делать будет? я в эту клоаку нырять не хочу, я ж не петрович

да нифига. замедился как раз выхлоп LLVM начиненный jmpами.

Что же касается LLVM, то тут какая-то лапша из переходов, которую полностью приводить не буду.

кодогенерация llvm это такая задница, что я вот делая свой проц тоже ведь хотел сразу сделать бекэнд чтоб модельку проверять но понял что там повеситься можно. 21й век, космические корабли бороздят просторы большого театра, а у них статические переменные повсюду. Это кстати пример того, как обдолбанные парадигмами и ООПом программисты превращают код в фарш в угоду идеологии.

Если не так, то никак. Боинг и илон маск тоже не сразу строился, это все военные вливания и лишь через время от них ответвлялась гражданская продукция. В РФ это все просто отягощено минпромторгом, где можно наверно каждого второго расстреливать за африканскую коррупцию.

Но вот так и надо.

Если не так, то никак.

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

каждого второго расстреливать за африканскую коррупцию

да вы однако оптимист:)

Понятно, на практике неоднозначно всё с cmov.