Последние месяцы ознаменовались бурными баталиями в отечественной индустрии разработки микроэлектроники и причастных. Государство, наконец-то пристально обратив своё око на данную, мягко скажем крайне проблемную отрасль, посулило крупные инвестиции на её развитие, в первую очередь на разработку мозга любой вычислительной техники - процессора. Прения по поводу того, как правильно потратить выделенные средства, из тишины министерских кабинетов выплеснулись наружу и дошли до прессы. Не вдаваясь в политические моменты, всегда присущие такого рода дебатам, хотелось бы сконцентрироваться на технической стороне вопроса и обрисовать позицию, почему ставка на легендарный микропроцессор Эльбрус - это тупик для развития отечественного процессоростроения.
Российское процессоростроение, в силу понятной специфики зарождения и функционирования последних лет в основном на военных и окологосударственных заказах, критически страдает от отсутствия сколь либо открытой и доступной общественности, и при этом профессиональной дискуссии. Безусловным прорывом в данном вопросе можно считать проведение Elbrus Tech Day:
Жаль, что это происходит с примерно 15-ти летним опозданием, но лучше поздно, чем никогда. Результатом такой закрытости является нагромождение мифов вокруг Эльбруса, где антагонисты утверждают, что Эльбрус это просто старые процессоры Итаниум с переклеенными шильдиками, а сторонники рассказывают о супер архитектуре и гениальных компиляторщиках, которых не смог переманить Интел, благодаря чему Эльбрус имеет ни с чем не сравнимую производительность. Правда лежит в параллельной реальности, поэтому сначала несколько тезисов в качестве ликбеза для широкой публики, не столь глубоко знакомой с темой процессоров.
Микропроцессоры архитектуры Эльбрус (e2k) - это абсолютно аутентичная разработка компании МЦСТ, основанная на предыдущем опыте создания линейки Эльбрусов 1/2/3 ещё в СССР.
Хотя архитектура Эльбрус является достаточно типичной VLIW-архитектурой (процессоров на базе которой было построено много, самые известные из которых это Intel Itanium и Transmeta), у неё есть некоторые особенности, которые нельзя обобщать на все VLIW процессоры. Но для простоты повествования в рамках статьи я буду говорить о VLIW именно в контексте Эльбрусовской реализации.
Компания МЦСТ также разрабатывает линейку процессоров с архитектурой Sparc V9. В названии данные процессоры также имеют слово Эльбрус, что часто вызывает путаницу. Все дальнейшие рассуждения относятся именно к VLIW-архитектуре Эльбрус (e2k), а не к Sparc V9.
Самые популярные в мире процессоры на данный момент от Intel и Arm - это представители CISC и RISC архитектуры.
Создание процессора можно в первом приближении разделить на разработку процессора и производство. Компания, которая только разрабатывает процессор, но для производства использует чужие мощности, называется "фаблесс". МЦСТ - это фаблесс разработчик процессоров. Как и абсолютное большинство дизайн-центров в мире, включая Apple, Qualcomm, Nvidia, HiSilicon и т.д. и т.п.
В России на данный момент нет заводов по производству процессоров, которые пригодны для производства сколь-либо современных процессоров топ-уровня. Кому интересно актуальное состояние данной отрасли, можно почитать здесь. Дальше все претензии и обсуждения на тему "а производят-то на Тайване!" здесь не принимаются. Статья касается только вопроса разработки процессоров.
Сама по себе разработка высокопроизводительного процессора любой архитектуры - крайне сложная инженерная задача
При обсуждении микропроцессоров крайне важно понимать различие между Архитектурой и Микроархитектурой. Говоря простыми словами, Архитектура процессора - это набор команд, который предоставляет аппаратура для использования софтом, иначе говоря интерфейс между миром ПО и миром железа. Микроархитектура - это то, как процессор устроен внутри, т.е. каким образом он реализует предоставленные Архитектурой интерфейсы. В современных процессорах именно микроархитектура является ключевым фактором достижения производительности. Именно из-за неё разные процессоры линейки x86 или Arm, реализующие одинаковую архитектуру, при схожих параметрах тактовой частоты могут в разы отличаться по производительности.
Так в чём же проблема Эльбруса? Если не углубляться в кучу технических и не очень нюансов, их две основных:
Собственная архитектура
Интересно, что руководство МЦСТ всячески пиарит данный пункт, выставляя его в качестве преимущества. Парадокс в том, что это большой недостаток. Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям. А это колоссальные затраты, тем более для VLIW-архитектуры (об этом ниже). В МЦСТ это прекрасно понимают (несмотря на публичные заявления о собственной архитектуре как о достоинстве) и именно поэтому в Эльбрусе на аппаратном уровне сделана поддержка бинарной трансляции из x86, что означает потенциальную возможность запускать привычные пользователю программы без какого-либо портирования. Но это стоит транзисторов, перформанса и всё равно имеет много ограничений для применения в реальности. В итоге можно сказать, что создание процессора с собственной архитектурой должно иметь крайне веские обоснования, иначе это получение колоссального геморроя на ровном месте. Да, к сожалению мы не можем делать аналог x86. Да, с лицензированием Arm есть потенциальные угрозы. Но любая лицензионно чистая открытая RISC/CISC архитектура здесь будет лучше, потому что увеличивает коммьюнити, занимающееся портированием софта.
VLIW-архитектура
Главная техническая проблема. Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением.
Тут требуется немного технического погружения. Основная идея VLIW заключается в том, что компилятор должен создать максимально оптимальный код, который железо просто исполнит, неукоснительно следуя тому, как компилятор создал широкие команды. Широкими команды как раз называются потому, что компилятор помечает операции, которые можно исполнить независимо, и планирует их в одну команду, которую процессор может исполнить за такт. Например, вот так:
{
addd,0 %r0, %r5, %r5
addd,1 %r0, %r6, %r6
addd,2 %r0, %r7, %r7
}В то же время процессоры RISC/CISC архитектуры логически получают инструкции как бы по одной, но само железо может в процессе исполнения проанализировать поток инструкций и перемешать их, если это возможно.
Идея VLIW на первый взгляд выглядит красиво, но она разбивается о реальность. В реальной жизни невозможно статически проанализировать код настолько, чтобы максимально плотно упаковать широкие команды. Пришедший указатель или сложная работа с памятью - и вы не можете спланировать Load выше операции Store (и наоборот). Если в горячем цикле есть вызов функции - его надо обязательно заинлайнить, иначе мимо него нельзя будет ничего поднять вверх и тем более применить критически важную оптимизацию конвейеризации цикла. Но при компиляции без профиля установить какие циклы горячие невозможно. Да и наличие профиля плохо помогает в случае динамической линковки, динамических вызовов, отсутствия ярко выраженного горячего кода. Опять-таки, сколь-либо сложное управление в цикле препятствует его накрутке.
В то же время классические RISC/CISC архитектуры с OoO автоматически оптимизируют и конвейеризируют любой исполняемый код. И хотя это стоит определённых транзисторов и мощности, на выходе такой подход оказывается более эффективным.
Например, чтобы получить некоторую интуицию проблемы с инлайном, не погружаясь сильно глубоко в сложные технические детали, давайте рассмотрим простейший синтетический код:
int get_inc_val () { return 3; };
...
int a=0;
while (a < 10000)
{
a+=get_inc_val();
}
...Архитектура Эльбрус крайне плохо исполняет код, если в нём появляются не заинлайненные вызовы функций. В таком случае производительность может падать на порядок.
Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт(P.S. после публикации статьи проверка на реальном коде показала 3 такта), не отличаясь принципиально от случая, если инлайн сработал.
В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов. Конкретно в данном случае компилятор lcc с высокой вероятностью данную функцию заинлайнит, если будет видеть определение функции ( что далеко не всегда применимо в сложных проектах). Но минимальное усложнение кода, например, путем добавления бОльшего числа команд в функцию, легко сломает логику работы инлайна в реальной жизни.
Чтобы хоть как-то решать возникающие проблемы в VLIW архитектуру приходится добавлять различные, иногда достаточно нетривиальные архитектурные фичи. Нужно иметь много архитектурных регистров, т.к. требуется хранить большое количество промежуточных результатов вычислений. Как следствие, аппаратура получается сложной (а от этого как раз хотели уйти) и в итоге падают частоты, на которых VLIW-процессор может работатать. Вот сравнение самых топовых решений процессоров на базе VLIW-архитектур от Intel и МЦСТ с их RISC/CISC аналогами:
CPU model |
Year |
Architecture |
nm |
Freq, GHz |
Cores |
TDP,W |
transistors, billion |
Intel Itanium Processor 9760 |
2017 |
VLIW |
32 |
2,66 |
8(16) |
170 |
3,1 |
Intel Xeon Processor E5-2687W |
2012 |
CISC |
32 |
3,1-3,8 |
8(16) |
150 |
2,27 |
Intel Itanium Processor 9750 |
2017 |
VLIW |
32 |
2,53 |
4(8) |
170 |
? |
Intel Xeon Processor E3-1290 |
2011 |
CISC |
32 |
3,6-4,0 |
4(8) |
95 |
1,16 |
Эльбрус-8СВ |
2020 |
VLIW |
28 |
1,5 |
8 |
90 |
3,5 |
Эльбрус-R2000 |
2019 |
RISC |
28 |
2,0 |
8 |
36 |
0,5 |
Как видно, VLIW-процессоры на тех же нанометрах, имеют меньшие тактовые частоты, при этом имеют более высокое тепловыделение и больше транзисторов.
В итоге VLIW процессоры проигрывают не только по микроархитектурной скорости в пересчёте на Герцы, но и по самим частотам. Кстати, данная таблица чётко демонстрирует, что декларируемая "энергоэффективность VLIW" - это миф.
Собственно говоря, именно с вышеуказанными проблемами связаны те многочисленные истории, когда пользователи Эльбруса, получив возможность скомпилировать и запустить своё ПО на данном железе, часто с первого раза получают удручающие результаты. Потому что если на небольших бенчмарках или тем более Spec2006/2017 (которые вылизывали 20+ лет) компилятор худо-бедно справляется и может сгенерировать близкий к оптимальному код, то на реальных проектах он уже не справляется, а т.к. аппаратура тут подстраховать не может, то производительность падает в разы. И начинается долгая история про то "как правильно переписать код проекта, чтобы lcc смог скомпилировать оптимальный код".
Кстати, именно с этой проблемой связана достаточно странная политика МЦСТ, когда получить Эльбрус можно только написав официальный запрос на имя генерального директора. Ведь казалось бы, если вы хотите продавать свои процессоры, надо их максимально пиарить и первые партии раздавать чуть ли не бесплатно. А тут такие бюрократические препоны. Дело в том, что руководство МЦСТ в общем-то прекрасно понимает недостатки Эльбруса и максимально пытается избежать негативной огласки. Поэтому оно старается фильтровать потенциальных клиентов, чтобы в случае возникновения перформанс проблем привлечь своих специалистов, которые могут разобраться в проблемах и с помощью правильных опций, допилок компилятора или переписывания горячего кода "под Эльбрус" улучшить производительность пользовательских задач. Но масштабируемость такого подхода, думаю, всем понятна.
Отсюда следует ещё один, крайне важный вывод - процессор на базе VLIW архитектуры существенно более требователен к квалификации программистов, компилирующих программы под данную платформу. Т.е. это своеобразный дополнительный налог, который взымает архитектура с разработчиков, и чем она шире используется, тем этот налог выше. Что тоже не добавляет плюсов Эльбрусу.
Вот пример далеко не самой сложной ШК из Эльбруса:
{
loop_mode
alc alcf=1, alct=1
abn abnf=1, abnt=1
ct %ctpr1 ? %NOT_LOOP_END
muls,0,sm %g17, %b[10], %b[1]
addd,1,sm 0x4, %b[15], %b[13]
adds,2,sm %b[8], 0x3, %g17
ldw,3,sm %r0, %b[17], %b[0] ? %pcnt12
adds,4,sm %b[22], %b[13], %g16
staaw,5 %g16, %aad0[ %aasti1 ]
incr,5 %aaincr0
}Разобраться в логике данного кода непросто, даже имея опыт и необходимую квалификацию. А теперь представьте, это будут делать программисты в мире, где простой x86-ой ассемблер хоть как-то понимают хорошо если 1 из 100. А тут надо будет не только разобраться в коде, но ещё и понять, а что же компилятор "сделал не так" и что исправить в коде, чтобы решить проблему.
Собственно, как следствия, вполне понятны вытекающие из вышесказанного дальнейшие недостатки VLIW :
"Жирный" код, ведущий к повышенным кэш-миссам кода
Дополнительная нагрузка на кэш данных вследствие спекулятивного исполнения кода
Фактическая непереносимость кода между версиями процессора (если были какие-то изменения в архитектуре, то надо перекомпилировать код, чтобы получить преимущества новой версии)
Сложность развития микроархитектуры, т.к. в случае VLIW это почти всегда влечёт за собой изменение в архитектуре
Сложность оптимизации кода, сложность обработки прерываний и т.д.
Резюмируя - процессорная платформа, которая претендует стать массовой и конкуретной на рынке десктопных и серверных процессоров, не может быть VLIW архитектурой, т.к. это заведомо проигрышный путь. Дело не в конкретной имплементации или профессионализме разработчиков Эльбруса ( в МЦСТ есть специалисты, безусловно, мирового уровня в своих сферах). Проблема именно в самой архитектуре Эльбрус, которая принципиально менее производительна, чем RISC/CISC архитектуры с современными реализациями микроархитектур с OoO исполнением.
Именно поэтому, при всей уникальности линейки процессоров Эльбрус, они не могут служить базовой платформой для массового производства отечественной вычислительной техники.
P.S. Продолжение моих мыслей про отечественные процессоры тут
Комментарии (808)
N-Cube
01.08.2021 13:05Возможно ли на суперкомпьютере оптимизировать бинарный код под VLIW так, чтобы решить указанные в статье проблемы с ручной доводкой всего софта? Большую часть ПО достаточно перекомпилировать, скажем, раз в год (или в месяц, если патчи безопасности регулярные нужны), возможно, с генерацией достаточно оптимального кода справится один из топовых российских суперкомпьютеров (на процессорах Интел). Идея очевидная, но почему-то нигде не разбирается, осуществимо ли это.
akaAzazello
01.08.2021 13:38+2>> на суперкомпьютере оптимизировать
Чтобы что-то оптимизовать на супер-компьютере, вначале надо написать оптимизированный софт для супер-компьютера (т.к. производительность суперкомпьютеров сейчас преимущественно достигается через SIMD/GPGPU).
Впрочем в статье всё прекрасно описано - на динамических данных это невозможно - только на статических (которые составляют максимум несколько процентов от общего числа данных)
Paskin
02.08.2021 09:44Именно это и делают в DSP. А для процессора общего назначения, тем более в многозадачной ОС - как вы это себе представляете?
yalex1442
04.08.2021 23:29Оптимизировать бинарники можно с помощью техники многофазной сборки - PGO, но для проектов придется выделять допресурсы на написание скриптов прогона основных сценариев использования программы. еще и отслеживать ситуации с провалами производительности, когда по каким-то причинам в финальной сборке не применилась нужная информация из тестовых прогонов.
VladUA
01.08.2021 13:06+12Именно поэтому, при всей уникальности линейки процессоров Эльбрусов, они не могут служить базовой платформой для массового производства отечественной вычислительной техники.
Но они могут служить для массового производства российской вычислительной техники для держсектора.
Как по мне это идеальный кандидат чтобы заменить банальные кучи рабочих станций для разного рода структур вроде вояк/милиции/бти и прочее и прочее.
Да, это все равно выйдет дороже чем просто купить базовые компы на пентиуме/рязань3. Но зато есть и плюсы:
1) часть денег остается в стране
2) в стране поддерживаются и создаются специалисты высокого уровня
Есть конечно минусы, и их немало:
1) впереди все еще немалое количество софта, которое придется оптимизировать/портировать
2) это просто дороже (хотя наверно этот пункт нужно ставить первым)
Но это все перекрывается двумя главными проблемами:
1) МЦСТ работает по модели «только держзаказы, на частных клиентов плевать»
2) МЦСТ к ит-сообществу/энтузиастам развернуто попой, в результате не использует довольно большой пласт мотивированной и практически бесплатных (для них) мозгов, по-сути добровольно отказывась от отличного буста для продвижения и совершенствования их продукции
ИТОГ: как это не странно, но главный тормоз для Эльбрусов — действия и стратегия руководства МЦСТ.
П.С. это все мое неспециализированное ИМХО, я вполне могу ошибаться или что-то недопонимать.
checkpoint
01.08.2021 14:02+13ИТОГ: как это не странно, но главный тормоз для Эльбрусов — действия и стратегия руководства МЦСТ.
Руководство МЦСТ не раз давало понять, что всей политикой заправляет главный заказчик, у которого нет ни малейшего желания делать Эльбрус полностью открытым и привлекать сообщество к решению задачь (создание того-же оптимизирующего компилятора в замен lcc). Свои задачи они решают, на остальных — класть болт. Ситуация с «туманом» вокруг микропроцессоров Эльбрус очень выгодна главному заказчику.
Armmaster Автор
01.08.2021 14:51+4Там набор факторов. С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.
С другой стороны есть понимание, что Эльбрус принципиально проигрывает. Отсюда дополнительный набор действий по наведению тумана.
checkpoint
01.08.2021 15:01+8МЦСТ обеими руками за то, что бы сделать Эльбрус полностью открытым и привлечь всех желающих к разработке софта (компиляторов, математических и прочих библиотек), но главный заказчик — против такого подхода. Так как вся работа ведется на деньги заказчика, то ничего поделать с таким решением нельзя.
Armmaster Автор
01.08.2021 16:00+4Тут 2 момента.
Во-первых постоянные кивания "на заказчика" и рассказы про "обеими руками за"- это, скажем так, не совсем правда.
Во-вторых, суть статьи как раз в том, что это технически неверное направление. Проблемы продвижение, маркетинга, создания экосистеммы и т.д. и т.п. - это вопросы для отдельного, очень большого разговора.
a0fs
01.08.2021 16:02+2С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.
Повеселило. В нынешних условиях это как? Существенная часть продуктов работается по схеме тяп-ляп и в продуктив, и побольше хайпа. Откуда столько негатива к планомерной рутинной работе. Продвигать продукт возможно они и хотят (и нет такого разработчика, который не хотел бы широкого распространения своего детища), но есть объективные проблемы:
Начиная с первого появления живых образцов, вокруг архитектуры клубится негатив со стороны "разбирающейся в теме общественности". Сражаться с ветряными мельницами в виде людей, которым и интелов с армами вполне достаточно - глупо. В МЦСТ явно есть на что потратить деньги без попыток снизить кислотность общественной среды.
Отсутствует образ будущего со стороны государства и "общественности". Что нужно от машины на горизонте 10-15 лет, куда стремиться. На рынке, где архитектура Эльбруса всюду инородна нет смысла заниматься активным продвижением, поскольку на данный момент сам процессор страдает от бича российской действительности, когда нужно уметь и нашим и вашим, и Intel-ом прикинутся и быть не интелом, для всяких спец-контор.
Существует заказчик (как говорят), которого процессор устраивает, так зачем распылять силы на продвижение, если можно их сосредоточить на продукте. Динамика прироста возможностей, у процессора вполне нормальная.
ИМХО, Эльбрус адекватный процессор, с вполне хорошей производительностью. Для разработки топовых процессоров способных тягаться с гигантами нужно ни одно уцелевшее неведомо как советское НИИ, хоть как-то причастное к изготовлению СБИС, а комплекс этих самых НИИ и опытно-производственная база, чтобы не нужно было на Тайване за 100500 регулярно дорожающих денег заказывать опытные образцы для натурных испытаний. Нужна политика партии на развитие своего, а не нынешнее "импортозамещение", где большая часть всего для галочки. Ну и образ будущего, когда все понимают, что мы строим и спланировано движутся к поставленной цели. Необходимость тратить транзисторы на транслятор в процессоре идёт из принятого ещё в 70-тые курса на облегчение цельнодратия с прогрессивных и умных американцев их прогрессивного и умного софта. Мы ж не можем у нас совок и лапки... Ну и для того, чтобы продукт вывести не через 30 лет, а сильно раньше. Когда у нас будет гордость и желание обеспечивать себя ПО, а не тырить или закупать заморское чудо чудесное, в товарных объёмах, тогда и достоинства Эльбруса раскроются, а влияние недостатков будет уменьшено. Хороший пример - Японцы, у которых две тяжёлые машины от фуджика собраны на своём, не так чтобы хайповом, процессоре. На АРМ-е, когда это не было ещё так модно и Спарке, который не особо признан в HPC.
Сколько недостатков у Эльбруса нет, но это последний оригинальный Российский процессор. Только поэтому его стоит тянуть и активно использовать во всяких специальных и закрытых системах. Разучимся делать оригинальные вещи, можно закутываться в простыню и тащится на кладбище, ничего путного в будущем уже сделать не сможем.
Armmaster Автор
01.08.2021 16:57+8Хотеть чего-то мало - надо ещё уметь, я как раз про это.
А по сути, оригинальность должна быть к месту. Например, собственная микроархитектура, дающая в итоге производительность на уровне мировых аналогов - это правильная оригинальность. А собственная архитектура, которая принципиально уступает другим - это неправильная оригинальность. Надо научный потенциал направлять и компетенции развивать там, где это нужно и где это даст результат.
a0fs
01.08.2021 17:15+9Китайцы в 90 делали дрянь, сейчас они делают нам почти всё чем мы пользуемся. Чтобы делать хорошо, нужно учиться. А учиться без проб и ошибок не выйдет. Чтобы оригинальная архитектура давала производительность на уровне мировых аналогов, нужно производство и разработку на уровне мировых аналогов. Где это взять, если не развивать самим? Кто даст технологии мирового уровня, какой дебил добровольно отдаст своё конкурентное преимущество в капиталистическом мире. Долго учится, подглядывая у лучших, а потом сразу сделать шедевр, который их всех затмит - такое бывает только в сказках. Совершенство - тяжёлый труд нескольких поколений, когда на старте имеем дрянь, которая со временем становится совершенней. Эльбрус стартовал с высокой базы, и сразу стал не полным дерьмом, а вполне рабочей вещью. Дальше совершенствование, ввод дополнительных блоков, улучшающих подклассы задач, сопроцессоров, и возможно вынос транслятора x86 в отдельный чип, а лучше постепенно от него отказываться в подлинейке моделей. Но это работа на будущее, а пока пользуемся тем, что имеем, и судорожно придумываем, что нам нужно в будущем, чтобы определить приоритеты развития платформы. Просто "сделайте нам как у них, только у вас, и также быстро" это не вектор развития, это констатация его отсутствия.
Armmaster Автор
01.08.2021 17:21+3Эта статья и есть про то, где были сделаны ошибки и как их исправлять. Надо не "делать как у них" , а делать правильно, вне зависимости, делают у них так или по-другому. У нас же законы физики при пересечении границы не меняются. А упорствовать в своих заблуждениях - это и есть верный путь к провалу. Пусть будет дерьмово, зато не как у всех! Странная логика.
a0fs
01.08.2021 17:41-1В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?
а делать правильно
Никто не знает как правильно, поэтому слабые духом делают так же. Процессоры, которые пошли этим же путём, мы знаем, это и Байкалы. Мне кажется второй Байкал от МЦСТ будет лишним для рынка России, не отличающегося масштабами. А SPARC и собственный VLIW вполне хорошие запасные варианты.
И ещё раз. Да, я согласен, что Эльбрус для задач общего назначения странен. И не за счёт VLIW, а за счёт того, что там всё плохо с переключением задач. Как говорилось на какой-то конференции, она там крайне дорога. Я не думаю, что он пойдёт в массы. Скорее в массы пойдёт вполне предсказуемый Байкал, поскольку АРМ-ом и MIPS сейчас никого не удивишь. Эльбрус - это специальные и большие супер машины и числодробительные ускорители, там как кажется его удастся раскрыть. Но нет у нас сейчас даже намёков на интерес к таким машинам. А когда появится МЦСТ уже сдохнет и разложится. Поэтому пытаются найти нишу для архитектуры, с надеждой на светлое будущее.
Armmaster Автор
01.08.2021 17:52Так дороговизна переключения задач и есть ещё одна проблема VLIW )) Я уж просто не стал углубляться в кучу мелких проблем и деталей, коих там вагон. Ну и как раз дороговизна переключения там не настолько уж плохая. Была бы только в этом проблема - уж как-нибудь можно было крутиться. Но проблем там, как я в статье описал, много.
creker
01.08.2021 17:58+1В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву.
Все таки речь о неправильной его реализации конкретно интел, а не неправильном подходе. Большая часть проблем, например, обошла АМД вообще или бессмысленны на практике.a0fs
01.08.2021 18:36+2Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...
strvv
02.08.2021 09:28-1назови архитектуру, где Out of Order не имеет возможности организовать коллизии? как указал a0fs — если делать правильно — проще Out of Order вообще не реализовывать — дешевле и надёжнее.
creker
02.08.2021 11:53-1Я могу назвать архитектуру, которая обошла большинство самых серьезных проблем и не требует на деле патчей, которые просаживают производительность значительно. Это амд и их zen.
0xd34df00d
03.08.2021 03:48+1В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?
Для значимой части задач и условий использования это не является уязвимостью. Если вы не запускаете чужой бинарный код и достаточно загрубляете условные таймеры в условном JS, то на этот класс атак вам плевать.
Я у себя вообще
mitigations=offсделал. Предложите векторы атаки на мой настольный компьютер.
CNstuff
02.08.2021 17:27Дак вот в этом и шутка, что в 90х китайцы делали дрянь потому что не могли и не умели другого. Но даже в 90х после развала СССР в России было кому и где делать хорошие вещи, но почему-то не смогли.
AMaxKaluga
23.08.2021 14:45-1Наверно потому что сказали нафига надо, мы у партнёров всё купим. И партнёры уверенно кивая, помогли с переходом.
arcman
01.08.2021 14:26+6Для описанных вами задач есть процессор Байкал-М (BE-M1000) на ARMv8:
https://www.baikalelectronics.ru/products/238/
acc0unt
01.08.2021 14:38+2Собственно, да. Это уже намного более подходящее решение для клиентских устройств. И совместимость с софтом и экосистемами лучше, и инструменты для разработки доступнее, и степень интеграции выше.
Единственный недостаток, если его можно таковым считать - зависимость от ARM. Но сейчас как раз поднимает голову RISC-V. Он уже начинает ставиться в микроконтроллеры, и на руки людям приходят первые образцы процессоров для рабочих станций.
checkpoint
01.08.2021 14:55+1К сожалению, в России разработки микропроцессоров на архитектуре RISC-V сейчас не ведутся. Да, есть пара фирм (почему-то зарегистрированных на Кипре) занимающихся изобретением своих софт-ядер RISC-V, но это не микропроцессор и тем более не высокопроизводительный. Я думаю, что с RISC-V у нас получится как всегда — через лет 5-7 властьимущие очнутся и начнут размахивать шашками, но будет поздно. Вместо того, что бы прямо сейчас возглавить разработку RISC-V и быть в авангарде, мы будем долго и упорно тащить всё своё наследие в виде Эльбрусов и прочих очень спецефических разработок, пока это наследие не потопит нас.
Andrey_Petroff
01.08.2021 16:57+14Вы видимо не в курсе, но российская компания "Ядро" (которая до этого скупила российского разработчика RISC-V ядер компанию Syntacore) начала разработку собственных процессоров на архитектуре RISC-V. Причем инженерные образцы процессоров для ПК и ноутбуков должны выйти уже в следующем году, а в 2023 они обещают уже 48-ядерный серверный процессор с частотой 3 ГГц.
Xambey
01.08.2021 22:14+1Только вот есть проблема, эта Yadro вошло в список для конкурса по раздаче бюджетных денег, имея в составе своих разработок дофига иностранных компонентов, что противоречит требованию об импортозамещении. МЦСТ даже вроде недавно на них иск в суд подала из-за неконкуренции. Их кто-то пропихнул вперед байкалов и эльбрусов
asmolenskiy
03.08.2021 13:59-2Вы сначала требования по импортозамещению почитайте в 719ПП, а потом уже бросайтесь такими тезисами.
Нет у Yadro никаких проблем - все сделано и делается с полным соблюдением всей нормативки.
amartology
03.08.2021 14:10+1Нет у Yadro никаких проблем — все сделано и делается с полным соблюдением всей нормативки.
Постановление правительства РФ номер 1746
с 1 января 2021 г. соблюдение процентной доли стоимости использованных при производстве иностранных комплектующих изделий — не более 35 процентов цены товара, включая обязательное применение в продукции центрального процессора, удовлетворяющего требованиям к интегральной схеме первого уровня или интегральной схеме второго уровня, предъявляемым в целях ее отнесения к продукции, произведенной на территории Российской Федерации;
Процессор IBM, стоящий в СХД, закупку которой отменили, никак не является отечественным, и попасть в реестр отечественной продукции легально СХД на таком процессоре не могла.
Так что неправда ваша про полное соблюдение всей нормативки.asmolenskiy
03.08.2021 14:18+1Это правда - потому что оборудование подавалось в реестр до появления этих требований. И акты не перевыпускаются при каждом изменении.
То что попало в реестр - живет там год. Потом повторная сертификация по новым правилам.
asmolenskiy
03.08.2021 14:30Вообще мне так и не понятно с чего пошла это волна.
Заказчики этой чернухи прекрасно знают правило игры. На что они рассчитывали, кроме того, чтобы публично обделаться - я не знаю.
Armmaster Автор
03.08.2021 14:44Что интересно, охапку фидбеков в свою сторону что "это заказная статья от Галицкого" я уже получил. Т.е. показательно, в каких категориях они сразу мыслят.
Кстати, хотел спросить, а причём здесь Галицкий?)) Он как-то аффилирован с Ядром? И какой Галицкий, тоже можно уточнить, а то я минимум двоих знаю))
asmolenskiy
03.08.2021 14:53А кто такой Галицкий?
Статья, насколько знаю не то что заказная - а скорее без fact-check вышла. Кто эту волну пустил я знаю совершенно точно (да все знают уже в рынке). Но не скажу) Мы на уровень кидания какулами в публичном поле не опускаемся.
Armmaster Автор
03.08.2021 15:30Вы, по-моему, не поняли мой вопрос. Я автор данной статьи про проблемы Эльбруса. И меня тут некоторые обвинили в том, что это заказуха от Галицкого для продвижения RISC-V. Я, собсвенно говоря, интересуюсь, причём тут Галицкий? Разве он имеет отношение какое-то к Ядру?
asmolenskiy
03.08.2021 15:32Я тоже не знаю)))
И я имел в виду не эту статью, а статью в Известиях о том что нас откуда-то выпилили и прочее. Про Вашу статью я вообще ни слова не сказал.
Прошу прощения если Вам так показалось.
uFarm
04.08.2021 18:32ЦИПР 2021. "В дискуссии принял участие Александр Галицкий, основатель и управляющий партнер венчурного фонда Almaz Capital Partners, советник премьера Михаила Мишустина по проблемам электронной промышленности. " Основатель Elvis.
Armmaster Автор
04.08.2021 18:34Ну ок, и причём здесь Ядро и RISC-V? Элвис же делает ARM чипы, да и у них другая ниша, они на рынок GP CPU по-моему не претендуют.
amartology
04.08.2021 18:44Основатель Elvis.
Во-первых, основатель Элвиса — Петричкович.
Во-вторых, Элвис не занимается ни RISC-V, ни какими-то процессорами, конкурирующими с Эльбрусом.
perfect_genius
01.08.2021 23:13checkpoint
02.08.2021 00:02+1Это что-то новое, посмотрим во что выльется. Спасибо за ссылку на новость.
Вот тут чутка больше подробностей: 3dnews.ru/1044326/rosteh-sozdast-otechestvennie-protsessorina-arhitekture-riscv-dlya-noutbukov-i-serverov
Нацеливаются на 8 ядерный RISC-V на частоте 2ГГц. Cобираются потратить 18 млрд руб. Не плохое начало, если слова дойдут до дела.
Цитата:Ожидается, что первые 60 тыс. систем на новых процессорах будут отправлены заказчикам к 2025 году, что означает, что производство непосредственно процессоров начнётся примерно в 2023 году. Следовательно, на разработку отводится примерно два года. Для решения на открытой архитектуре — это вполне приемлемое время, хотя отладка всегда чревата массой сюрпризов
Paskin
02.08.2021 09:49И мы примерно представляем, в каких статьях УК эти "сюрпризы" давно описаны.
asmolenskiy
03.08.2021 14:07+2Ни в каких. Разработка SoC происходит за собственные средства, а не за какой-то госНИОКР (как у нас водится).
А что то там Ростех или еще кто-то коммитится под объемы закупок оборудования (хотя это все ОБС на самом деле) - это совершенно другая история.
Мы не играем в прямое гос-деньги в виде НИОКР по которому мы что-то кому-то обязаны сделать. И не играем в прямые гос. контракты. Потому что да - часто люди за это попадают в тюрьму.
Мы не делаем разработку на заказ, только на продажу. Так что риски у компании тут вполне понятные - вложить денег и не отбить инвестиции.
Paskin
03.08.2021 14:35+1Тогда я рад за вас. Потому что я был на одной из ведущих выставок электроники - где Россия построила целый павильон. Куча дядек в дорогих костюмах и скучающие девочки модельной внешности. Какие-то видавшие виды платы под стеклом, которые нельзя посмотреть вблизи - а по поводу характеристик "инженер только что здесь был, наверное отошел на пару минут". Инженера я так и не дождался ни в этот день ни в следующий, на электронные письма ни одна из представленных компаний не ответила.
А в соседнем зале выставлялась российская компания (не афиширующая этот факт), занимающаяся решениями на базе западных SoC - у них на стенде были одни инженеры, и туда было не протолкнуться.asmolenskiy
03.08.2021 14:42Мы пытаемся построить нормального российского продуктового вендора глобального масштаба.
Это одна из основных целей компании.
Да - нам это сложно с учетом геополитических реалий, российских реалий и всего остального.
Но не надо экстраполировать на нас скажем, практики, которые применяют другие компании в России.
amartology
03.08.2021 14:49+1Но не надо экстраполировать на нас скажем, практики, которые применяют другие компании в России.
Это довольно сложно после того, как узнаешь, что конечный бенефициар компании — Алишер Усманов.
asmolenskiy
03.08.2021 14:55-1Ну и что?
Известный олигарх выкупил у НКК потенциально выгодный актив. Вы же не думаете что он тут у нас между паяльных станций ходит?
Структурам Усманова много чего принадлежит.
Нам тут ни холодно ни жарко от сего знания. Раньше принадлежали Калинину, сейчас Усманову, завтра он нас кому нить продаст или не продаст. Калинина я видел один раз в жизни, Усманов вообще где-то там в другой галактике.
Между ним и нами 100500 компаний еще посередине.
Где блин Усманов и где RISC-V. Будьте реалистами в конце концов.
amartology
03.08.2021 15:12+1Вы же не думаете что он тут у нас между паяльных станций ходит?
У вас между паяльных станций — вряд ли. А вот поужинать с Чемезовым, чтобы он подтвердил, что Ростех у вас купит что-то — вполне.Где блин Усманов и где RISC-V. Будьте реалистами в конце концов.
Где Усманов и где многомиллиардные контракты на СХД? Да очень близко. Или вы считаете, что он вас купил, а дальше пальца о палец не ударит, чтобы отбить инвестиции?
asmolenskiy
03.08.2021 15:19Да пусть ударяет - лишь бы на пользу шло.
Я просто не понимаю ход Ваших мыслей. Вот у нас тут есть маркетологи и продуктовые менееджеры - они бегают по рынку и спрашивают кому что надо.
Мы (инженера) это делаем.
Потом сэйлы это продают.
Или Вы думаете мы сидим такие - ай, дядя АБУ ща все порешает - а мы на 3Д принтере щас напечатаем тут что нить и продами за бешбабло. Вы это так себе представляете? Нафига нам тогда было тут городить крупнейший центр разработок для этого? Можно было студента нанять чтобы он в кикаде че-то рисовал и документашку по ГОСТ лепил - и так сойдет.
amartology
03.08.2021 15:23+2Ход моих мыслей очень простой: что бы у вас не происходило на самом деле, на вас теперь клеймо «принадлежат владельцу распилов и откатов», и отношение много у кого будет соответствующим.
Вне зависимости от того, что у вас происходит на самом деле.
asmolenskiy
03.08.2021 15:28Ну во-первых "нас" оно не особо заботит. Моральных страданий мы по этому поводу не испытываем. Вы вот правда меня, инженера пытаетесь попрекать тем кому принадлежит мой работодатель? Может бы у меня тут в России обширный выбор и я такой - ой фу к Усманову не пойду, к Фролову не пойду, в ДЕПО не пойду. Ну вот давайте ткните пальцем в ту самую светлую и честную компанию.
Во-вторых все кому-то принадлежат. У всех есть бенефицары которые имеют доступ не то что к Чемезову, но и к тому кого нельзя называть. Жизнь такая.
В-третьих - если олигарх решил прокачать российское IT а не очередную яхту - это же прекрасно.
amartology
03.08.2021 15:41Вы вот правда меня, инженера пытаетесь попрекать тем кому принадлежит мой работодатель?
Нет, конечно нет. Все моральные выборы, мнимые или настоящие — полностью ваше дело. Я говорил о другом.
Напоминаю, с чего начался наш диалог:
— не надо экстраполировать на нас скажем, практики, которые применяют другие компании в России.
— Это довольно сложно после того, как узнаешь, что конечный бенефициар компании — Алишер Усманов.
asmolenskiy
03.08.2021 15:52Ну вот я Вам отвечаю - несмотря на то что наша компания входит в структуры Усманова - мы пытаемся работать как наши заокиянские коллеги (ну или на худой конец тайваньские). То есть пытаемся делать то, что можно продать, а не запихать насильно в трусы всем кто мимо проходит.
amartology
03.08.2021 17:54А я вам говорю — не важно, как у вас обстоят дела на самом деле (я вот знаю, что нормально) — вам все равно никто не поверит сходу. Это печально, но так работает репутация. В данном случае — репутация Усманова.
Поэтому люди непременно будут на вас экстраполировать все кхм принятные в России практики ведения бизнеса, пока вы не докажете обратное — и даже после этого.
asmolenskiy
03.08.2021 18:52Ну... нам же главное чтоб клиенты поверили, а они все таки мыслят другими категориями.
Еще главное чтобы наши будущие сотрудники поверили и пришли к нам. Но у нас нет проблем с репутацией на рынке труда. Yadro по совокупности факторов (оплата, отношение к сотрудникам, развитие, устойчивость) очень хороший работодатель.
А глобальный общественный имидж - ну конечно неприятно читать всякое, но глобально - с этим можно жить. Мы же понимаем, что обычно это разгоняют люди вообще далекие от отрасли. А мнение там моего соседа по лестничной клетке имеет сомнительную ценность. Лучше когда оно позитивное - но в целом пофигу.
Am0ralist
03.08.2021 18:54Ок, а не думали написать про это статью здесь тогда, чтоб понимали разницу между новостями «ЯДРО и ростех чего-то там вместе мутят на столько-то лярдов»?
asmolenskiy
03.08.2021 19:09В данный момент у нас политика - не пиариться в интернете.
Я даже наверняка что-то нарушаю, поддерживая этот диалог.
Кроме небольшого цикла статей тут, который быстро закончился (фантазия иссякла да и время тоже) - мы сами про себя ничего нигде не пишем. Поэтому все что Вы видите про нас в интернет - это обычно негатив, из-за которого торчат вполне конкретные уши.
amartology
03.08.2021 19:30В данный момент у нас политика — не пиариться в интернете.
Это очень плохая политика, я могу потыкать пальцем в отечественных процессоростроителей, которые уже на этом погорели — и на тех, кто еще не погорел, но погорит в обозримом будущем.
asmolenskiy
03.08.2021 19:39Ну они ж не на этом горят, а на том что берут на себя обязательства, которые не могут исполнить.
Вот что глобально изменится для нашей компании если мы начнем тут или на СуН раз в неделю выкладывать статейки как мы задорно пилим и дебажим железки и какие они клевые.
Люди, которые принимают решения о закупке оборудования не делают это почитывая интернет. У них другие критерии. Вы ж не будете принимать решение потратить несколько ярдов почитав развлекательный контент?
PR в соцсетях и СМИ - это скорее работа кадры. Чтобы люди читали сами про себя где-то и радовались, гордились там и прочее.
Лично я считаю что нужно это делать, но у руководства другое мнение. Ну и им скорее всего виднее - они не вчера с ветки спрыгнули.
amartology
03.08.2021 19:43+1Ну они ж не на этом горят, а на том что берут на себя обязательства, которые не могут исполнить.
Есть и такие, которые говорили «зачем нам пиариться, нас госзаказчик и так купит». А потом неожиданно выяснилось, что не купит. И что разработчики приборов знают про старые разработки, и помнят, что «компания Х» — выпускает какое-то говно мамонта, устаревшее много лет назад. А дальше все, ты можешь двадцать раз сделать что-то хорошее, но в систему поставят изделия лучше пиарящихся конкурентов, которые ничем не лучше, но на слуху. А потом и ОКР перестали давать — потому что зачем давать ОКР на разработки мамонтова говна?Люди, которые принимают решения о закупке оборудования не делают это почитывая интернет.
Они довольно часто имеют тенденцию прислушиваться к мнению своих читающих интернет инженеров. Да и сами читают — я проверял своими статьями. И благодарности получал, и по шапке — напрямую от разнообразного высокого начальства, и своего, и чужого.Чтобы люди читали сами про себя где-то и радовались, гордились там и прочее.
И не без этого тоже, да. Чтобы привлекать лучшие кадры на работу, надо иметь публичный образ хорошего места для работы, а не усмановской распильной конторы.
asmolenskiy
03.08.2021 22:20Ну Вы путаете теплое с мягким.
Не пиариться в интернете - не значит не пиариться. У нас лучшая сэйловая команда в стране. Они очень хорошо бегают и пиарятся там где нужно. Просто мы работаем на корпоративном рынке (пока, может и до ширпотреба дойдем - кто знает). И там узнаваемость брэнда очень высокая.
А второй момент, что мы же не делаем там платы, заказные разработки и прочее. Мы делаем продукт - сервер там, хранилка. И даже на самом деле уровнем выше - мы делаем решения. То есть к нам приходит там... ритейл и говорит - сделайте чтобы у нас маркетинговые кубы быстро крутились (это от балды абстрактный пример). Мы можем туда ставить свое оборудование, можем ставить OEM (которым нас тоже не забывают попрекать) - это уже более низкий уровень представления, вторичный.
К нам нельзя прийти и купить наш кабельный PCIe адаптер или плату свича или материнскую плату или что-то еще из 300+ запиленных электронных модулей. Нам нет нужды ходить в разработчиков - мы сами разработчики конечных изделий.
А касательно репутации на рынке труда. Информация о численности - скорее всего тайна, я цифру не скажу. Но Yadro уже достаточно крупная компания, а рынок кадров - маленький. Мы уже года 3-4 как не стартап, а очень крупный инженерный центр. Поэтому все кто находится в зоне нашего кадрового интереса - в основном уже прекрасно все знают. Мы эту работу на зачетку как раз проводили когда писали статьи на Хабр, ходили в социальные группы разработчиков и прочее - как раз для этого. Сейчас у нас очень много инженеров - они общаются в своих кругах, приводят к нам своих бывших коллег, рассказывают остальным как им у нас живется и эта машина в принципе едет сама.
Поэтому не нужно сомневаться в нашей возможности что-то запилить - будь-то аппаратура или процессор. Задизайнить мы можем все что угодно - все риски тут только в коммерческой целесообразности а не технической способности.
Am0ralist
04.08.2021 10:32Просто мы работаем на корпоративном рынке (пока, может и до ширпотреба дойдем — кто знает). И там узнаваемость брэнда очень высокая.
Ну, блог компании Крока, например, мне лично нравится намного больше блогов хостингов. И хотя у оных вроде как тоже узнаваемость в корпоративном высокая, а их решения так же просто так не получится взять, прийти и купить, но…
Am0ralist
04.08.2021 10:30Люди, которые принимают решения о закупке оборудования не делают это почитывая интернет. У них другие критерии. Вы ж не будете принимать решение потратить несколько ярдов почитав развлекательный контент?
Ну если цель крупные корпорации и чиновники, это одно. Если ещё и бизнес — то да, решения будут приниматься ещё и на основе «известности» бренда в широких IT-кругах, в обсуждаемости его технологий.
Am0ralist
04.08.2021 10:25-1А зачем пиариться. Расскажите, как что-то делаете, какие трудности. Что планируете.
Не, понятно, что кучка хомячков набежит с криками «пиар, пиар».
Но обычные инженерские вещи обсуждать… ну, хз…
asmolenskiy
04.08.2021 11:02+1Это на самом деле не так просто как кажется - взять и написать.
Щас попробую сформулировать. С точки зрения хардверщика (программисты немного в другом мире - поэтому я вот только за своих).
Мы в принципе всегда делаем одно и тоже всегда - делаем схемы, разводим платы, дебажим, ну и так далее. Для нас это просто самая обыденная текущая рутина - в ней нет каких-то вещей про которые на наш взгляд вообще стоит писать. Самая обычная, ежедневная, в основновном рутинная работа.
И вот приходит маркетинг - и у нас начинаются просто страдания - ну о чем вообще писать. В итоге выдумывается какая +/- более менее понятная тема - и мы пишем, долго и мучительно. Потом это все естественно цензурируется (не сильно - на пару процентов может), разбавляется юмором, картинками и постится. Вот блин делать эту процедуру на регулярной основе для нас, инженеров - это адский ад. Поэтому как только маркетинг перестал к нам с этим ходить - мы перестали этим заниматься. Если б был такой инженер у нас кому это нравится делать (ну бывают такие) - это одно. У нас таких нет. Для нас такая деятельностью - это сродни наказанию.
asmolenskiy
04.08.2021 11:15Этим профессионал отличается от радиолюбителя. Радиолюбитель может постить до бесконечности про какую нить погремушки, которые он сделал из палок и желудей - для него это хобби.
Я на потоке занимаюсь электроникой уже больше 15 лет из них почти 10 - HPC а потом серверами и хранилками. Одна машина за другой, нон-стопом. Для меня это не какой-то вызов - а обычная рутина. IBM, Intel, AMD, Эльбрус - да пофигу. Очередная мамка, очередной набор бакплейнов, разеров и прочего. Машинист в метро водит поезд, а я делаю вычислительные системы. Для меня не существует таких вещей, которые мне было бы интересно обсуждать с широкой публикой. И большинство хардверщиков - они именно такие.
И у нас еще прикольно - средняя продолжительность активного проектирования - полгода, потом следующая машина. У военных так вообще тьма - у них там проекты по 10-15 лет.
Такая работа - она только со стороны кому-то кажется какой-то особенной.
edo1h
04.08.2021 14:56ну то есть ваша работа не вызывает у вас особого интереса? «могу копать, могу не копать».
ИМХО это грустно.или вы хотели сказать, что вам кажутся интересными такие вещи, которые не объяснить неподготовленному слушателю?
asmolenskiy
04.08.2021 15:16Не надо все сводить к бинарным опциям интересно / не интересно.
Интересно ли мне читать публикации Богатина и других экспертов по Signal Integrity - да интересно.
Ковырять какие-то новые системы проектирования и моделирования - интересно.
Дебажить интересно и драйвово. Особенно ценен момент когда железо оживает - он очень эмоциональный.
Но нет никакого интереса читать там... очередной даташит на очередной чип, срисовывать очередной рефдизайн или трассить очередную плату - а это 95% работы хардверщика.
asmolenskiy
04.08.2021 15:43Если обобщить - то как и в любой работе - интересно делать и узнавать что-то новое, развиваться.
Причем DDR5 вместо DDR4, PCIe Gen4 вместо Gen3, Intel вместо IBM - это не что-то новое.
А повторять из раза в раз одни и те же действия с вариативностью деталей - как это может быть интересным?
Я знаю например коллегу, который в какой-то момент сменил работу, потому что ему хотелось ходить в другой офис, другим маршрутом и общаться с другими людьми. Чел 25 лет в отрасли и знает и умеет по ходу вообще все. Наша профессия не столь динамична - законы физики как появились так и не менялись с тех пор. Книжки 1980х выпуска до сих актуальны и годны для самообразования. А бэкграунд в 10-15 лет вполне себе релевантен при трудоустройстве.
asmolenskiy
03.08.2021 14:15Просто надо правильно понимать контекст ситуации.
Тут не то, что государство дало денег Yadro и написало там ТЗ на процессор, количество патентов рабочих мест и прочего.
А Yadro (возможно, так пишут в синусе) пришло и спросило - если мы это сделаем (компьютер, планшет итд) - Вы будете это покупать?
checkpoint
01.08.2021 14:44+6Статья об Эльбрусе, а не о Байкале.
Если Вы не поняли смысл статьи, то я поясню. Российское государство пытается сейчас пропихнуть Эльбрус как ЦПУ общего назначения (читай — микропроцессор для десктопов). Автор статьи показывает, что архитектура VLIW — ущербна и не пригодна для такого применения.arcman
01.08.2021 22:38+1Вы точно мне это хотели написать? Я то всё понял и с автором согласен, я отвечал комментатору, который предлагал использовать Эльбрусы в гос секторе в качестве АРМ, но Байкал-М для этих целей явно лучше.
Armmaster Автор
01.08.2021 14:48+3Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора. Теоретически, это могут сами же МЦСТ и сделать. И не мучать несчастных пользователей и не вкладывать деньги туда, куда заведомо понятно что не надо.
crea7or
01.08.2021 14:59-10А вам-то какая разница? Вы хотите такой заказ получить или что?
Armmaster Автор
01.08.2021 16:01+8За державу обидно.
vladshulkevich
01.08.2021 21:22-11ну да, ну да. Заберите бабло у мцст и отдайте байкалу. У нас всякий знает, что для державы лучше. Что странно, они никогда между собой не могут договориться, пока товарищ Берия за них решение не примет, отчаявшись дождаться "консенсуса".
Armmaster Автор
01.08.2021 22:00+6По существу есть возражения?
vladshulkevich
01.08.2021 22:52-6а как же! Начиная с названия: откуда вообще идея, что Эльбрус должен конкурировать в сегменте процов общего назначения?
Armmaster Автор
01.08.2021 23:15+5Это вопрос к тем, кто Эльбрус в эту нишу продвигает. В самом начале есть ссылки на соответствующие статьи, можете ознакомиться.
divanikus
01.08.2021 15:37Интересно насколько сейчас в принципе реальна перспектива создания своей RISC/CISC архитектуры, не беря уже имеющиеся типа ARM, SPARC или MIPS. Ведь любая платформа, будь она хоть state of the art без софта обречена, а софт это как минимум более-менее мейнстримовая операционка и компилятор.
Armmaster Автор
01.08.2021 16:04+3Наверное, ARM было бы оптимальным решением. Но там легко могут организовать проблемы с лицензией. Поэтому, в плане открытости и независимости, на данный момент наиболее перспективным выглядит RISC-V. Но с другой стороны, это ещё очень сырая архитектура.
amartology
02.08.2021 03:26С чего бы RISC-V сырая архитектура? Под нее уже есть высокопроизводительные решения серверного класса, и софта уже выше крыши. Прямо сегодня RISC-V способен достойно конкурировать с ARM вообще в любой нише.
Armmaster Автор
02.08.2021 03:33И какие есть решения серверного класса на RISC-V? Векторный iset устаканили?
P.S. Я как бы двумя руками за RISC-V, но сравнивая состояние экосистемы того же ARM и RISC-V, думаю что слово "сырая" тут вполне применимо.
amartology
02.08.2021 03:49+1Например, есть представленные на прошлой неделе ядра серии Performance от SiFive. Или 1000-ядерный ML-чип от Esperanto. Сравнивая состояние экосистем, я вижу, что до ARM осталась буквально пара лет. И до RISC-V ноутбуков, вероятно, тоже.
А число произведенных RISC-V чипов попроще уже перевалило за миллиард.Armmaster Автор
02.08.2021 11:13Чипы от SiFive ещё слабые и крайне далеки от серверного рынка. На прошлой неделе получил их плату HiFive Unmatched и имел возможность немного потестить (будет время опубликую результаты). 1000-ядерный ML чип от Эсперанто это вообще другая история, это не general-purpose CPU, там Minion-core вообще in-order.
Ну и как я выше написал, даже векторный Iset ещё не устаканился.
amartology
02.08.2021 11:50Чипы от SiFive ещё слабые и крайне далеки от серверного рынка.
P550 выглядит вполне нормально. Или, скажем, SCR7 от Синтакора.1000-ядерный ML чип от Эсперанто это вообще другая история, это не general-purpose CPU, там Minion-core вообще in-order.
Так прямо сейчас огромный кусок серверных задач — это машинлернинг, отсюда и такой пример.Armmaster Автор
02.08.2021 14:40P550 выглядит вполне нормально. Или, скажем, SCR7 от Синтакора.
Это всё ещё далеко до серверных решений, хотя дорога верная
Так прямо сейчас огромный кусок серверных задач — это машинлернинг, отсюда и такой пример.
Мы всё же говорим именно о general-purpose CPU и серверных чипах в этой нише. Давайте ML сюда не примешивать, это сильно отдельный топик.
Civil
02.08.2021 15:36+2P550 выглядит вполне нормально. Или, скажем, SCR7 от Синтакора.
Давайте посмотрим что известно про P550:
SPECint2006 - 8.65/GHz, это примерно на 30% лучше чем у Cortex A75. Вспомним про сервеный арм в лице Neoverse N1 у которого SPECint2006 - ~14.2/GHz (37 на одно ядро на частоте 2.6 ГГц)
С SPECfp все менее понятно становится, в презентации SiFive было только "114% от Cortex A75", а именно FP пилили больше всего (35% прирост при переходе на A76, например и еще какой-то прирост у Neoverse'а)
До 4 ядер в кластере. У того же Neoverse - до 128.
Планируемые частоты - 2.4 ГГц на 7нм. Смотрим что у того же neoverse - 2.6 для заметно большего числа ядер.
Там по прежнему нет SIMD. Собственно его нет, потому что спека еще не финализирована.
Я где-то недалеко говорил про особенности реализации работы с кэшом из кода в RISC-V (она отсутствует), это тоже создаст определенные проблемы в реальном мире. Притом в этот раз - нерешаемые без использования непереносимых кастомных расширений производителя ядра (если он вообще их реализовал).
Затем вспоминаем, что с момента доступности IP до его внедрения проходит минимум 1.5-2 года, что косвенно можно увидеть в планах интела по выпуску их Horse Creek в конце 22 или начале 23 года. То есть суммарно P550 выглядит как мощный мобильный процессор, но никак не как серверный. Не хватает и масштабируемости по ядрам в рамках одного кластера и по производительности на 1 поток недотягивает до ARMов. И главное - на серверном рынке ему бы пришлось конкурировать с Neoverse N2, если бы он туда позиционировался.
Касательно Syntacore SCR7 он совсем простенький же, это по сути проц уровня Raspberry Pi 3 (4.00 Coremark/MHz, 3.0 DMIPS/MHz, по Coremark'ам мне честно лень на 3-ей малине гонять бенчмарк ради комментария, но в интернете пишут про 5 Coremark/MHz что примерно соответствует тому что я помню, по DMIPS - все чуть хуже, там примерно 2.1-2.2, у A55 должно быть 2.6, у старенького A57 уже 4.0+), то есть ядро там примерно на уровне Cortex-A53 (где-то чуть хуже, где-то чуть лучше, но одного класса). Цифры по SCR7 я взял из их презентации на RISC-V Forum от декабря 2018 года. То есть по производительности это уровень чипов в домашних роутерах (при условии что сеть хорошо реализована и сетевуха много на аппаратном уровне делает) или телеприставок (если есть нормальный видеодекодер), но никак не ноутбука и тем более не сервера.
Но RISC-V развивается и это прекрасно. Со временем он действительно станет достаточно хорошим, чтобы применяться в серверах. Просто это будет не сегодня и не завтра и не в ближайшие пару лет.
edo1h
02.08.2021 04:20ИМХО всё-таки не «сырая», а молодая и
дерзкаядинамично развивающаяся.Civil
02.08.2021 11:27+2У RISC-V есть проблемы в том числе на уровне ISA. Например там отсутствует как класс все связанное с работой с кэшом (нет инструкций, которыми можно инвалидировать кэш, например). Это обещают поправить в следующих ревизиях, только вот пока их посмотрят, пока начнут производители железа использовать...
Это все можно назвать "сырой", можно "молодой и динамично развивающейся" - суть та же - есть шанс что детские проблемы со временем исправят. Но в текущий момент они немного ограничивают сферы применения архитектуры.
yalex1442
02.08.2021 15:44>С чего бы RISC-V сырая архитектура? и софта уже выше крыши.
Рано называть платформу развитой тогда когда, например, тот же OpenJDK доступен только в виде интерпретатора Zero
https://github.com/openjdk/jdk/tree/master/src/hotspot/cpu
даже для того Эльбруса запилен JIT-порт
PHP тоже доступен только как интерпретатор: https://wiki.php.net/rfc/jit#proposal
c .NET Core все глухо
А вот с JS v8 jit-движком v8 получше - несколько месяцев назад добавлена поддержка risc-v
Путь к развитой платформе:
-Собрать ядро линукс, сишку, cpp, системные библиотеки
- DOOM!!! https://twitter.com/ultraembedded/status/1284515315062317061Сейчас вы находите здесь -> - портировать основной тулчейн: JS, JVM, PHP, .NEt Core, Python ( сюда же основные модули, которые использует каждый первый питонист - numpy, pandas, ...)
...
- PROFIT!11Civil
04.08.2021 01:40+2Строго говоря risc-v находится чуть дальше - в стадии оптимизации этого тулчейна по скорости.
civil@debian:~$ uname -m riscv64 civil@debian:~$ python3 Python 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20201224] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> a = np.arange(15).reshape(3, 5) >>> a array([[ 0, 1, 2, 3, 4], [ 5, 6, 7, 8, 9], [10, 11, 12, 13, 14]]) >>> a.shape (3, 5) >>> a.ndim 2 >>> a.dtype.name 'int64' >>> a.itemsize 8 >>>То есть все как выше - местами нет JIT, но постепенно и он появляется. А касательно .NET Core - он все таки не так популярен на линуксе и кому очень надо - по-прежнему есть mono, который на risc-v как-то уже работает.
amartology
02.08.2021 03:22+1Интересно насколько сейчас в принципе реальна перспектива создания своей RISC/CISC архитектуры,
Это можно сделать. Вопрос в том, нужно ли. И этот вопрос вдвойне актуален с учётом существования открытой и отлично проработанной RISC-V.
VaalKIA
01.08.2021 21:16Вы с такой болью пишете про «проёб… средства», когбуд-то не понимаете, что процессор, это не только ядро, а ещё и множество IP блоков, DDR4, PCI, IO, Кеш, куча всего и всё это разрабатывается коммандой Эльбрус и легко лицензируется другим прозводителям, а так же поддерживается не зависимо от любых санкций. Специализированное ПО и рабочие, стоят так же очень дорого и им всё равно процессор какой архитектуры делать. Фактически, очень многое из сделанного, это уже идеально вложенные силы в разработкую любого нормального процессора. И зачем тогда бучу поднимать?
vladshulkevich
01.08.2021 21:53-6а еще нет понимания различия между изделием военной техники и ширпотребом, пусть даже этот ширпотреб ламборгини или бентли. Бентлями войны не выигрываются.
Armmaster Автор
01.08.2021 22:03+2Это логика из разряда "ну мы же старались".
Давайте все эти знания и наработки команда МЦСТ применит для разработки Sparc V9 или RISC-V процессора? Они же архитектурно независимы.
byman
02.08.2021 10:19+4Насколько достоверна ваша информация о том, что DDRC (а также его PHY часть) , например , для Э-8СВ разработан в МЦСТ?
yalex1442
04.08.2021 13:27>Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора
А разве распространенные архитектуры сами же не попали в тупик - процессоры вынуждены иметь в своем составе набор сопроцессоров на все случаи жизни и даже стали появляться чипы со встроенными ПЛИС(!)
Хватит ли ресурсов у отечественных чип-мейкеров тянуть эту мету GP CPU, чтобы оставаться конкурентными?Armmaster Автор
04.08.2021 14:17Сопроцессоры и т.д. предназначены для ускорения отдельных видов workload'ов. Но какой смысл об этом сейчас говорить, если мы пока не сделали конкурентного GP CPU, для работы которого и так хватает кучи типичных нагрузок прямо сейчас в дата центрах и рабочих станциях пользователей
biohumanoid
13.08.2021 15:43У vliw процессора есть все же один плюс — в нем невозможно спустя годы найти грабли вроде spectre и meltdown.
Ошибку оптимизации в компиляторе все же проще исправить.
А вот на виртуализации все видимо еще хуже, т.к. компидятор не может знать, когда гипервизор решить прервать исполнение кода одной гостевой ос, и передать другой.
sse
01.08.2021 13:10-1В этой статье я вижу антологию домыслов. Начиная с того, что основным критерием перспективности процессоров здесь подразумевается показатель "Ватт/гигафлопс". Кто решил, что это так? Непонятно.
И заканчивая поиском заговоров в типовой схеме b2b приобретения изделий. К слову, Oracle работает так же, по запросу, продавая свои БД, бесплатная ознакомительная версия у них появилась относительно недавно, и она не содержит всех коммерческих фич вообще.
Очень хотелось бы в следующей статье увидеть факты, исследования и отсылки на авторитетные мнения.
Armmaster Автор
01.08.2021 14:58+17Здесь нет обсуждения вопроса, как правильно вести бизнес. Только техническая сторона вопроса. Критерий перспективности является то, в каких нишах Эльбрус технически может быть конкурентен. Собственно я показал, что и по абсолютной производительности, и по энергоэффективности процессоры на базе VLIW проигрывают архитектурам RISC/CISC.
sse
01.08.2021 17:22-13В большинстве военных и гражданских применений будет перспективен. Для настоящих числодробилок используют специальные устройства типа видеокарт и других акселлераторов, что касается производительности типовых приложений (особенно веб), то один раундтрип запроса между БД и сервером приложений съест все выигрыши оптимизации под конкретную архитектуру.
Сколько в итоге будет отставание производительности на практике - 20% 40%? Это все ерунда, уже давно никто не ускоряет задачи вертикальным масштабированием single core, single thread
Armmaster Автор
01.08.2021 17:59+4Ага, 20% ))
В разы отставание, иногда на порядок :
sse
01.08.2021 21:37-6Вы игнорируете то, что я пишу. И про числодробилки, и про тестирование на практических задачах, а не на синтетических тестах, и про то, что вертикальное масштабирование уже давно не основной вариант.
К счастью, вне зависимости от того, что себе там думают интернет-эксперты, "Эльбрус" развивается и будет развиваться дальше
edo1h
01.08.2021 22:07+4И про числодробилки, и про тестирование на практических задачах, а не на синтетических тестах,
как раз синтетику vliw может молотить хорошо, а вот с практическими задачами всё хуже
и про то, что вертикальное масштабирование уже давно не основной вариант.
а, ну да, эльбрус же дешёвый маложрущий проц, который идеально подходит для горизонтального масштабирования
Armmaster Автор
01.08.2021 22:10+6Что игнорирую? На базах данных Эльбрус также Интелам существенно уступает, на хабре были статьи с результатами. Горизонтальное масштабирование работает и там, и там. Только если у вас в обоих случаях по условных 32 ядра, только производительность каждого ядра в 3 раза выше, то и производительность системы в 3 раза выше.
ALXN
01.08.2021 18:56+1Полнофункциональные версии СУБД Oracle уже даже не помню сколько лет как можно скачать с их сайта, безо всяких ограничений, создав себе учетку за пару минут.
zxweed
01.08.2021 19:31+5Ознакомительная версия, которую нельзя по требованиям лицензии использовать в продуктивной эксплуатации, у Oracle всю жизнь выкладывается на сайте, обновляясь каждый мажорный релиз. Для неё не предоставляется поддержка, но никаких технических ограничений на разработку она не имеет и включает в себя практически все опции.
sse
01.08.2021 21:32-4Там нет ни RAC, ни Oracle Streams/GoldenGate, ни AdvancedQueueing, ни Flashbacks, ни Report Services, ни монитора, даже embedded java нет. Про APEX не помню, есть ли, возможно, тоже нет. В общем, можно длинный список перечислить, чего там нет
ALXN
01.08.2021 23:20+1Вы что-то путаете.
www.oracle.com/database/technologies/oracle-database-software-downloads.html#19c
Вот пример под Linux — 19.3 — Enterprise Edition. Там есть все опции. Спокойно скачивается, безо всякого «запроса».
А вы явно говорили про Express Edition, её тоже можно скачать.
Loggus66
01.08.2021 22:00Это Express? Знатно потерял время с ней, когда после первого раза выяснилось, что там не было UTF-8. В более новых вроде добавили, но несовместимость разных версий дампов с СУБД - отдельная шутка.
Antervis
01.08.2021 21:12+3Начиная с того, что основным критерием перспективности процессоров здесь подразумевается показатель "Ватт/гигафлопс". Кто решил, что это так?
вся индустрия? Масштабировать процессоры вширь все давным-давно научились, и по сути всё упирается либо в производительность однопоточки, либо в энергоэффективность. Ну, есть еще конечно финансовые критерии, но они у относительно штучных эльбрусов в еще большем дне чем перф/ватт.
crea7or
01.08.2021 13:12-16Стрёмная какая статья, а местами вообще дичь. Это же насколько часто при разработке программисты смотрят ассемблерный код чтобы понять, что пошло не так? Есть компилятор, который должен делать код - это его работа. В дебаггере тоже всё на уровне языка программирования. Программисту надо в своём языке разбираться и логическую модель приложения сделать на нём. Сишники и те раз в год в ассемблер залезают, остальным-то зачем это? Проблемы у эльбрусов такие видятся - закрытость в целом и недоступность для разработчиков-энтузиастов банально по цене.
Cykooz
01.08.2021 13:25+14С современными компиляторами очень даже приходится смотреть на ассемблер, т.к. нет уверенности, что компилятор "понял" как правильно оптимизировать код. Да, это требуется не так часто, и в основном только для тех, кто ведёт разработку на низкоуровневых языках. А ведут её преимущественно из-за скорости работы кода на этих языках. И если вдруг программа не выдаёт ожидаемой скорости, то рано или поздно (когда выверил все алгоритмы) добираешься до ассемблера и начинаешь искать в нём проблемы.
Так же бывают банальные косяки в компиляторах, когда новая версия вдруг начинает создавать медленный код на ровном месте. Просмотр ассемблера помогает увидеть причину, написать баг-репорт.
checkpoint
01.08.2021 14:38+14В статье, кстати, не упоминается тот факт, что подавляющее большинство пользовательских разработок в последние лет 10-15 ведется на интерпретирующих языках высокого уровня (Perl, php, Python, scala/java), статическое предсказание в данном случае не возможно от слова «совсем». Аналогичная ситуация с компилирующими языками типа rust и go — никто не будет создавать для этих языков оптимизирующий компилятор для всей линейки микропроцессоров Эльбрус. Даже если Эльбрус станет полностью открытым, его доля в мировом масштабе на столько мала, что разработчики языка rust никогда не узнаю о существовании такой архитектуры, а даже если и узнают — где они найдут высококлассных специалистов по VLIW, что бы создать оптимизирующий компилятор? Вероятно, что Google (создатель go) сможет потянуть такую задачу, но зачем ему весь этот гимор? В общем, полностью поддерживаю лейтмотив статьи — Эльбрус, как ЦПУ общего назначения это тупик при любых раскладах. Удел Эльбруса это числоробилка в узкоспециализированных задачах.
BugM
01.08.2021 14:47+7Как раз у языков с jit компиляторами есть шансы. Статический анализ и перекомпиляция кода идет в рантайме. Можно оптимизировать на основе реальной статистики выполнения.
Но кто напишет такой jit компилятор непонятно. Это сложно, долго и очень дорого.
Armmaster Автор
01.08.2021 16:07+6Собственно, вы абсолютно правы. В теории, JIT для Эльбруса более перспективен. На практике написать высокопроизводительный JIT для каждого из интерпретируемых языков - это колоссальная работа, вряд ли осуществимая на практике.
BugM
01.08.2021 16:16+1Зачем для каждого?
Есть типовой подход: Компилируем каждый язык в один и тот же байт код, который и передаем одному jit компилятору.
Armmaster Автор
01.08.2021 17:00+1Если коротко, то не всё так просто.
BugM
01.08.2021 17:19А кто говорил про просто? Это хотя бы реально. В отличии от "написать хороший jit компилятор для каждого языка"
Armmaster Автор
01.08.2021 18:45Боюсь, чтобы достичь перфа, этим всё и закончится.
Ну и не решит это проблем глобально. Т.е. можно какие-то углы срезать, но в итоге обычным архитектурам всё равно будем проигрывать существенно.
BugM
02.08.2021 02:48Мир как-то живет менее чем с десятком JIT компиляторов и ничего. Наверно даже штук 5 всего массовых.
Даже нейтив компиляцию по этому же пути стали делать llvm и больше ничего не нужно.
Я бы думал только в эту сторону для чего угодно нового. Может быть я не прав, но выглядит как самое перспективное направление. И гораздо дешевле компиляторов полного цикла.
Идеально достижимую производительность так не получить, но вот хорошую производительность для большого числа языков и уже написанного софта получить можно. Если не упереться в любые другие ограничения архитектуры, конечно же.
Paskin
02.08.2021 09:54В общем случае - да. Но большинство вычислений в Python делается через нативные numpy/scipy и прочие Tensorflow - которые сами по себе что-то вроде виртуального языка для обработки матриц.
beeruser
02.08.2021 01:25Ага. Пересадить «каждый» язык на общий бэкенд… ради Эльбруса, который практически нельзя купить, тем более за границей.
AamSpace
13.08.2021 15:47Квалификация специалиста до определенной степени может компенсировать недостатки архитектуры. Чтобы писать быстрый код под Эльбрус нужно знать его (Эльбруса) преимущества и недостатки. Не лезть туда, где заведомый проигрыш, совершенствоваться там, где есть выигрыш и думать, что можно сделать в "середине". Если архитектура - "проблемная", то и подготовить для нее специалистов - сложнее. А подготовить спецов это тоже дорогое удовольствие. Та самая "колоссальная работа".
Рассуждая так, примерно в 2017-м я попытался в своем ВУЗе протолкнуть идею создания курса с идеей - "Мы лучше всех умеем писать под Эльбрус" (в смысле с учетом всех особенностей Эльбруса). Были и люди, кроме меня, готовые это все делать в ВУЗе. Вышел на контакт с МЦСТ, получил понимание и поддержку (насколько это возможно для МЦСТ). Подписали декларацию о намерениях. Все уперлось в то, кто: МЦСТ или ВУЗ предоставит ресурсы (4-х проц. сервер) для разработки и проведения курса. В 2019-м я почти получил машину. Но в конце все-же сорвалось. И с тех пор ситуация не изменилась. Максимум, чем я тут смог помочь отечественному производителю, это отфильтровать и направить к настоящему времени в МЦСТ 3-х студентов, которые загорелись от меня идеей работать именно с Эльбрусами. Как-бы и винить тут особо некого. У каждого своя правда. Но правда и в том, что ситуация с ПО для Эльбрусов и специалистов, которые под него могут писать эффективный код, как мне представляется, с 2017-го лучше не стала.
Вот сейчас выделяют средства на разработку процессоров и "обвязки". Это - хорошо. Но может что-то надо выделить и на подготовку отечественных специалистов для работы с отечественным оборудованием? Чтобы они в ВУЗах уже с ними знакомились, а не с Microsoft? То, с чем ты раньше познакомился, то и будет сидеть "глубже". Пусть Эльбрус - это специфична техника. Это просто означает, что специфичные курсы для Байкала должны быть во всех ВУЗах с IT-специальностями, а для Эльбрса не во всех, а в нескольких, достаточных для заполнения специалистами ниши, которая может быть занята Эльбрусами и этим специалистам дать работу. Какое-никакое, а комьюнити начнет формироваться. А то ведь на 30-е июня 2021 г. форум Эльбруса ( https://forum.elbrus.ru/ ) с 2016 г. имел такие характеристики: Всего сообщений: 185 • Всего тем: 49 • Всего пользователей: 264. 37 сообщений в год, 3 сообщения в месяц. За месяц ситуация "изменилась": Всего сообщений: 187 • Всего тем: 50 • Всего пользователей: 270. Думаю, рыночными механизмами эту ситуацию не изменить. От теплого к холодному энергия передается только с помощью работы, а сама - никак. Дорогу осилит идущий :)
Ну и наконец, не массовая ниша это не плохо. Например, ПО проектирования цветных революций (предполагаю, что такое есть) вряд-ли обсчитывают на компьютерах общего пользования. Против такого ПО должно быть "контрПО" не уступающее по производительности, иначе можно опоздать с контрдействиями. Цена ошибки (поражения) здесь в принципе равна цене всего производства универсальных процессоров. Потому как поражение равно закрытию всего этого производства и универсальных процессоров и специфичных. Поэтому, думаю, нужны Эльбрусы и те, кто на них умеет эффективно писать не смотря на ограничения архитектуры. И направление это надо развивать "не смотря на". А массовым, ну... пусть Байкал будет. В общем я за появление курсов по изучению и Эльбрусов и Байкалов в ВУЗах (а может и школах) страны! :)
qw1
13.08.2021 15:59+1Например, ПО проектирования цветных революций (предполагаю, что такое есть) вряд-ли обсчитывают на компьютерах общего пользования
А, кстати, почему? Если это большие системы линейных или дифференциальных уравнений, то быстрее их считать на видеокартах (общего пользования!) а не каких-то специализированных чипах, которых 1000 штук на всю страну.Am0ralist
13.08.2021 16:15А майнить быстрее на асиках или на видиках?
А вставлять к процам всякие ускорители нейронок — это про то, что на старых процах общего пользования было быстрее эти расчёты делать или медленнее?
Ну то бишь, к тому, что если расчёты специфические и под них можно свою железку забацать, то быстрее таки будет она. И если больше они нигде не нужны, то встраивать их в железки общего пользования не особо смысла несёт.
И да, насколько помню из рассказов, вроде как в своё время одна небольшая троичная машинка щелкала дифуры не хуже, чем более «крутые» большие двоичные) Но это может быть и байкой.qw1
13.08.2021 16:30Выше товарищ говорил конкретно про Эльбрус, а Эльбрус это совсем не ASIC. Вот мне и интересно, какая такая специфика должна быть, чтобы Эльбрус был быстрее лучших GPU и CPU общего назначения.
И да, насколько помню из рассказов, вроде как в своё время одна небольшая троичная машинка щелкала дифуры не хуже, чем более «крутые» большие двоичные) Но это может быть и байкой
В годах 60-х это могло быть и не байкой, что какие-то умельцы придумали что-то уникальное и крутое. Но сейчас все алгоритмы хорошо изучены и всем известны. Поэтому рулит грубая сила: гигагерцы и нанометры, а что там — троичная логика или двоичная, не так важно.Am0ralist
13.08.2021 16:37Вот мне и интересно, какая такая специфика должна быть, чтобы Эльбрус был быстрее лучших GPU и CPU общего назначения.
Ну, как бы есть факт того, что суперы из них вы сами особо не построите, точнее построите не под все задачи (точнее вам построят под ограниченный список задач внешние конторы). А под часть задач — только распределённые вычислительные кластеры на базе простых железок.
А в идеале на эльбрусах сможете собрать любые системы, если осилите создание шин и т.п.
PS. при этом в них так же могут крутится те же гпу.
PPS. Я не настоящий сварщик и мимокрокодилqw1
13.08.2021 16:51Мне показалось, что фразочка про «цветное ПО» и «своевременные контр-меры» — домашняя заготовка, нацеленная на политиков, которые в вычислениях не понимают, зато распоряжаются бюджетом. Если это не так, нужно пояснение для технарей. Если так, пояснение не требуется.
Am0ralist
13.08.2021 17:00Ну тут я без понятия, единственные задачи, под которые нам точно нужны хоть какие-то свои решения — это всякие моделирования атомного оружия и прочие расчёты для впк и некоторой части науки.
Ну и там всякие модули «ангара», собственно, как понимаю, под это создаются. Про то, что на эльбрусах создавали блейды тоже была инфа.
А вот что возможно там какие-то социологические расчёты гоняются — я не встречал рассказов ещё)
qw1
13.08.2021 17:27единственные задачи, под которые нам точно нужны хоть какие-то свои решения — это всякие моделирования атомного оружия
Для меня это не очевидно. Сколько нужно Эльбрусов, чтобы заменить одну NVidia RTX 3090? И есть ли смысл менять (кроме распила денег, конечно)?
Am0ralist
13.08.2021 17:40-2Сколько нужно ксеонов, что бы заменить газовую плиту?
Я там даже выше писал, что в таких решениях могут даже и видики дополнительно ставится обычные, а вот как вы собираетесь считать на видеокарте без процессора и чипсета — я так и не понял.
qw1
13.08.2021 19:25-1На чём считать? На «компьютерах общего пользования», от которых почему-то хочет уйти автор комментария.
Am0ralist
14.08.2021 10:39Ок, покажите хоть один супер собранный «на обычных» компьютерах общего пользования?
И какое место в топе для науке он займёт?
А так же, кто вам поставит это дело под такие задачи? Ну те же суперы здесь собирались зачастую только под другие задачи.
Или вы всерьёз заявляете, что можно на обычном домашнем железе собрать супер, способный ворваться в топ 500 хотя бы?
qw1
14.08.2021 12:46Я хочу сказать, что суперкомпьютер на Эльбрусах не имеет смысла. Если не согласны, приведите пример реализованного или планируемого проекта. Посмотрим, сколько у него ядер, терафлопс. Сравним с обычной обывательской RTX 3090
Am0ralist
14.08.2021 13:23А что мешает уже в суперкомпьютер в каждый модуль поставить ту же RTX3090 да не одну?
Извините, но покажите мне ОС, которая работает исключительно на видеокарте. Ну то есть вот видик, к нему подключили питание и запустили ОС без всего прочего.
Есть такая? А почему нет?
Ну серьёзно, вы правда заявляете, что обычный видик может что-то сам посчитать без ЦПУ и платы?
Если нет, то понимаете ли вы разницу между суперкомпьютером и распределённым вычислительным кластером на декстопном железе?
qw1
14.08.2021 14:37-1Если основная числомолотилка — GPU, то вообще без разницы, на чём строить хост. Хоть на Xeon-ах, хоть на Байкалах. А то ведь автор выше написал:
Поэтому, думаю, нужны Эльбрусы и те, кто на них умеет эффективно писать не смотря на ограничения архитектуры. И направление это надо развивать «не смотря на». А массовым, ну… пусть Байкал будет
Это мне и не понятно (понятно, с т.з. освоения бюждета, но не более).
Am0ralist
14.08.2021 14:52Извините, но разговор упорно напоминает:
— вы что нибудь понимаете в теме?
— нет, но мнение имею!
Я вас сколько раз спросил: вы понимаете разницу между суперкомпьютером и распределённым вычислительным кластером (а-ля майнинг-ферма или амазоновское облако?)
Если для вас нет разницы и вы отказываетесь её видеть, то это означает только, что вы сильно не в теме и не хотите погружаться. А вот высказаться очень хотите.
Реальность такова, что суперкомпьюетры хорошо заточены на некоторый спектр задач. Типа CFD.
А кластеры — позволяют делать другие.
Так вот, разница — в интерконнекте. И для суперов вам нужны специфические чипы и шины, чтоб обеспечивать его максимально быстрым. И вот их вы — просто так не получите. Всё. Ну купите вы тысячи процов домашних и тысячи видюх. Как вы это будете объединять в суперкомпьютер, не имея для этого специфического железа? Никак, блин. Никак!Если основная числомолотилка — GPU
Ну если вам не нужно считать связных данных и результаты, то да.
В противном случае то, что вы написали — это рассказ, что майнить можно и не на суперах. Ну, с этим никто и не спорит.
Да, процентов 90 или даже более задач могут этого не требовать.
Но вот все погодные, как читаешь, делают именно на суперах. Не на обычных кластерах, не в облаке амазона или там майкрософат. Строят очередные суперы, дабы симуляции считать и прогнозировать всё лучше и лучше.
На суперкомпьютерах. Потому что.
И что предлагаете вы? Купить тысячу 3090, пихнуть в тредриперы и получить что? Майнинговую ферму или там обучалку нейронок. Но как только потребуется активная пересылка данных, то вы упрётесь в то, что сеть будет съедать время быстрее, чем молотить.
Ну как это связано с суперами, а?
qw1
14.08.2021 16:46Если вопрос только в интерконнекте, то почему Эльбрус? На Байкалах его нельзя сделать? Я задавал вопросы по посту AamSpace (что именно Эльбрус спасение, а не ничто другое), а вы уводите тему в сторону.
Am0ralist
16.08.2021 15:03На Байкалах его нельзя сделать?
Может и можно, надо сравнивать все параметры, кроме производительности на ядро, там ещё надо и шины, каналы памяти и прочее.
У эльбрусов до 4 процессоров на плату с 4 каналами на проц, вроде было, байкал же энергоэффективное решение.
В итоге, не очень понятно, как вы будете собирать на нём производительную систему, где данные будут активно гоняться и обрабатываться туда сюда.
Не, может и могут, но, подозреваю, проще тогда попытаться новые армы взять в лицензию, но… что там будет с ограничением по лицензиям на использование данных архитектур?
Civil
15.08.2021 00:48Мне кажется, из контекста очевидно. Или по-вашему надо каждый раз перечисляя то на чем делаются вычислений указывать все, вплоть до марки топлива на электростанции? (вашу логику можно дальше легко развить - вы не указали блок питания, чем питать будете? А еще не указали кабель питания. А еще - откуда появляется электричество, а потом откуда оно появляется там и так до бесконечности).
Am0ralist
16.08.2021 15:17Мне кажется, из контекста очевидно.
Из контектста, человек утверждает, что можно либо на одном видике считать что-то, либо таки на чём-то собирать, но на чём не признаётся.
Выше вон предложил на байкалах. Я лезу в байкал и вижу 3 × PCIe Gen3 (8+4+4 линии), 2 × DDR3/DDR4-2400 64 и не вижу возможности объединять по нескольку процессоров.
В это же время вижу, что для 16С заявлены 32 линии PCIe 3.0, а 4 канальная DDR4-2400 ECC уже в 8С была, при этом на плате до 4 процессоров.
В итоге, вы оба вдвоём утверждаете, что в любых расчётах и пересылках данных подобные параметры не важны или что?
Я не очень понимаю ни его, ни ваши тезисы.
Ну вот есть у вас одна 3090, посчитайте мне модель обтекания воздухом тела?вашу логику можно дальше легко развить
Так нет же, это ваша логика. Это вы тянете к обсуждению как можно организовать вычисления левые пункты, а отбрасываете значимые.
Мне оную не приписывайте, иначе я сведу всю вашу логику к тому, что если на одном видике нельзя посчитать, то задача не нужна.
Ибо я так и не добился ответа, как же именно вы будете организовывать работу вашей железке в сферическом вакууме, который мне навязывают для обсуждения вместо ответа на том, как в реальности будет это всё работать.
Сильно выше хотя бы человек пытался про 100G энтернет поговорить, игнорируя, что современные шины а) ещё быстрее б) не факт, что энетренет 100г комутаторы смогут обеспечить работы в условиях, когда 50% узлов передают одновременно данным другим 50% узлов без задержек и падения скорости.
С учётом, что в суперх важно именно это — возможность гонять вот эти все подсчитанные данные по всему суперу, а не независимые вычисления, то я так и не вижу ответа на свои вопросы, а только методичное сворачивание на прямую подмену тезисов.
Civil
16.08.2021 17:28-1Из контектста, человек утверждает, что можно либо на одном видике считать что-то
Не соглашусь, мне очевидно что к видеокарте прилагается и другое железо. Мне кажется что Вы тут дальше заниматесь буквоедством, в том формате как задаете вопрос. Если хотите узнать что имеет в виду человек - пишите вопрос прямо, а не начинайте докапываться до слов.
В итоге, вы оба вдвоём утверждаете, что в любых расчётах и пересылках данных подобные параметры не важны или что?
Покажите цитатой пожалуйста, где я что-либо утверждал в таком духе. Я очень настаиваю.
Я не очень понимаю ни его, ни ваши тезисы.
Мой тезис в том, что Вы ведете себя некрасиво, по отношению к @qw1 (на самом деле и к другим собеседникам в других тредах), потому что придираетесь к формулировке, вместо того чтобы задавать правильные вопросы.
Пример тут "без процессора и чипсета — я так и не понял." (заметьте, что я отвечаю ровно на это сообщение, а не на другие в треде) - это и есть буквоедство, но вместо "ок, а какую конфигурацию сервера вы предлагаете использовать?" вы выдали именно то что я процитировал.
Так что хочу дать непрошенный совет - не делайте так, это выглядит очень неприглядно и негативно влияет на развитие дискуссии (сводит ее дальше, извините, в срач).
Касательно остальных вещей - извините, но я не собираюсь пытаться разобраться что конкретно вы имели в виду в этом треде, примерно начиная с сообщения на которое я отвечал. Просто потому что за бесполезными высказываниями найти нить спора и аргументы сторон мне решительно лень.
Ибо я так и не добился ответа, как же именно вы будете организовывать работу вашей железке в сферическом вакууме, который мне навязывают для обсуждения вместо ответа на том, как в реальности будет это всё работать.
Также предлагаю показать цитату где я что-то подобное утверждал в комментариях к этой теме или настаиваю что вы меня с кем-то спутали и рекомендую извиниться за это.
Am0ralist
16.08.2021 17:43Мне кажется что Вы тут дальше заниматесь буквоедством, в том формате как задаете вопрос.
Так вопрос в каком именно железе она воткнута? В обычный декстоп? А как тогда данные сливаются и пересылаются друг другу?
Простой вопрос. Что делать, если накладные расходы на передачу данных туда сюда сожрут все профиты наличия крутого видика.
Я написал сразу, после этого пошли подмены тезисов и демагогия.Вот мне и интересно, какая такая специфика должна быть, чтобы Эльбрус был быстрее лучших GPU и CPU общего назначения.
Ну, как бы есть факт того, что суперы из них вы сами особо не построите, точнее построите не под все задачи (точнее вам построят под ограниченный список задач внешние конторы). А под часть задач — только распределённые вычислительные кластеры на базе простых железок.Покажите цитатой пожалуйста, где я что-либо утверждал в таком духе. Я очень настаиваю.
Ну как же, из контекста очевидно:Или по-вашему надо каждый раз перечисляя то на чем делаются вычислений указывать все, вплоть до марки топлива на электростанции? (вашу логику можно дальше легко развить — вы не указали блок питания, чем питать будете? А еще не указали кабель питания. А еще — откуда появляется электричество, а потом откуда оно появляется там и так до бесконечности).
Когда вы заявляете, что вопрос в какую именно железку будет запихнут данный видик сравниваете с блоком питания, отрицая, что это основной вопрос в том, как расчёты параллелить будем, если задача на обычной распределённой системе не будет хорошо считаться из-за гигантских штрафов на обмен данными между нодами?
Ах да, я забыл, выдумывать аргументы за других а так же экстраполировать в любую сторону по желанию же только вам можно. Ведь у меня все аргументы касались того, что мы обсуждаем не сферическую производительность одной видеокарты, а рассчёты на суперкомпьютерах, производительность в которых не путем умножения сваленных стопокой видеокарт получается. И не суммирование производительности отдельных нод.
А вы пришли и попытались нивелировать аргумент рассказом про блоки питания и электричества, до которых я по вашему обязан был дойти. То есть выдумали аргумент и смело победили.Мой тезис в том, что Вы ведете себя некрасиво, по отношению к qw1 (на самом деле и к другим собеседникам в других тредах),
О да, когда тыкаешь в то, что они подменяют тезисы и уводят в сторону активной демагогией, то это ты плохой. Прям таки оскорбляешь их требованием логичных ответов.Вы выдали именно то что я процитировал.
То есть то, что человек до этого прямо сравнил расчёт на процессоре с расчётом чисто на видике вы проигнорировали?
Вот тут, конкретно:Сколько нужно Эльбрусов, чтобы заменить одну NVidia RTX 3090?
Причем сделал это явно после указания, что решение в супере может быть совместным:PS. при этом в них так же могут крутится те же гпу.
Ещё раз, как вы собираетесь что-то большое считать на куче ГПУ, если у вас нет простой материнской платы под это дело. Ну не продали вам на суперкомп для военки готовые железки. Я жду.Касательно остальных вещей
Итого, очередная демагогия, когда на аргументы одной стороны кладётся болт, ибо надо облить другую сторону.
Браво. В ответ я могу так же дать вам непрошенный совет по направлению. Ибо вам былорешительно лень
думать и читать, а вот лезть с ответами, выдирая отдельные фразу из контекста треда, а так же придумывая за другого трешаргументы — не, не лень.
Civil
16.08.2021 18:15-2Так вопрос в каком именно железе она воткнута? В обычный декстоп? А как тогда данные сливаются и пересылаются друг другу?
Так пишите эти вопросы явным образом @qw1с которым вы общаетесь на эту тему. Не юлите фразами подобными той, что я привел.
А вы пришли и попытались нивелировать аргумент рассказом про блоки питания и электричества, до которых я по вашему обязан был дойти. То есть выдумали аргумент и смело победили.
Перечитайте что я написал. Я просто вижу Ваше поведение в других тредах и решил попытаться указать на его проблемы, так как мне со стороны читая ваш диалог кажется очевидным, что начаниается проблема с вашего конкретного тезиса (более того, это было уже не первый раз и я на это Вам указывал в других темах). Ваше дело конечно как себя вести.
То есть то, что человек до этого прямо сравнил расчёт на процессоре с расчётом чисто на видике вы проигнорировали?
Да, проигнорировал, потому что для продолжения дискуссии можно было бы ожидать от Вас вопросы по существу, а не попытку придраться к словам.
Итого, очередная демагогия, когда на аргументы одной стороны кладётся болт, ибо надо облить другую сторону.
Я неоднократно вижу подобное поведение с Вашей стороны в комментариях к разным темам и искренне считаю что это призвано в первую очередь помочь Вам понять почему же люди отвечатют не на то, что Вы имеете в виду. Остальное - Ваши домыслы, я специально акцентирвал внимание только на выражении мыслей, чтобы как раз таки избежать ситуации, что Вы считаете меня участником вашего срача выше.
Am0ralist
17.08.2021 17:39Так пишите эти вопросы явным образом qw1с которым вы общаетесь на эту тему
Я ему прямо задавал вопросы. Я ему криво задавал вопросы, я ему уже начал аналогии приводить. Как ещё мне задать ему вопросы, что б он на них начал отвечать, а не рассказывать про рассчёт на одном видике 3090, которая порвёт все суперы, вставленная в обычный домашний комп?А так же, кто вам поставит это дело под такие задачи? Ну те же суперы здесь собирались зачастую только под другие задачи.
Или вы всерьёз заявляете, что можно на обычном домашнем железе собрать супер, способный ворваться в топ 500 хотя бы?Перечитайте что я написал.
Перечитайте ответы вам и другим людям.
Юлит здесь конкретно один чел, а вы его пришли защищать, не прочитав даже ветку и вырывая один коммент из всего треда.потому что для продолжения дискуссии можно было бы ожидать от Вас вопросы по существу, а не попытку придраться к словам.
Я уже указал, что попытка аннулировать тезис тем, что вы не хотите на него отвечать не означает, что там был вопрос не посуществу.
Я зада простой вопрос: как человек будет осуществлять рассчёты на конкретном видике. И несколько раз уточнял для наглядности тезисов о том, что он игнорирует реальность, в котором данный видик должен где-то стоять, получать откуда-то данные и передавать куда-то данные. Причём должен делать это очень быстро, иначе смысла от одного видика не будет никакого для решения этих задач.
То, что лично вы тоже делаете вид, что не понимаете вопрос — ну, это ваше дело.Я неоднократно вижу подобное поведение с Вашей стороны
О да, с десятком демагогов, которые на прямые логические вопросы вечно подменяют тезисы и пытаются увести от конкретики на обсуждение сферического коня в вакууме.
Извините, но десять раз задавать один и тот же вопрос, дабы игнорирующие его таки соизволили ответить — скучно и я начинаю выставлять их идиотами, которые не могут ответить даже на простой вопрос:
куда же будет воткнута данная видеокарта, которая порвёт все суперкомпьютеры, в реальности.
А тут приходите вы с «лень всё читать» и начинаете учить меня, как я должен общаться с известным мне списком демагогов, которые ведут себя раз за разом одинаково.
Да никак, можно только если десять раз в ветке заменить все комменты на один вопрос, игнорируя любые виляния.
Civil
17.08.2021 19:10-1Я ему прямо задавал вопросы. Я ему криво задавал вопросы, я ему уже начал аналогии приводить. Как ещё мне задать ему вопросы, что б он на них начал отвечать, а не рассказывать про рассчёт на одном видике 3090, которая порвёт все суперы, вставленная в обычный домашний комп?
На момент когда я Вам там отвечал я не видел никаких корректно заданных вопросов. О чем Вам и было сказано.
Юлит здесь конкретно один чел, а вы его пришли защищать, не прочитав даже ветку и вырывая один коммент из всего треда.
Перечитайте внимательно что я сказал. И прекращайте уже приписывать то, что я не говорил (либо давайте пруф о том что я его защищал, хинт: указание на проблемы коммуникации с Вашей стороны не являются защитой другой стороны).
Я уже указал, что попытка аннулировать тезис тем, что вы не хотите на него отвечать не означает, что там был вопрос не посуществу.
А я повторю, кажется в третий раз: мне все равно был ли там вопрос по существу или нет. Я читал вашу переписку, следил за ней и заметил что Вы делаете некорректные высказывания в отношении своего оппонента, на что обратил Ваше внимание. Было бы такое с его стороны - этот тред я бы вел с ним.
То, что лично вы тоже делаете вид, что не понимаете вопрос — ну, это ваше дело.
Давайте пожалуйста пруф того, что я не понимаю вопрос. Я его игнорирую, о чем я сразу заявил, о понимании я ничего не говорил и вопрос специально отказываюсь обсуждать с Вами.
Извините, но десять раз задавать один и тот же вопрос, дабы игнорирующие его таки соизволили ответить — скучно и я начинаю выставлять их идиотами, которые не могут ответить даже на простой вопрос:
А Вы уверены, что достигаете именно такого результата не только с Вашей точки зрения? Мне вот со стороны кажется, что это Вы начинаете разводить демагогию, в которой обвиняете других.
А тут приходите вы с «лень всё читать» и начинаете учить меня, как я должен общаться с известным мне списком демагогов, которые ведут себя раз за разом одинаково.
А Вы предлагаете ничего не делать, если мне очевидно что в таком ключе Вы только разводите срач? Но если Вы не готовы поменять свой стиль поведения, то заставить это сделать я Вас конечно же не могу.
amartology
14.08.2021 10:20Например, ПО проектирования цветных революций (предполагаю, что такое есть) вряд-ли обсчитывают на компьютерах
Вы разве не знаете? Оно на чипах из вакцин от ковида считается.
tbl
01.08.2021 19:10Пишем интерпретатор, берем третью проекцию Футамуры, получаем компилятор. Собственно, GraalVM уже умеет это делать. Постоянное профилирование кода и перекомпиляция по его результатам идут в комплекте. Проблема в том, что все это целиком выглядит как долгострой, и непонятно, когда можно будет использовать в продакшене. Хотя некоторые куски проекта уже допилили и используют в openjdk.
Civil
02.08.2021 19:11+1А были чем-то похожие идеи. Даже две реализации. Правда там решили не для языков делать, а делать бинарную трансляцию (с анализом, оптимизациями на лету и проичими плюшками) на уровне firmware.
Онда попытка была для x86 - процессор назывался Transmeta Crusoe. Про него можно почитать в том числе и бенчмарки (про тот же совет гонять их несколько раз, чтобы транслятор прогрелся). Собственно идея была хорошая, была воспринята с энтузиазмом, но процессоров от Трансметы очень давно не видно, потому что оказалось все не так радужно.
Вторая попытка была для ARM - назывался процессор nVidia Tegra K1 64-bit (ядро называлось Denver), которое потом даже получило некоторое развитие. Они про микроархитектуру писали мало, по сути есть только статья на anandtech про планшет на первом поколении этой тегры (Nexus 9 Review), статья на anandtech про Xavier (Investigating NVIDIA's Jetson AGX) и доклад на IEEEевской конференции (Denver: Nvidia's First 64-bit ARM Processor), за paywall'ом, про первое поколение архитектуры. Они продержались дольше, сделали несколько поколений своей архитектуры, но во всех случаях по эффективности она уступала ARM'овским Cortex'ам (у Xavier производительность получилась чуть лучше чем у Cortex A75 при значительно большем энергопотреблении и большей площади чипа). И хоть официально они ее и не хоронили, но следующие поколения своих процессоров будут делать уже на обычных Cortex'ах.
numas13
01.08.2021 14:51+4Аналогичная ситуация с компилирующими языками типа rust и go — никто не будет создавать для этих языков оптимизирующий компилятор для всей линейки микропроцессоров Эльбрус.
Rust уже есть на e2k. Хотя ещё есть что улучшать.
checkpoint
01.08.2021 15:13И какова эффективность кода полученного таким компилятором? Для Эльбруса есть почти все, что можно скомпилировать из C/C++. Главный вопрос — создание оптимизирующих компиляторов, а не просто чтоб было для галочки.
numas13
01.08.2021 15:22+2Там используется бекенд компилятора lcc (того самого, что компилирует C/C++), так что в идеале должен получится такой же эффективный код, но на данный момент это не совсем так. Как я уже написал выше, есть что улучшать.
crea7or
01.08.2021 14:58+2Perl в 2021 году? В остальных генерация идёт в байткод давно. И Java затаскивали на Эльбрус, кстати. Если какой-то язык прям по команде интерпретирует, там про производительность речь не идёт вообще (я таких и не знаю). Чего причетать-то - не вас же заставляют чтоо-то делать под Эльбрус.
BugM
01.08.2021 15:06+2Если какой-то язык прям по команде интерпретирует, там про производительность речь не идёт вообще (я таких и не знаю)
Bash же
checkpoint
01.08.2021 15:20+1В том-то и и дело что вынуждуют, путем насильственного пропихивания серверов на Эльбрусах в госструктуры, и удивляются почему написанный ранее код не справляется с задачей — ведь Эльбрусы они крутые числобробилки, от их внедрения все должно только улучшиться! :)
PS: Perl я привел в качестве примера, но на Perl-е написано дохемного всего и это всё переписывать никто не собирается.
creker
01.08.2021 16:11+1никто не будет создавать для этих языков оптимизирующий компилятор для всей линейки микропроцессоров Эльбрус
В Go поддержка новых архитектур это инициатива общественности. Недавно было одобрено добавить поддержку loongarch64 для новых китайских процессоров. Патчи уже полетели. Так что, если будет желание и ресурсы, поддержка будет. Google здесь вообще не при чем.kolkov
02.08.2021 16:10По идее добавить новую архитектуру в Go не очень сложно, но вот оптимизацию хорошую сделать, это будет не просто. В Go так же важна и скорость компиляции, он работает, как интерпретатор по скорости. Нажал выполнить, и можно смотреть результат, а не собирать проект часам, как на многих других языках. Проблемы есть, но они решаемы ИМХО, было бы желание.
devzona
01.08.2021 17:02Эльбрус своими ногами растет еще из времен СССР. Скорее всего, когда запретили проводить испытания ядерного оружия, потребовался вычислительный кластер, для расчета имитации ядерных испытания. Если мы будем исходить из сугубо прикладной задачи имитационного моделирования, то архитектура VLIW подходит как раз отлично. Написали одну программу, запустили ее, и пусть пару недель вычисляет. После развала СССР оставшиеся чертежи решили реанимировать, так получился Франкенштейн под гордым названием - Эльбрус. Изначально все задумывалось для совершенно других задач, а нынешние политики решили, что и так сойдет.
Удел Эльбруса это числоробилка в узкоспециализированных задачах
Это моно-задача имитационного моделирования под специализированный кластер, и совершенно несовместима с идеей "вычислений в облаке".
OpenA
16.08.2021 06:52+2Во первых советские эльбрус-1/2 были суперскалярными ОоО циск архитектурами.
Во вторых идеи его разработчиков (сделать машину с высокоуровневым языком в качестве базового) никак не ограничивались какой то одной сферой применений, его (если верить статьям с хабра) вообще можно было спокойно приобрести любому институту не связанному с военкой, проблема только в том что у него было водяное охлаждение которое едва справлялось и поэтому нужны были в довесок особые условия в помещении.
И повидимому в связи с этим решили сделать эльбрус-3 на подобии машины карцева, которая те же 2оп делала простым указанием алу0,алу1 и была гораздо энергоэффективней.
Честно говоря не понимаю эти постоянные кивания на военных, интернет и gps создавались для военных целей как это мешает их использовать в гражданской сфере?
Я понимаю еслиб в ассемблере были какие нибудь специальные команды вроде "есть", "так точно" и "доложить", и к слову говоря симуляция ядерных испытаний это не военная задача и занимаются ей профильные институты с вполне себе гражданскими сотрудниками.
devzona
18.08.2021 03:24"Честно говоря не понимаю эти постоянные кивания на военных, интернет и gps создавались для военных целей как это мешает их использовать в гражданской сфере?"
Абсолютно согласен с автором поста о бессмысленности и бесперспективности использования процессора Эльбрус для гражданской сферы. Подходы к построению систем для военных и граждан принципиально различаются. По факту у нас работает только два пути: изначально разработано для военной сферы, и только ими же и используется; разработано для гражданской сферы, с изменениями и дополнениями используется в военной сфере. Процессоры Intel установлены на множестве военной техники, телескоп Хаббл летает с процессором Intel Pentium 4 на борту. Это конечно же не те процессоры, которые установлены в миллионах домашних ПК, а доработанные с учетом надёжности и защиты для военной сферы. Аргументы про разработку Интернет и GPS не имеют никакого отношения к данной теме, по следующим причинам:
1) Это американская история успеха, и к российским реалиям она не имеет никакого отношения. Подобных примеров для СССР или РФ я не знаю, если Вы знаете, с удовольствием об этом услышу от Вас.
2) Интернет это не товар или даже не услуга, а проект и чертеж. Его никто не производит, его не нужно каким то образом поддерживать.
3) С GPS такая же история, это не товар, а услуга. В вашем смартфоне установлен совсем другой чип, и он принципиально отличается от чипов которые используют военные.
Вам в список можно было добавить разработку атомной бомбы, которая в последствие превратилась в мирный атом в виде атомных электростанций. Но в этом случае и в случае с Интернет и GPS, мы имеем дело с изобретениями от военных, которые легли в основу разработки гражданских систем. Примеров с использованием конечных устройств (разработанных изначально для военных), одновременно для военной и гражданской сферы попросту нет.
qw1
18.08.2021 10:41-2В целом согласен, но я бы сделал такую поправку:
Военная технология взлетает в гражданской сфере только в том случае, когда она передаётся другой компании, с другой бизнес-моделью. Та же МЦСТ заточена на гос. кормушку и по-другому работать не сможет. А вот когда технологию (тот же GPS) принимает компания (производитель смартфонов), которая знает, как её успешно продать людям, только тогда возникает успех.
beeruser
01.08.2021 14:32+12Стрёмная какая статья, а местами вообще дичь.
Важная и правильная статья.Программисту надо в своём языке разбираться и логическую модель приложения сделать на нём.
Да, если только его совсем не волнует достижение оптимальной производительности.Сишники и те раз в год в ассемблер залезают, остальным-то зачем это?
Странно, я как сишник смотрю в ассемблер каждый день.
Как вы предлагаете разбираться с крешдампами?
Там код оптимизированный и дебаггер не показывает переменные и прочее.
А у Эльбруса всё максимально заинлайнено и раскрыто.
Armmaster Автор
01.08.2021 15:00+15Как бы я об этом и написал как раз - большинство программистов в ассемблер не лазят. А без этого вы на Эльбрусе перформанса не получите. Что и является большим недостатком. Этому приличная часть статьи посвящена
Semy
04.08.2021 00:11+2"Это же насколько часто при разработке программисты смотрят ассемблерный код чтобы понять, что пошло не так?"
Вы не поверите...
JackKatch
01.08.2021 13:34+6Не скажу что Эльбрус это тупик, но по моему, какой нибудь Мипс, Арм (например), в количестве как трусов на рынке, был бы предпочтительней. А по поводу совместимости с x86 хотелось бы спросить, в чем тогда заключается импорто-замещение? В запуске Фотошопа на Эльбрусе? Думаю так, пусть военные и кто там ещё играются с Эльбрусом, а для массового потребления нужен простой и дешевый процессор. А быстродействие дело наживное, тем более, что нужно оно не везде и современный код быстродействие современных x86 пожирает очень быстро.
ctacka
01.08.2021 16:25Сделать процессор для массового рынка очень сложно. Лучше уж начать с универсальных процессоров для военных, для гос-датацентров, и уж тогда смотреть в сторону массового рынка
lorc
01.08.2021 17:11+2Чем гос-датацентр отличается от обычного датацетра? Там программы работают не на java, python, PHP, go? Или может им Oracle/Postgres не нужен?
ky0
01.08.2021 19:36+6Тем, что оплачивается из чужих карманов, а значит - эффективность не важна.
Медленные? - добавим ещё стоек. Горячие? - побольше кондеев. Не взлетело? - выделим ещё денег на очередную итерацию.
ctacka
01.08.2021 20:13Им нужна сертификация, и ради сертификации какого-нибудь ФСТЭК или ФСБ они готовы жертвовать эффективностью. Плюс у них вполне определенный стэк, возможно им оракл и не нужен, и не будет нужен. И они могут крутить одну версию СУБД годами, особенно если это изолированные контуры.
Тоже самое и с военными - они могут позволить переплачивать за отечественные процессоры, могут свои программы под него собирать и разрабатывать.
А обычный потребитель зачем будет покупать отечественный процессор, на котором не всё запускается, и который еще и стоит дороже?BugM
01.08.2021 20:29+8И как итог получаем неэффективный и вероятно дырявый софт в госсекторе и около.
Неэффективный потому что особый стек, древние версии, деньги не считают. Смысла и способа делать эффективно нет.
Уязвимости хорошо находятся и исправляются в открытых и массово используемых экосистемах. В закрытых и никому не нужных, за исключением госов и военных, экосистемах уязвимости могут жить годами и десятилетиями. Никто не заинтересован в их поиске и исправлении. При этом потенциальный противник спокойно купит/украдет весь софт и железо этой экосистемы и запустит туда хороших пентестеров. Он заинтересован в поиске уязвимостей.
Зато все сертификаты будут идеальные. Тут возразить нечего.
Это точно то чего мы хотим добиться?
ctacka
01.08.2021 21:08-1Вопрос концептуальный.
Во-первых, у государства много уникальных задач, для которых не существует открытых и вообще коммерческих систем (потому что рынка нет). Во-вторых, возможности потенциального противника запросто купить закрытый софт, мне кажется, преувеличены, если это гостайна. Ну и сертификация как раз и нужна для поиска уязвимостей, это же не просто бумажка (по крайней мере как задумано, как это реализуется в нашей стране, я не знаю).BugM
01.08.2021 21:30+6США на зря отдаёт военные разработки корпорациям. Микрософт самые известные. Я не думаю что они ради госконтрактов используют что-то совсем особое вместо своих типовых решений.
Гостайна в 21 веке? Которая влезет на любой носитель или облако? Вы сами-то верите что она продержится дольше одной недели? Типичная security though obscurity. Вроде все уже в курсе что это не работает?
Я сталкивался с российскими сертификатами. Сложилось впечатление что это про бумажки и деньги, а не про код. Одна только невозможность легально выпустить патч безопасности для сертифицированного софта за сутки чего стоит.
ctacka
02.08.2021 15:23По-вашему выходит, что у США все системы открытые? О чем тогда говорил Сноуден, PRISM, вот это вот всё? Да и тот же Майкрософт вполне может работать на оборонных заказов без опубликования детальной информации. У нас же тоже все эти системы разрабатывают какие-то приближенные НПО (возможно, наполовину государственные, наполовину родственников генералов).
Гостайна в 21 веке продолжает работать, потому что уже 10 лет мы не знаем, что там в АНБ происходит, например, а кода PRISM до сих пор не нашли. В конце концов, никто не хочет быть осужденным за шпионаж за то, что выложил секретные документы в облако.
Я не сталкивался с российскими сертификатами, но могу допустить, что там действительно очковтирательство и просто кормушка для приближенных.
Тем не менее, от этого задача создать коммерчески успешный массовый процессор не становится легче задачи создать специальный процессор для нужд госухи и оборонки, создание такого процессора не решит описанных выше проблем.BugM
02.08.2021 17:51Где вы прочитали про все открытое? Я писал про стандартные. Стандартные для МС, например. Они достаточно велики чтобы их внутренние стандарты были хороши.
Вы же понимаете разницу между крупнейшей корпорацией и карманной конторой? По уровню разработки, внутренних инструментов, разработчиков и всего такого?
Внутренние системы корпораций очень часто или базируются на открытых решениях или переводятся в опенсорс частями. Это повышает безопасность и удешевляет разработку.
Ну то есть вы верите в security through obscurity . Это печально. Нет ни одной причины в это верить в 2021 году.
Так задача создать уникальный процессор просто не нужна. Надо купить/взять что-то типовое и делать. Арм, Риск5 отличные кандидаты.
Я тут уже три сообщения распинаюсь почему такой процессор неиспользуемый нигде больше плох со всех сторон. Уязвимости искать некому, нанимать сложно, софта нет, качество софта ниже плинтуса и тому подобное. И при этом нет ни одного плюса.
DistortNeo
01.08.2021 13:43+9В реальной жизни невозможно статически проанализировать код настолько, чтобы максимально плотно упаковать широкие команды.
Я бы сказал, что сама по себе статическая оптимизация и упаковка команд — тупиковое направление. Например, в реальных сценариях время доступа к памяти недетерминировано, время выполнения некоторых команд (например, деление) тоже может различаться. И если процессор с OoO выполнением команд сможет эту ситуацию быстро разрулить, то VLIW будет просто ожидать.
Аналогично с branch prediction. Статическая оптимизация предполагает, что предпочтительная ветка определяется на этапе компиляции. Но в реальности всё зависит от данных. В процессе выполнения программы ситуация может много раз меняться, и процессоры с аппаратным branch prediction могут быстро подстраиваться под ситуацию.
NeoCode
01.08.2021 14:27Ну если в программе есть обычный цикл, то вероятность повторения итерации все равно выше чем вероятность выхода из цикла. Аналогично, вероятность исключения всегда ниже чем вероятность нормальной работы. Поэтому не вижу ничего плохого в том, чтобы в коде команд ветвления зарезервировать один бит для указания вероятности перехода.
DistortNeo
01.08.2021 15:06Ок. Примените теперь рассуждения для такой практической задачи, как сравнение строк.
NeoCode
01.08.2021 16:05+1while(*s1 && *s2) { // вероятность цикла > 0.5 if(*s1 != *s2) // вероятность неравенства > 0.5 return false; s1++; s2++; } return true;
Вероятность цикла всегда больше, в т.ч. и для сравнения строк, потому что на практике строки как правило не пустые. Вероятность сравнения на равенство стремится к нулю, на неравенство к единице — потому что две произвольные ячейки памяти скорее всего не равны. Вообще, вероятность прямого (неинвертированного) срабатывания if с простым условием, а также блока case в switch в среднем меньше 0.5, потому что это как правило обработка особых случаев, которые мы «выхватываем» из множества всех возможностей (и соответственно else — больше 0.5). Для компилятора нет никаких проблем оценить вероятность сложносоставного условия на основе предположений о вероятностях простых условий, входящих в сложное.BugM
01.08.2021 16:20+6Вы только что убили производительность кода сравнивающего почти всегда одинаковые строки. Да, такой код есть и его много.
Вы одновременно убили производительность сравнения строк размером в 1-2 символа. Такой код тоже есть и его тоже много.
С учетом что это библиотечная функция поправить это простым способом невозможно. Остается или мириться или писать неприятные костыли с протекающими абстракциями.
DistortNeo
01.08.2021 16:49+4Для компилятора нет никаких проблем оценить вероятность сложносоставного условия на основе предположений о вероятностях простых условий, входящих в сложное.
Проблема не оценить вероятность сложносоставного условия. Проблема в простых предположениях о данных. При статической оптимизации это просто гадание на кофейной гуще. Вы взяли некоторое предположение о данных и на основе этого предположения сделали вывод. Отлично. Но если вы с предположением ошиблись, то на практике получите падение в производительности.
А вот процессоры с предсказанием ветвлений такого недостатка лишены. После нескольких итераций на реальных данных предсказатель делает вывод и следует ему. Код в итоге получается одинаково эффективный как для только коротких строк, так и для длинных с одинаковым префиксом.
qw1
01.08.2021 22:22+3Ну если в программе есть обычный цикл, то вероятность повторения итерации все равно выше чем вероятность выхода из цикла
Слишком грубое предположение. Современный Intel может выучить, что вот конкретно в этом цикле — всегда 5 итераций, и на 6-ю уже не делать спекулятивного повтора. А данные изменятся — переучится на другое число. Или выучить, что конкретно этот IF срабатывает каждый 4-й раз (не такое уж редкое дело).
Armmaster Автор
01.08.2021 15:04+3В Эльбрусе нет предсказателя переходов (хотя есть статьи, где это пробовали делать).
Но в целом вы правы. Там множество мелких и не очень проблем возникает, просто я не хотел совсем уж в технику уходить, т.к. это заняло бы уйму времени на написание статьи, а технически восприняло бы всё это пара десятков человек.
Andrey_Petroff
02.08.2021 07:32Собираются в следующую версию архитектуры v7 (Эльбрус-32С) воткнуть предсказатель переходов.
yalex1442
01.08.2021 13:47+3Дополнительная нагрузка на кэш данных в следствие спекулятивного исполнения кода
Так и на распространенных архитектурах спекулятивные вычисления неявно задействуют кэш, отсюда как раз и произрастает Meltdown.
Armmaster Автор
01.08.2021 15:08+4В Эльбрусе с этим ещё хуже. В типовых архитектурах, если бранч предиктор более менее хорошо работает, то дополнительная нагрузка на кэш минимальна. В Эльбрусе же там просто всегда надо исполнять код по обеим веткам по сути (если линейный участок попал под предикат)
Andrey_Petroff
02.08.2021 07:33Официальная инфа от МЦСТ такова: В следующей версии архитектуры v7 должен быть предсказатель переходов.
Armmaster Автор
02.08.2021 11:20+1Если она официальная, то есть что-то публичное, подтверждающее данное утверждение?
Разговоры о branch predictor'e в Эльбрусе ходили в МЦСТ давно. Но там возникнет большая проблема с совместимостью со старым кодом.
ky0
01.08.2021 14:08+3Ведь казалось бы, если вы хотите продавать свои процессоры, надо их максимально пиарить и первые партии раздавать чуть ли не бесплатно. А тут такие бюрократические препоны.
Чтобы оснащать госсектор и армию в добровольно-принудительном порядке (ещё и за бюджетные деньги, разумеется) - никакого пиара не нужно. И уж тем более не нужны въедливые программисты со стороны, задающие неудобные вопросы. У всей этой затеи изначально не стояла цель приносить прибыль - соответственно они себя и ведут.
Armmaster Автор
01.08.2021 15:13+6Изначально всё было нацелено на широкий рынок. Была знаменитая статья в 99-ом в Microprocessor Report про Эльбрус. А получилось так, как получилось
KanuTaH
01.08.2021 14:12+3Безотносительно Эльбруса хотелось бы заметить, что скорость мейнстримных general purpose CPU, достигаемая за счёт branch prediction и спекулятивного исполнения, имеет "обратную сторону", являясь неисчерпаемым источником различных мелтдаунов.
Armmaster Автор
01.08.2021 15:10+6За всё надо платить и нет никаких гарантий, что в том же Эльбрусе нет своих аппаратных уязвимостей, которые просто ещё не нашли.
DistortNeo
01.08.2021 15:17+1Но для огромного количества задач это не является существенным недостатком.
Точнее, есть потребность как в быстрых процессорах, так и в безопасных.
qw1
01.08.2021 22:07+1Уязвимости такого рода не являются неизлечимой болезнью спекулятивного выполнения. Никто не мешает отслеживать спекулятивно загруженные линии кеша и инвалидировать их, если выполнение пошло не по той ветке. Точно так же, как инвалидируются спекулятивные действия с регистрами. Да, на это надо добросить немного транзисторов. Этого не делали, потому что казалось, что нет большого вреда от того, что больше данных попадёт в кеш. Если это внести в требования к микроархитектуре — что спекулятивные действия не должны быть видимы в кеше — это несложно реализовать.
Kakadout
01.08.2021 15:13Я ещё слышал, что ещё у нас делают мультклеточную архитектуру. С ней тоже всё не радужно?
Armmaster Автор
01.08.2021 15:14+3Мультиклет это не general-purpose CPU. Т.е. совсем другая история, не связанная с обсуждаемым топиком.
VaalKIA
01.08.2021 22:23Мультиклет это именно архитектура процессора общего назначения, а на его базе они разрабатывают всевозможные линейки: для криптохешей, графический, нейроморфный и т.п.
amartology
02.08.2021 03:32+2Мультиклет — такая же «архитектура общего назначения», как Эльбрус, то есть форменное натягивание совы на глобус.
numas13
01.08.2021 15:30+1Было бы неплохо поправить немного таблицу с процессорами. У Itanium 9760 всего 8/16 ядер/потоков, предсказатель ветвления и своеобразное OoOE. Он довольно сильно отличается от Эльбрусов.
Armmaster Автор
01.08.2021 16:20Да, спасибо, таблицу поправил. Что касается различий Итаниума и Эльбруса - про это я особо оговорился в п. 2. Но на общие выводы это не влияет.
numas13
01.08.2021 16:44+1Но на общие выводы это не влияет.
На мой взгляд влияет. IA-64 как-то можно сравнивать с e2k только до появления Poulson, но только если код собирается с
-march=nativeдля IA-64. Как минимум не стоило подгребать их под одну гребёнку в сравнении с OoOE x86.Armmaster Автор
01.08.2021 17:13И в чём на ваш взгляд ключевое отличие последних Itanium от Эльбрус, что принципиально менят описанную картину?
numas13
01.08.2021 17:28+1Часть я уже упомянул выше, но повторюсь для полноты картины.
Многопоточность.
Тактовая частота.
Предсказатель ветвлений.
Аппаратный префетчер.
Наличие FMA.
Ну и вишенка на торте, своеобразное OoOE.
В Эльбрусах что-то отсутствует или сделано иначе (в основном в сторону статического/программного решения), а это сказывается на транзисторном бюджете и TDP. И это не говоря уже о технических возможностях реализовать это в аппаратуре.
Определённо e2k и IA-64 имеют много общего, но в то же время они очень разные. Что-то из этого списка можно реализовать в e2k, что-то уже реализовано, а реализация чего-то ещё превратит в рудимент добрую часть ISA. :)
Armmaster Автор
01.08.2021 19:02+5Многопоточность это просто фишка, которая не ускоряет исполнение в single thread, а просто позволяет чуть более эффективно использовать ресурсы CPU. Добавление её в Эльбрус никак не поменяет всё то, что написано
Тактовая частота это как раз вопрос вылизывания дизайна во многом. Ну и к архитектурным вещам она не не относится напрямую. А косвенные проблемы с частотой у Итаниума и Эльбруса те же.
Предсказатель ветвлений - действительно важная вещь. Она в каких-то моментах поможет, но глобально ничего не изменит. Есть статья от МЦСТ, где они делали предсказатель и в итоге перф получился даже немного хуже (но вроде энергоэффективность подросла).
Префетчер - тоже важный момент, но опять-таки, кардинально ничего не изменит в выводах. Более того, префетчер вносит динамику в планирование задержек и по сути противоречит идее статического планирования.
FMA это просто команда. И в Эльбрусе FMA есть конечно же, причём что-то порядка 6 в такт.
А вот и вишенка на торте)) Ну т.е. давайте скажем честно - по итогу развития линейки Итаниум инженерам стало понятно, что чтобы выжимать перформанс - надо делать ОоОE. Но скрещивать ежа с ужом оказалось больно и сложно и в итоге от развития этой линейки отказались. Что и является признанием тупиковости такого вектора развития general purpose CPU. Я ж на самом деле ни какой-то мега секрет или откровение в статье открыл. В общем-то изложенный вывод - это давно понятный в индустрии результат, ставший известным лет 15 так назад.
В итоге я, честно говоря, не вижу, в чём погрешил перед истиной, обобщив проблемы VLIW на Итаниум. Различия, конечно же, есть. Но они принципиально картины не меняют.
numas13
01.08.2021 20:40+1Многопоточность — это в первую очередь T*S, где T кол-во потоков и S размер архитектурного состояния. Когда у вас 16/32 GPR/VFPR это может и не проблема, но вот когда 128/128 в IA-64 или 256 в e2k (и это ещё не всё архитектурное состояние), то дело уже не настолько просто. Опять таки больше транзисторов, но в статье вы этот аспект Itanium'a не упоминаете в контексте простого VLIW процессора, а он не такой уж и простой.
Тактовая частота — это комплексная проблема поиска оптимального соотношения производительности, энергопотребления, стоимости разработки и тд. Я думаю не надо напоминать какие затраты идут на R&D в Intel и МЦСТ. Да и Itanium на этот момент фактически уже был похоронен. Упомянутый в статье 9760 из 2017 года, это освежённый Poulson из далёкого уже 2012 года. Мне очень сложно представить Э8С с тактовой частотой около 3ГГц, не только потому, что он на ней банально не заработает, а потому что он переплюнет всех остальных по энергопотреблению. Это к вопросу об энергоэффективности. Что-то мне подсказывает, что оба этих производителя не делали на этом слишком большой акцент в этих микроархитектурах.
Предсказатель ветвлений из упомянутой статьи разрабатывался для сокращения энергопотребления в мобильном Э1С+. Процессоры из статьи явно не из этой категории.
Смотря какая политика в планировании используется. Если планировать для ситуаций когда ядро всегда получает данные из L1d, то это имеет смысл. Насколько мне известно по умолчанию (без PGO) в lcc именно такая политика для неспекулятивных обращений.
FMA — это обычно комплексная комбинаторная логика, что означает больше транзисторов. В приведённом Э8С это ещё не реализованно, а Э16С ещё даже нет в серийном производстве. В Poulson это 2 FMAC на ядро, а в Э16С будет 6 векторных FMAC на ядро.
Я вам скажу больше, вы путаете такие понятия как VLIW и ISA заточенная под статическое планирование (не обязательно VLIW). IA-64 (изначально) и e2k заточены под статическое планирование. Но VLIW в IA-64 используется потому, что размер инструкции ~43 бита. Согласитесь, 43 бита не умещаются в 32, а в 64 будет слишком много неиспользованных. Если же абстрагироваться от кодирования, то сама идея EPIC очень плохо ложится не только на статическое, но и на динамическое планирование, это что-то среднее. Банально в OoOE не нужны стоп биты, то есть в Poulson эта информация рудимент прошлого (хотя и может упрощать переименование регистров), а для статического планирования это не подходит при изменении конфигурации микроархитектуры. E2k в этом плане более последователен, но со своими крайностями. Если же вернутся к OoOE в Itanium, то это не про dataflow как обычно принято, а про перемещение инструкций в конец очереди если её операнды не готовы в момент запуска. Грубо говоря, пока процессор ждёт 200 тактов данных из памяти, он всё это время "теребонькает" очереди. Опять таки, это лишнее энергопотребление, не говоря уже про необходимость переименования регистров. Опять таки, нужно больше
золотатранзисторов.
Если же подвести итоги, то на этом фоне микроархитектуры Эльбрусов выглядят очень очень плохо. Например в 9760 32 Мб L3, а в Э8С всего 16 Мб. Хотя то что физдизайн у Эльбрусов оставляет желать лучшего отнюдь не новость. Делать из этого далекоидущие выводы как минимум глупо на мой взгляд. Лучше было бы сравнивать Itanium'у с x86 тех годов, но опять таки с учётом специфичности IA-64.
Но в одном я с вами полностью согласен, что e2k слишком переусложнён, что и тянет его на дно из-за невозможности адекватно реализовать всё в аппаратуре.
На мой взгляд, наиболее разумное применение VLIW для in-order CPU в Denver от Nvidia. Скажем так, это современных взгляд на in-order VLIW без классических недостатков и развитие идей заложенных в Crusoe от Transmeta.
Надеюсь мой пост не получился слишком перегруженным.
Armmaster Автор
01.08.2021 21:29Мы сейчас уйдём совсем в глубокие потроха, давайте остановимся. По Эльбрусу у нас разночтений нет, а что касается Итаниума - я останусь при своём мнении, что он принципиально имеет схожие проблемы. Но это уже повод для отдельных статей и дискуссий. Я специально в начале статьи сделал оговорку, чтобы меня Итаниумом не донимали ))
numas13
01.08.2021 21:43+1Но потом вы сделали ошибку упомянув Itanium в статье. ;)
Все эти архитектурные споры вечны. Как говорит один умный человек: "It depends". Ну а через какое-то время потомкам приходится жить с тем, что было важно тогда в прошлом, вне зависимости о какой бы архитектуре мы сейчас не говорили. :)
edo1h
01.08.2021 22:09ИМХО практика — главный критерий, если бы у итаника был хоть какой-то шанс, его бы не потопили.
numas13
01.08.2021 22:33+2Это всё из разряда: "Если бы у бабушки были...".
Я не хочу быть адвокатом ни для Intel, ни для МЦСТ, и топлю за объективную оценку ситуации. Но позволю обратить внимание на то, что у всех архитектур разные стартовые позиции, что может сильно сказаться на их успешности. Микроахитектура спокойно может быть OoOE, даже для того же IA-64. То есть вопрос не столько в том, что это RISC/CISC/VLIW/etc, а в самом дизайне ISA и насколько он удачен. Но не достаточно просто быть лучше. Рынок обчыно инертен и не любит сильных потрясений. Лучше всего когда появляется новая ниша и её удаётся быстро занять, но это происходит не часто. Itanium свою нишу не нашёл, а и IA-64 была не такой уж хорошей. Это камень в огород плотности кода у этой архитектуры.
Не надо делать поспешных выводов и экстраполировать опыт Х на все Y.
Sabubu
01.08.2021 15:33-3Не вижу в статье серьезных аргументов против архитектуры e2k. Складывается такое ощущение, что автору просто нравится устаревшая архитектура x86 и он ее всячески защищает.
Но x86 как раз пример ужасной архитектуры. Она была придумана для 16-битного процессора с последовательным выполнением команд и очень плохо подходит для современных процессоров. Одна команда может быть закодирована кучей разных способов, используются префиксы. Можно только представить, каких усилий инженерам Интел стоит ее поддержка.
Любая новая архитектура, спроектированная с учетом параллелизации, будет лучше интеловской. Незачем поддерживать это легаси. И тот, кто отказывается от поддержки легаси, получает преимущество перед Интелом, вынужденным тянуть совместимость.
Я также замечу, что в последнее время перестали расти частоты процессоров. Значит, нужно проектировать архитектуру под "медленные" процессоры и искать выигрыш в чем-то другом — например, в большем распараллеливании. Традиционные программы, где команды выполняются по очереди, больше не ускорить. Прирост, который дает Out-of-order execution и спекулятивное выполнение, тоже ограничен, и нужны новые подходы. За счет Ooo вы можете выполнить 3-4 операции за такт при удачном стечении обстоятельств, но не больше. Если вы хотите выполнять вычисления быстрее, вы должны либо иметь множество ядер (десятки-сотни) и многопоточную программу, либо придумать способ выполнять за один такт множество команд — 10, 20, 30.
Это, кстати, объясняет, почему архитектура x86 бесперспективна — ее нельзя адаптировать под "медленные", но широко параллельные процессоры.
Все это, скорее всего, потребует переделку исходного кода с "последовательного" на "параллелизуемый". Нужны новые языки программирования, облегчающие это.
Объективно я вижу два недостатка у Эльбруса:
- непредсказуемость времени обращения к памяти может остановить конвейер. Наверняка с этим что-то можно сделать. Ведь такая же непредсказуемость есть и в Интеловских процессорах И они точно так же могут остановиться. А в Эльбрусах, как я помню, есть возможность фоновой предзагрузки данных из памяти.
- отсутствие поддержки Эльбруса в JIT-компиляторах. Браузеры на лету компилируют JS-код в ассемблер, регулярные выражения компилируются в ассемблер, ява-код компилируется, базы данных компилируют код. И все они не поддерживают Эльбрус.
При этом, я вижу определенную несправедливость. Вышел Мак на ARM — переоцененное, бесполезное, не нужное железо с проприетарным закрытым софтом по завышенной цене. И все спешат адаптировать свои программы под него, выполняя бесплатно работу для самой богатой корпорации в мире. А для нашего Эльбруса никто ничего адаптировать не хочет.
При этих недостатках, у Эльбруса много хороших решений. Глупо было бы терять эти наработки.
Идея сделать сложный компилятор вместо сложного процессора однозначно хороша. Все, что можно выкинуть из процессора, нужно выкидывать.
Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям. А это колоссальные затраты
Не вижу колоссальных затрат в запуске компилятора. Это кстати, наглядно показывает, почему надо опираться на свободный и открытый софт, который легко адаптировать под Эльбрус и отказываться от недружественного закрытого софта. Вместо того, чтобы покупать дорогой закрытый софт, лучше вложиться в доработку открытого.
"Жирный" код, ведущий к повышенным кэш-миссам кода
Та же проблема есть в интеловских процессорах. Если процессор выполняет 4 инструкции за такт, он должен успевать подкачивать эти 4 инструкции.
Дополнительная нагрузка на кэш данных в следствие спекулятивного исполнения кода
Та же проблема есть у Интела.
Фактическая непереносимость кода между версиями процессора
Не вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой.
AllexIn
01.08.2021 17:24+2Нет проблем писать многопоточку для х86. Есть проблема писать эффективную многопоточку.
Эффективно утилизировать ядра тяжело, но и задачи такой не стоит. Если каждое ядро дает +50% производительности это уже отлично.
Я сам пишу на языке по мнению большинства плохо подходящего для написания многопоточности(С++) и не испытываю особых проблем чтобы эту многопоточность использовать.
Переделывать "старый" код необходимости тоже нет. Мы живем в мире, где старого кода очень мало. Актуальный софт постоянно обновляется и часто переписывается. А не актуальный... Он просто нормально исполняется за счет того, что современные процессоры как минимум не хуже тех под которые он писался изначально.
N-Cube
01.08.2021 21:15+10…я вижу определенную несправедливость. Вышел Мак на ARM…
И каждый желающий его может купить и софт писать. А с учетом, что дебиан давно и прекрасно работает на Арм (и 15 лет назад работал, помнится, я на армовском роутере даже PostgreSQL запускал и систему документооборота на Tcl, все работало без ошибок, хотя и медленно), никакой проблемы с софтом нет.
…по завышенной цене…
По сравнению со стоимостью эльбрусов - дешевле пареной репы.
…для нашего Эльбруса никто ничего адаптировать не хочет.
Вот именно, что «вашего» - а мы его в жизни не видели, как и подавляющее большинство всех разработчиков в мире.
qw1
01.08.2021 22:41+3
Вы не понимаете проблему. Допустим, у вас есть абсолютно последовательный код (а это не такая редкость, тот же CRC32 не распараллелишь), например«Жирный» код, ведущий к повышенным кэш-миссам кода
Та же проблема есть в интеловских процессорах. Если процессор выполняет 4 инструкции за такт, он должен успевать подкачивать эти 4 инструкции.X = ((A+B)*C+D)*E
Так называемая «широкая команда» Эльбруса должна выполнять в одной команде до 6 независимых операций. Но в первой «широкой команде» вы делаете только A+B, во второй *C, и т.д., забивая остальные 5 слотов арифметики NOP-ами, т.е. раздувая код пустыми операциями.Не вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой
Проблема в том, что современный капиталистический мир насквозь проприетарный, и вам никто исходников не даст. А если попросите вендора перекомпилить код под ваш новый проц, так он денег попросит за поддержку, а то и вовсе окажется, что год назад обанкротился.
beeruser
02.08.2021 06:44+9Не вижу в статье серьезных аргументов против архитектуры e2k.
Ой, всё. Ваши аргументы — не аргументы!(с)х86… очень плохо подходит для современных процессоров
Смешно, учитывая что на этой архитектуре созданы самые быстродействующие процессоры в мире.Любая новая архитектура, спроектированная с учетом параллелизации, будет лучше интеловской.
История показывает что это не так.
Как и delay слоты это вынос попытка выноса микроархитектурных детали в архитектуру является глубокой ошибкой. Софт нужно будет пересобирать под каждый процессор.
На новых чипах старый код выполняется неэффективно.За счет Ooo вы можете выполнить 3-4 операции за такт при удачном стечении обстоятельств, но не больше.
M1 декодирует 8 команд, а выполнять из ROB может ~17 штук за такт.непредсказуемость времени обращения к памяти может остановить конвейер. Наверняка с этим что-то можно сделать. Ведь такая же непредсказуемость есть и в Интеловских процессорах И они точно так же могут остановиться.
OoO движок выполняет все инструкции до которых можно дотянутся пока данные из памяти идут. В M1 буфер переупорядочивания отслеживает 630 инструкций.
www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2А в Эльбрусах, как я помню, есть возможность фоновой предзагрузки данных из памяти.
А где её нет?Вышел Мак на ARM — переоцененное, бесполезное, не нужное железо с проприетарным закрытым софтом по завышенной цене.
Ахаха. Ну надо же какое нелепое и бессмысленное зубоскальство. По какой шкале вы «ненужность» замеряли? Для сотен миллионов людей железо крайне полезное и нужное.
Всего-то процессор с самым быстрым однопотоком ever.проприетарным закрытым софтом
Особенно ОС и компилятор.
opensource.apple.com
github.com/llvm/llvm-projectИ все спешат адаптировать свои программы под него, выполняя бесплатно работу для самой богатой корпорации в мире.
Как же так? Ведь быть такого не может? :)
Всего-то лучший процессор для ноута, не имеющий конкурентов.А для нашего Эльбруса никто ничего адаптировать не хочет.
Эльбрус это у вас образчик открытости и полезности :)
И особенно образчик доступности.
Не, я бы конечно купил Эльбрус без того пистолета у виска, но кто ещё?
Более того, с Эльбрусом приходилось работать.При этих недостатках, у Эльбруса много хороших решений. Глупо было бы терять эти наработки.
Какие? Архитектуру нужно было закопать и забыть ещё в нулевые.Идея сделать сложный компилятор вместо сложного процессора однозначно хороша.
Хороша ложка к обеду.
А идея это давно устарела. Как показывает практика, «умный» компилятор сделать невозможно даже при неограниченных ресурсах.
Процессор со статическим планированием может эффективно работать только со статической памятью никогда не сможет эффективно выполнять сложный код. Удел VLIW — это DSP. Адекватные люди его так и используют.Не вижу колоссальных затрат в запуске компилятора
Ну возьмите и портируйте туда языки программирования с JIT. Пара пустяков, да?Если процессор выполняет 4 инструкции за такт, он должен успевать подкачивать эти 4 инструкции.
Нет проблем подкачивать инструкции. На х86 Fetch получает 16/32 байта каждый такт из кэша.
Но то что выполняется в цикле, обычно лежит в МОП-кэше, откуда достаётся по 6 инструкций (Sandy Bridge+).
travisdowns.github.io/blog/2019/06/11/speed-limits.htmlНе вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой.
Ясно, понятно.
Весь бизнес Интел построен на том, что «не нужно перекомпилировать код».
Вы его перечеркнули одним высказыванием.
Юзверь ведь захочет ждать несколько часов/дней, пока соберётся какой-нибудь Chromium на его машине.
Или разраб захочет держать шесть дистрибутивов каждой версии софта под каждую версию Эльбруса, который есть у нескольких человек в мире. Так держать!
shcher
01.08.2021 15:46+5Вопрос про цикл с вызовом функции. Вы проверяли, какой получается результат? 17 тактов в случае Эльбруса кажется реалистичным результатом. Но вот один такт на других архитектурах - не верится совсем.
Я понимаю, что вы нацелились на самую широкую аудиторию, но заявляете техническое рассмотрение вопроса, а значит нужно больше деталей. Если это скучные детали, можно скрыть их под спойлер, большинство сможет пропустить.
akaAzazello
01.08.2021 15:55-4С учётом inline вызов функции выкидывается и оставшаяся целочисленная операция сложения(которая будет осуществляться в регистрах) - это действительно почти везде 1 такт.
shcher
01.08.2021 16:20+1Боюсь, вы были невнимательны при чтении статьи. Речь о том, сколько будет выполняться тело цикла, если не удалось подставить функцию (например, она в другом модуле компиляции). Или вы считаете Эльбрус настолько отстающим, что у него одно целочисленное сложение занимает 17 тактов?
akaAzazello
01.08.2021 18:26-5К сожалению, только вы не поняли, что значит разница между inline & VLIW - и, пожулайста, адресуйте своё непонимание к автору статьи.
shcher
01.08.2021 18:41+2Действительно, не понимаю, как можно сравнивать inlining и VLIW. Подстановка функции - это техника оптимизации, работает под любую архитектуру, в том числе VLIW, в том числе Эльбрус.
И этот вопрос я адресую именно вам, потому что автор верно понял мой первый вопрос и ответил на него, а подмена понятий началась у вас.
kosmos89
01.08.2021 19:32Вы точно не так поняли написанное или, может, вообще в теме не разбираетесь...
В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной (и то, если компилятор не раскрутит цикл, но далеко не каждый цикл можно раскрутить).
А вот при отсутствии инлайна как Эльбрус, так и Интел сильно просядут и даже в Интел вряд ли будет 1 такт.
creker
01.08.2021 19:36+1Разве спекулятивное исполнение не позволит интелу и без, и с инлайном сразу начать выполнение следующей итерации?
kosmos89
01.08.2021 23:03Ну начать може и сможет, в зависимости от того, как организован цикл. Но все равно всё встанет на инкременте переменной, потому что это зависимость между итерациями.
creker
01.08.2021 23:11+2Это если есть инкремент, ну ок. А в чем тогда разница с VLIW? Он же тоже упрется в инкремент. Если компилятор не раскрутит цикл, то получится все так же одна итерация за раз. А если раскрутит, то тут и интел неплох будет.
kosmos89
02.08.2021 00:39+1У Эльбруса в архитектуре есть поддержка циклов, так что в счетчик не упрётся.
beeruser
02.08.2021 07:54+2В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной
Виртуальную функцию заинлайните?
Сколько может трекать ОоО, столько итераций и будет выполняться за такт.
В общем случае инкремент ограничит время выполнения скалярного кода до не более чем 1 итерации за такт.
Если это является препятствием, можно цикл раскрыть.(и то, если компилятор не раскрутит цикл).
Звучиткак угрозакак будто раскрутка ухудшит ситуацию.но далеко не каждый цикл можно раскрутить
Тогда и на Эльбрусе с этим ничего не поделаешь.А вот при отсутствии инлайна как Эльбрус, так и Интел сильно просядут и даже в Интел вряд ли будет 1 такт.
Интел сильно не просядет. Время увеличится только на пролог/эпилог функции.
Сall/ret эффективно занимают 0 тактов благодаря предсказателям и аппаратному стеку возврата.У Эльбруса в архитектуре есть поддержка циклов, так что в счетчик не упрётся.
И что? Счётчик циклов позволит выполнять несколько широких команд за такт? Или несколько итераций внутри широкой команды?
В общем старания ваши и товарища sabubu выше, непонятны.
E2K изначально спроектирован так, чтобы быть низкочастотным, неповоротливым процессором, который может эффективно выполнять только распараллеливаемые циклы без переходов.
C современными микроархитектурами его сравнивать нельзя и я даже не говорю о векторных ISA типа ARM SVE.
Это как сравнивать каменный топор с современным.kosmos89
02.08.2021 08:00>Или несколько итераций внутри широкой команды?
Именно так, наслаиваясь. Конвейерная обработка циклов. Может как-то еще хитрее можно выполнять, но это уже не в моей текущей компетенции.
beeruser
02.08.2021 14:52+1Именно так, наслаиваясь. Конвейерная обработка циклов.
Поддержка (софт)конвейеризации циклов это костыль, который сделан чтобы компенсировать зависимости инструкций внутри одной итерации цикла.
OoO движок может «наслаивать» десятки итераций, а не 2-3.Когда уже ясно, что из системы команд уже практически всё выжато.
Что выжато? Если смотреть источник повышения производительности, хорошая система команд даёт 5% производительности, а 95% даёт хорошая микроархитектура. Через пару лет OoO будут иметь окно переупорядочивания в 1000 инструкций, вместо 630 сейчас.
За такт может выполняться не 17, как сейчас, а больше инструкций, а уж найти их процессору в этом окне гораздо проще, чем в исходной программе компилятору.
Поймите, ISA это просто API. Внутренности процессора могут быть устроены как угодно.А мне непонятны старания людей, пытающихся доказать, что за CISC/RISC будущее.
Людей, которые видят, что ваш воображаемый мир Очень Длинных Розовых Пони плохо соотносится с объективной реальностью?
PS: Не только будущее, но и настоящее.
kosmos89
02.08.2021 08:06А мне непонятны старания людей, пытающихся доказать, что за CISC/RISC будущее. Когда уже ясно, что из системы команд уже практически всё выжато.
edo1h
02.08.2021 08:09Когда уже ясно, что из системы команд уже практически всё выжато
разумеется, прогресс идёт не в системе команд, а в отвязке системы команд от реального процессора.
creker
02.08.2021 12:01Определенно за ними будущее, раз на горизонте нет ничего близко, что может их заменить. А прогресс весь идет в микроархитектуре. В систему команд добавляются лишь специализированные инструкции под шифрование, сжатие, ML тот же. Сейчас большой упор делается не на совершенствование ядер, а на обвязку, потому что там основные ботлнеки. Тут у нас HBM как процессорный кэш, 3d stacking, всяческие тайлы и чиплеты, интерконнекты на подложке вроде infinity fabric, интерконнекты на уровне системы вроде CXL, новые интерфейс для оперативной памяти. Процессоры нынче уперлись в скорость подсистемы памяти и кэши, это самое узкое место. Никакая новая система команд это не изменит.
edo1h
03.08.2021 08:06Если мы начинаем туда интегрировать элементы "влив"(т.е. явный параллелизм), то это ничто иное как принятие несостоятельности суперскаляра как такового.
а как же simd?
qw1
03.08.2021 08:35+1Проблема суперскаляра не в суперскаляре, а в говнокоде который на нём пускают
Кто делает «говнокод»? Компиляторы или люди? Если люди, то не «говнокод» — это то, что идеально исполняется на процессоре, или легко читается/понимается другими людьми?Ширина операций никак не связана со свойствами влива/суперскаляра. Поэтому попытка провалилась
Нет, это вы ничего не поняли. SIMD — это не VLIW!
Во-первых, SIMD — это попытки ввести в архитектуру тип данных, с которым нативно оперирует программа. Если 3d-редактор работает с векторами (x,y,z,w) и матрицами 4x4, то введение SIMD-регистров на 4 double с действиями над ними, полезными для предметной области, это и есть перестройка АЛУ под задачи предметной области, а не какой-то там VLIW.
Во-вторых, введение SIMD нахаляву даст нам хороший прирост производительности, если прямое развитие упёрлось в предел (это не значит, что суперскаляр плохой, любая технология упирается, иначе бы рост был до бесконечности), потому что это шаг в сторону. Если вы из-за каких-то религиозных соображений не приемлете такой шаг, это просто глупо.Суперскаялар предполагает(да и это прямо выводится из ваших рассуждения), что суперскаляр состоятелен сам по себе
Где вы это увидели? Приведите цепочку рассуждений, с цитатами. Моя позиция такая, что если текущее развитие суперскаляра упёрлось в 150 условных попугаев на ватт, а развитие VLIW упёрлось в 120, то боттлнеки можно легко снять, введя в архитектуру гибридные элементы и получить сразу 200 попугаев. А вы хотите вечно сидеть на 150? Или с болью выжимать из старых идей ещё по капле, до 160 и 130 соответственно, зато не поступиться «чистотой».
Brak0del
03.08.2021 09:52+1У суперскаляра нет ни одного преимущества перед вливом. Поэтому никаких 160/130 там нет. Просто начните влив понимать правильно. Влив - это класс архитектур с явным параллелизмом. Т.е. это не-скалярные архитектуры. И осознайте, что он может делать всё тоже самое, только лучше.
Ну что за бред, не может. Определяющая характеристика VLIW -- это статическое планирование исполнения инструкций, которое даже в теории уступает динамическому. Важнейшая фишка суперскалярных архитектур -- это динамическое планирование, которое эффективнее статического всегда.
qw1
03.08.2021 10:34+1Планирование борется в основном с легаси-вендорлок-дерьмом, а так же с неоднородностью памяти. Но эти проблемы порождены самим суперскаляром
Про память вы уже не первый раз пишете. Мне интересно, как вы себе представляете идеальную организацию памяти.
qw1
03.08.2021 17:22Я хотел поподробнее, тип памяти, количество, расположение.
Например, «128 Гигабайт SRAM на кристалле у каждого ядра». Только сколько это будет стоить?
qw1
03.08.2021 17:25+1По идее, вы должны понимать, что многоуровневая память — компромис между скоростью доступа, объёмом и ценой. Но мне всё больше кажется, что здесь вы чтобы троллить )))
edo1h
03.08.2021 20:36+2Т.е. мы имеем многоуровневую физическую память в одноуровневым адресспейсом. Я же предлагаю многоуровневаю с многоуровневым.
вот смотрите, у вас запущено 15 процессов на ядре, каждое из них рассчитывает на какие-то данные в кэше. предлагаете при каждом переключении контекста и кэш перезагружать?
DistortNeo
04.08.2021 00:13+1Ага, и в итоге мы приходим к механизму виртуальной памяти, но работающей на уровне быстрой памяти. Фактически, получается тот же самый вытесняющий кэш, но управляемый программно, а не аппаратно.
Ну либо раз мы памятью управляем явно, тогда и процессами — тоже. Вместо вытесняющей многозадачности — многозадачность кооперативная.
qw1
03.08.2021 10:07+1Делают компилятор люди, которые являются жертвами школы суперскаляра. Компилятор еж пытается с этим бороться.
Ничего не понял. Компилятор пытается бороться со своими создателями?SIMD — это не VLIW!
Это вливНикакой «влив» будь то эльбрус, либо итаник вливами не являются, номинально
Жесть. Сначала у вас SIMD это VLIW, затем Эльбрус это не VLIW ))Симды — это развитие векторных процессоров. Векторные процессоры это противоположность скалярным. Основным их свойством является параллельная обработка данных
И отсюда вы делаете вывод, что SIMD это VLIW. Это ошибочный вывод. Потому что VLIW и векторный процессор — это про разное.Оно даст не на халяву. Это так же несостоятельные рассуждения. Вектор стоит столько же, сколько и несколько отдельных скаляров
Значит, вы не понимаете профита от SIMD. А профит в том, что в программе есть типичные действия, такие как сложение или ужножение векторов. И их можно делать одной инструкцией, экономя на размере кода. Никакой VLIW не позволяет добиться этой цели, потому что во VLIW сложение каждого компонента с каждым надо запрограммировать, и это занимает место в коде.Приведите цепочку рассуждений с цитатами, где вы бы выступали за синергию подходов
Так с самого началаОй, что делают, гады! В свои плохие процессоры тащат то, что позволит им вырваться вперёд! Это же нечестно!!!
Если вы не поняли, это ваши проблемыУ суперскаляра нет ни одного преимущества перед вливом
На моих типичных задачах нет параллелизма: обход дерева в глубину, вычисление CRC, кодирование-декодирование Хаффмана, парсеры текстов, компиляторы. VLIW тут будет как собаке 5-я нога, потому что параллелизма нет, и 90% мощностей тупо не будет задействовано. Но для вас эти задачи мусор и говнокод.Единственное что он не может — это исполнять скалярное легаси-вендорлок-дерьмо
Удачи вам на задачах моделирования погоды, ядерных взрывов и прочих уравнениях мат. физики. А мне процессор не для этого нужен.
qw1
03.08.2021 10:47Делают говнод люди, которые являются жертвами школы суперскаляра
Ну ясно. То есть люди должны писать под процессор, а не в терминах предметной области. Но это очень дорого. А потому у нас везде будет «говнокод». И нужны процессоры, которые хорошо это прожуют.Вот симд это влив(как то, чем он является). Эльбрус — это влив(как то, чем является). Эльбрус это не влив(как неверное обывательское представление о вливе)
Хватит! VLIW — это широкая команда, EPIC — явный параллелизм. Ну вот просто по определению этих буковок. Если вы будете продолжать писать vliw вместо epic, придётся делать эти замены при чтении. Но тогда отвечать я вам не смогу — не буду же я эти замены делать, чтобы лично вам было удобно читать в ваших терминах, а не общепринятых.Влив и векторный процессор — это про одно и тоже. Про явный параллелизм. Скаляр же про неявный
Подмена терминов, выше уже писал, что я об этом думаю.Во-вторых зачем вам тогда суперскаляр? Суперкаляр это как раз таки про параллелизм
90% мощностей тупо не задействовано. Чушь потому что 90% мощностей суперскаляра на этом говнокоде так же задействовано не будет
На моих не параллельных задачах суперскаляр иногда выискивает резервы для параллелизма, и иногда это выстреливает. Дополнительно получить 20-40% ускорения — почему бы и нет?То, о чём я говорил выше, а именно: «задачи мусор и говнокод», когда я говорил о том, что говнокод это именно решение задачи. Это обычная попытка снять с себе ответственность. Если проще, то человек заявляет «нет плохих реализаций — это всё просто следствие задач», что, очевидно, противоречит наблюдаемой реальности
Чушь. Хотите сказать, что сможете написать кодер Хаффмана для вашего VLIW/EPIC, который бы загрузил полезными действиями все исполнительные модули на 100%?
qw1
03.08.2021 20:26Пытался, когда думал, вы серьёзно. А вы тут просто рофлите, выдавая нечто несуразное и ждёте, когда все вам наперебой кинуться доказывать, что белое это белое, а чёрное это чёрное )))
Civil
04.08.2021 01:53+3Кстати, судя во всему этот персонаж ботвы с собой нагнал. Потому как как-то яро начали минусовать мои ответы ему, а его плюсовать.
Простите, что врываюсь в вашу почти приватную дискуссию, но не могу удержаться и задам вопрос: А почему Вы уверены, что причина в мифических ботах, а не в Вашей манере вести беседу? Тут в комментариях люди до сих пор не очень любят, когда какой-то недавно зарегистрированный человек оставляет комментарии формата "очевидно вы все не правы" и всячески пытается выставить что вокруг только он один в белом плаще, еще и используя переходы на личности.
Так что неперошенный совет - начните аргументировать свою позицию чем-то кроме "очевидно", либо несколько деанонимизируйтесь, если хотите выезжать на репутации. Иначе со временем вам и карму сольют в минуса и будут минусовать такого рода комментарии.
И естественно - в диалогах на технические темы надо использовать общепринятую терминологию чуть чаще, чем всегда. Даже если Вы с ней несогласны.
Civil
04.08.2021 10:56+2Любимые оправдания ботов. Какая манера? Где манера? Почему у него её нет?
То есть я Вам хотел помочь объяснив в чем Ваша проблема и я за это еще и бот? Отлично, спасибо.
Какая манера? Просто - Вы хамите людям, пишите так, словно Вы звезда уровня мировой величины и Ваши слова истина не требующая доказательств. Почему у него (кстати у кого?) ее нет - я не знаю, не ко мне вопрос.
Почему минусовали/плюсовали именно мои ответы ему/его ответы мне? Почему плюсовали откровенное вранье, которое проверяется про ctl+f за пару секунд? Почему в принципе плюсовали не читая?
За Вашу манеру выражаться и полное отсутствие доказательств.
А т.е. кумоство? Да, высокий уровень для технического ресурса.
Странные выводы из моего сообщения, но нет, не кумовство, а не любят людей которые с порога хамят.
Показывайте такие комментарии.
Про "очевидно" с Вашей стороны:
раз - первые три ответа. Правило хорошего тона - раз Ваш собеседник не понял - расскажите как и аргументируйте ссылками. Либо Ваш комментарий ни чем иным как хамством назвать нельзя. Не важно правы Вы или нет (заметьте, я специально избегаю контекста правоты).
Хотите больше? два
Про "один я в белом плаще": раз, два, три
Меня удивляет эти бригада поддержки, которая прибегает и сообщает "ненужно аргументации уровня "очевидно"", но при этом пишет:
См. этот комментарий. Впрочем от меня Вам это будет последний коммент, так что можете не распаляться на ответ.
Естественно нет. Ну и да, где пруфы того, что использовал я, а не он? Идите объясняйте его факапы.
Ну раз нет, то нет. Потом только не удивляйтесь что вас будут считать за человека, который не разбирается примерно ни в чем. Если Вас это устраивает - кто я такой чтобы Вас останавливать?
К тому же тут Вы извратили смысл сказанного мною. Я Вас не обвинял, а намекал на то чтобы Вы пересмотрели Вашу дискуссию с другими об определениях и подкрепили Ваши определения ссылками (обязанность доказывать по правилам хорошего тона лежит таки на Вас, если Ваша цель обсудить, а не развести полемику). Но в плане доказательства что Вы использовали я воспользуюсь Вашим же приемом и скажу что Ваше "Естественно нет" исходя из правил русского языка можно трактовать как то, что Вы понимаете что используете изобретенные Вами термины (по контексту), так что Вы сами только что признались.
И жду, чтобы вы написали каждому, кто называл итаник/эльбрус вливов ту же самую херню. Или только клоунада?
А тут уже whataboutism начинается. Я Вам написал только из-за того, что Вы постоянно переходите в своих комментариях на личности. Понадеялся, что это неосознанно и что мой комментарий поможет Вам понять из-за чего Вам отсыпают минусов так щедро.
За сим оставлю Вас наедине с этим новоприобретенным знанием. Все таки это не вежливо в технической (и даже псевдотехнической) дискуссии объяснять людям за что им сыплются минусы. Хотите продолжить - добро пожаловать в личку, я Вам там постараюсь подробнее объяснить почему я считаю, что в Ваших минусах виноваты Вы, а не мифические боты.
P.S. Предполагаю, что Ваш следующий ответ тоже ничего конструктивного кроме перехода на личности или попыток пояснить почему "очевидно" и "стою в белом плаще" это нормально и единственно верно, а я не прав (без доказательств естественно) содержать не будет. Но приятно удивлюсь, если Вы таки воспримите что я Вам сказал и поменяете свой стиль общения в этом тредике.
DistortNeo
04.08.2021 18:32+4> Мы видим здесь какие-то пруфы? Какие-то рассуждения о том как мы к этому приходим? Нет. Это просто пустое заявление.
Если что-то не понятно, то всегда можно попросить собеседника развить мысль или спросить непонятный момент, а не называть людей клоунами и божествами. Людям такое почему-то не нравится.
У вас почти в каждом комментарии про мнение оппонента написано «чушь», «мусор», «рак» и т.д. Безаппеляционная уверенность в своей правоте, не свойственная думающим людям.
> Ага, и в итоге мы приходим к механизму виртуальной памяти, но работающей на уровне быстрой памяти.
Это не пустое заявление, потому что очевидно, что в многозадачной среде процессы будут конкурировать за быструю память. При переключении задач операционной системе придётся либо копировать эту память куда-нибудь целиком (а это медленно), либо виртуализировать доступ к ней (т.е. копировать только по запросу).
0xd34df00d
05.08.2021 04:41+3Мне вообще кажется, что это Царь переквалифицировался с божественной сишки на хардварь. Правда, про сектантов и методички он вроде не упоминал, что заставляет меня сомневаться.
PsyHaSTe
05.08.2021 14:23Да нет, сидит (по крайенй мере сидел) в телеграме, все так же вопит про методички и блеющих скриптодетей
0xd34df00d
05.08.2021 04:38Хотите сказать, что сможете написать кодер Хаффмана для вашего VLIW/EPIC, который бы загрузил полезными действиями все исполнительные модули на 100%?
Видел папир, где люди предлагали параллелизовать декодер, параллельно пытаясь декодировать с каждого бита и отбрасывая неуспешные попытки.
Модули загрузит на 100%. Не уверен, что полезно.
technic93
04.08.2021 12:30Удачи вам на задачах моделирования погоды, ядерных взрывов и прочих уравнениях мат. физики.
Число дробилки векторизируются. Не вижу тут проблем, их даже не гпу считают часто.
qw1
04.08.2021 14:50Это было в другом контексте. Человек написал, что типичные десктопные задачи (офисные или игры) — легаси вендор-лок дерьмо и лапшекод, потому что параллелизм там никакой. Потому я предположил, что все его задачи — рассчётные, т.е. мы с ним никак не пересекаемся по областям применения процессоров.
DistortNeo
03.08.2021 10:48+3Это влив. Повторяю ещё раз — под вливом никто не понимает влив — влив это имя нарицательное. Подобные представления — это представления обывательские.
Нет, это не влив.
VLIW — архитектура процессора с несколькими вычислительными устройствами и явное указание процессору, какие инструкции должны выполняться параллельно. Суперскалярность же — это неявная параллельность (впрочем, вы это и сами понимаете).
SIMD в x86 не обладает признаками влива. Да, поначалу может показаться, что мы явно указываем сделать несколько операций параллельно, и потому это должно быть VLIW. Но нет, это одна команда, которая задействует одно векторное вычислительное устройство и потому является одной операцией над вектором. К слову, скалярные операции работают на тех же самых векторных устройствах и по факту являются просто подмножеством векторных.
Так что ваше заблуждение: вы классифицируете SIMD как VLIW по признаку параллельного выполнения операций. На самом же деле VLIW — это параллелизм по признаку параллельного задействования вычислительных устройств.
Ну и ещё в копилку фактов: в процессорах имеется несколько векторных вычислительных устройств, SIMD-операции могут выполняться параллельно, если задействуют различные устройства. Но мы не сообщаем об этом процессору явно, так что это суперскаляр в чистом виде.
С небольшой натяжкой можно классифицировать SIMD как VLIW на первом Zen, в котором имелись только 128-битные векторные вычислители, и использование 256-битных команд требовало задействования сразу двух устройств. То есть можно работать с данными как используя 128-битный SSE, так и 256-битный AVX, и при этом в теории не должно быть разницы в производительности.
qw1
01.08.2021 23:52В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной
Не понимаю, как это. Если в цикле есть зависимость следующей итерации от предыдущей, никакая магия VLIW тут не спасёт. Если же задача хорошо распараллеливается, типа скалярного произведения для умножения матриц, тут последняя версия AVX будет умножать по 8 double за раз, а не по 6, как в «широкой команде».yalex1442
02.08.2021 00:406 векторов по 128 бит в последних Э.
qw1
02.08.2021 08:30Можно пожалуйста цитату из официального описания архитектуры?
www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdfyalex1442
02.08.2021 12:19Вот ссылка на ролик из поста с таймкодом на нужный слайд презы МЦСТ
https://youtu.be/Jwt5mSmtoXA?t=3010qw1
02.08.2021 15:01-1Не указаны, какие именно операции можно делать со 128-битными значениями. Может, только сложение 4*fp32, или 2*fp64. А может, вообще только integer арифметика, как у первых Pentium MMX ))
Странно, что они так шифруются и никакой информации не выдают.
kosmos89
02.08.2021 00:44+2Ой, как хорошо, что вы вспомнили AVX. Это же такие general-purpose инструкции! Еще хуже, чем VLIW ) Интересно, зачем они появились в процессорах? Может потому, что в системе команд не хватало параллелизма?
И нет, в Эльбрус гораздо меньше поводов упереться, потому что у него есть аппаратная поддержка выполнения циклов. Некая конвейеризация. Он может наслаивать итерации друг на друга.
Armmaster Автор
02.08.2021 03:00Эту конвейерезацию должен сделать компилятор, и это не всегда возможно. В проце с OoO конвейеризация работает всегда автоматически.
qw1
02.08.2021 08:33+2Ой, как хорошо, что вы вспомнили AVX. Это же такие general-purpose инструкции! Еще хуже, чем VLIW )
Настолько general-purpose, что c/c++ компиляторы полностью заменили FPU на векторные регистры, да ещё агрессивно циклы разворачиваютИнтересно, зачем они появились в процессорах? Может потому, что в системе команд не хватало параллелизма?
Ой, что делают, гады! В свои плохие процессоры тащат то, что позволит им вырваться вперёд! Это же нечестно!!!
rogoz
02.08.2021 14:50Особо смешно, что судя по тестам Sandy Bridge скорее всего всё равно будет заметно быстрее, даже если тестовые приложения откомпилить вообще без SSE/AVX.
qw1
02.08.2021 17:45Экий юношеский максимализм :)
Представьте, что у вас есть суперскаляр мечты: конвеер на 4096 одновременно выполняемых команд, идеальный предсказатель ветвлений, идеальный префетчер, OoO глубиной 65536 и т.д.
Но! Этот суперскаляр 8-битный. А мы молотим длинные числа, чтобы перемножить пару чисел, надо сделать 32 коротких умножения. И тут один инженер выдвигает гениальную идею: а что если регистры сделать 16-битными. Это же незадорого вдвое ускорит нам сложение, и вчетверо ускорит умножение. И тут появляетесь вы и начинаете их учить уму-разуму: фу-фу-фу, это что, ваш Суперскаляр зашёл в тупик? Вы что, не можете докинуть 8-битных исполнительных модулей и улучшить конвеер? Не-не-не, ни в коем случае не делайте 16-битные вычислители.
Это примерно то же самое, что вы сейчас про SIMD.technic93
03.08.2021 09:24+1Этот суперскаляр 8-битный. А мы молотим длинные числа, чтобы перемножить пару чисел, надо сделать 32 коротких умножения. И тут один инженер выдвигает гениальную идею: а что если регистры сделать 16-битными.
По-моему тут у вас путаница. Длинная арифметика и паралелизация нескольких коротких умножений это разные вещи. Предметные области в которых возникают эти задачи разные. SSE не решает первую задачу явно, там нужны дополнительные трюки для этого.
qw1
03.08.2021 10:12Прежде всего, вы согласны, что чем длиннее нативное процессорное слово, тем быстрее работает длинная арифметика?
Согласны, что умножение 32x32 можно расписать как 16 умножений 8x8 и кучу сложений? Согласны, что часть умножений и сложений при этом можно делать параллельно?
Мой пример о том, что некий суперскаляр с высоким параллелизмом и 8-битными блоками умножения мог бы справиться с умножением 32x32, и все его хитрости типа параллелизма и OoO были бы в этой задаче востребованы. Но гораздо проще ввести блок 32-битного умножения.
Аналогично, у нас есть задачи (сложение/умножение векторов, например), которые можно писать обычным скалярным кодом, и процессор может его пытаться параллелить. Но есть предел наращивания производительности таким путём. Проще ввести специальную инструкцию, что и делает SIMD.technic93
03.08.2021 18:53Кому проще? Получается вы предлагаете реализовать новую инструкцию в железе? Или на уровне микрокода?
beeruser
03.08.2021 16:02+1fpu не существует в amd64. Там есть только тормозная эмуляция fpu.
Ахах. Что, прямо на интах, как в 80-е?Симд это элементы явного параллелизма. Они как раз говорят о неспособности неявного конкурировать с янвым в этих задачах.
SIMD это лёгкая возможность добавить явного параллелизма, не теряя «неявного». Это говорит лишь о том, что расширить ALU проще и эффективнее чем добавить ещё несколько независимых юнитов.DistortNeo
03.08.2021 19:57Ахах. Что, прямо на интах, как в 80-е?
Нет. Через микрокод. Из-за этого latency у команд FPU выше, чем у аналогичных команд SSE/AVX.
Armmaster Автор
04.08.2021 18:08Нет, не из-за этого, а из-за того, что x87 (мы же про него говорим? потому что FPU это и x87, и SSE/AVX тоже) работает с 80-ти битными регистрами, в то время как SSE/AVX с 32/64.
qw1
02.08.2021 17:47Это не спасёт и суперскаляр.
Ага. Потому что я комментирую вот эту ерунду:В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной
anonymous
00.00.0000 00:00Armmaster Автор
01.08.2021 16:28+6Да, я хотел чтобы статья была максимально простая. Иначе если уйти в технику, там вообще мало кто понимать начнёт, да и по объёму очень много получится. Но какие-то конкретные вещи я может потом распишу, если будет интерес у публики.
Что касается одного такта на других архитектурах. Там всё упрётся в количество инструкций перехода, которые конвейер может переварить за такт (но 2 там минимум должно быть) и скорость фетчинга кэш-линий. Последнее в современных Интелах решится кэшем микроопераций. Ну т.е. я прямо не проверял, но почти уверен, что будет 1-2 такта на топовых моделях.
edo1h
01.08.2021 18:59сейчас проверил, на i5-3570 1ккк циклов выполняются за ≈1.9 с против ≈1.6 с у заинлайненной функции.
разница примерно на такт. это, конечно, не «итерация цикла будет занимать ~1 такт», но всё равно очень впечатляет.Armmaster Автор
01.08.2021 19:19+2i5-3570 всё же чип 9-летней давности и не топовой линейки. И я не помню, был там кэш микроопераций уже или нет. Но идейно понятно, что там происходит. Просто для x86 с OoO это просто вопрос, нужно ли добавить ещё транзистров, чтобы съедать такой код за такт. А на Эльбрусе если компилятор не справился - то всё, 17 тактов и никуда не деться.
edo1h
01.08.2021 19:31+1i5-3570 всё же чип 9-летней давности и не топовой линейки. И я не помню, был там кэш микроопераций уже или нет.
проверил на xeon 6144 (≈1.9 с и ≈1.5 с соответсвенно), ryzen 5950x (≈1.3 с и ≈0.4 с).
у древнего i5, получается, самые маленькие потери от отсутствия инлайна.update: о, нашёл, у scalable второго поколения (4214) фактически нет разницы между не-инлайн и инлайн версиями, ≈1.85 с и ≈1.9 с (разница того же порядка, что и разброс между последовательными запусками).
P. S. только не уверен, что этот пример что-то показывает, есть сомнения, что процессор на реальном коде сможет «закэшировать» вызов функции.
Armmaster Автор
01.08.2021 20:07+1Вы заставили меня дойти до компа ))
Значит сдаётся мне, что вы скомпили код с опцией -O0, а это не то, что мы хотим мерять. Надо подать -O2.
Функцию get_inc_val надо с помощью атрибута __attribute__ ((noinline)) указать как не подлежащей инлайну в случае тестирования с вызовом (иначе компилятор её насильно заинлайнит)
Для тестирования случая с инлайном я в цикл добавил asm("nop"); иначе компилятор просто свернёт цикл.
В итоге оба случае на моей машине Intel Core i5-7500 3.4 GHz работают ~0.3c.
edo1h
01.08.2021 20:20+1нет, собирал с -O3.
давайте ассемблерные варианты сравним
вариант без inline:
.L2: xorl %eax, %eax call get_inc_val@PLT cltq addq %rax, %rbp cmpq %rbx, %rbp jle .L2вариант с inline (тут я использовал volatile, чтобы компилятор не выбросил цикл совсем, так что появился «лишний» код, без него, теоретически, должно быть быстрее):
.L5: movq 8(%rsp), %rax addq $3, %rax movq %rax, 8(%rsp) movq 8(%rsp), %rax cmpq %rdx, %rax jle .L5Armmaster Автор
01.08.2021 20:27У вас в первом варианте функция вообще через PLT вызывается, а во втором со стэком идёт работа, что явно не -O3 (или volatile к такому привёл). Сейчас приведй пример ассемблера, который у меня получился.
edo1h
01.08.2021 20:37У вас в первом варианте функция вообще через PLT вызывается
да, я её поместил в отдельный .c файл.
или volatile к такому привёл
да, я же про это написал
Armmaster Автор
01.08.2021 21:22+2Так, со временем кода с вызовом я наврал . Там компилятор разобрался, что значение в вызове не меняется и просто убрал его из цикла. Я добавил asm ("nop") в код функции, в итоге получил ~1с.
Дизасм кода с инлайном (0.3 с) :
main: ... 4f8: 90 nop 4f9: 48 83 e8 01 sub $0x1,%rax 4fd: 75 f9 jne 4f8 <main+0x8>Дизасм кода без инлайна (~1с):
0000000000000630 <get_val>: 630: 90 nop 631: b8 01 00 00 00 mov $0x1,%eax 636: c3 retq main: ... 500: 31 c0 xor %eax,%eax 502: e8 29 01 00 00 callq 630 <get_val> 507: 48 01 c2 add %rax,%rdx 50a: 48 81 fa ff c9 9a 3b cmp $0x3b9ac9ff,%rdx 511: 76 ed jbe 500 <main+0x10>Тут в глаза бросается, что у нас не очень оптимально цикл получился во втором случае (2 лишних операции + 16 байтную границу кода пересекли 2 раза, не считая call, а это лишние ifetch). Но дальше ковыряться с компилятором мне лень, считаем что в таком случае работаем 3 такта. Можно потестить на топовых Интелах, там фронтенд шире и по идее должен всё скушать за 1-2 такта.
edo1h
01.08.2021 22:10ну в любом случае накладные расходы на вызов функции получились удивительно маленькими, спасибо, что открыли на это глаза.
edo1h
03.08.2021 08:07Таким образом мы получаем минимум 2-3 инструкции
даже так, согласитесь, это очень немного.
тут рядом для эльбруса озвучили 17 тактов на call/ret.
edo1h
03.08.2021 09:47+1Перечитайте ещё раз. Это самый минимум в вырожденно-лучшем случае
перепроверил на свежую голову: привёл ассемблерный код к одному виду, получил разницу 3-5 тактов на цикл (в зависимости от процессора) на коде с call/ret и без него.
kosmos89
01.08.2021 19:35За последние 10 лет процессоры принципиально не ускорились. И это и есть основная проблема SSOoO - их дальше становится нецелесообразно ускорять.
creker
01.08.2021 19:41+1Вы видимо последние несколько лет на процессоры не смотрели. Очень даже ускорились, по крайней мере амд варианты, что интел все никак догнать не может. И с каждым поколением IPC все больше и больше. Число ядер тоже выросло кардинально и планируется нарастить еще больше благодаря прогрессу в интерконнектах и производстве чипов. Не знаю, чего там нецелесообразно ускорять, но амд ускоряет и постоянно вносит правки в микроархитектуру.
kosmos89
02.08.2021 00:33Ничего себе растет. Вы помните, как росла производительность лет 20 назад? А что сейчас? Почему тогда мне особо не на что поменять процессор 10-летней давности за разумные деньги? Да даже за неразумные я получу максимум 50% прироста на ядро. И это за 10 лет? Это шутка такая? А до недавнего выхода zen 3 и этого не было. У Интел с Core 2000 где-то по Core 8000 вообще прирост был мизерный.
Некоторые специалисты вообще говорят, что график роста переломился в 2006 году (собственно, и неспециалисту это наглядно видно на графике). А второй раз году в 2011.
creker
02.08.2021 00:46-1У вас было два тезисе. «За последние 10 лет процессоры принципиально не ускорились» если у вас настолько большие запросы, то наверное не ускорились. Я по графикам вижу постоянный рост от поколения в поколение, плюс повышение числа ядер. Можно спокойно периодически менять проц и видеть серьезный прирост.
Второй тезис — «их дальше становится нецелесообразно ускорять». Это просто неправда. Производительность растет, микроархитектура постоянно оптимизируется.kosmos89
02.08.2021 00:55+2>микроархитектура постоянно оптимизируется
каждая следующая оптимизация в среднем дает меньше прироста и стоит дороже. Висящие на нижних ветках фрукты собраны. Дальше станет только хуже.>у вас настолько большие запросы
Очень даже обычные. Ну серьезно, какому пользователю есть смысл покупать процессор процентов на 30 быстрее за немалые деньги?
И от числа ядер далеко не все задачи выигрывают. Вообще рост числа ядер как раз от сложности дальше ускорять одно ядро.
Вот расскажите, какие вы видите пути существенного ускорения SSOoO процессоров?
edo1h
02.08.2021 04:34Почему тогда мне особо не на что поменять процессор 10-летней давности за разумные деньги? Да даже за неразумные я получу максимум 50% прироста на ядро. И это за 10 лет?
Если вспомнить, что их этих 50% львиная доля приходится на последние 2-3 года, то всё не так уж плохо.
Ну и непонятно, почему вы сбрасываете со счетов многоядерность. Рост частоты не может быть бесконечным, с ростом ipc тоже не всё просто, так что основной вектор развития сейчас — рост числа ядер, тут пока всё хорошо. Да, требуется поддержка со стороны софта, но она неизбежно будет всё лучше и лучше.kosmos89
02.08.2021 05:50> она неизбежно будет всё лучше и лучше
Это говорят уже 15 лет. И все равно приходится продолжать говорить. Потому что многопоточная обработка порой очень сложно даётся.
edo1h
02.08.2021 08:55Это говорят уже 15 лет
и все 15 лет идёт увеличение числа ядер на декстопах, телефонах и т. п.
DistortNeo
02.08.2021 09:37Вот телефоны здесь вообще не к месту. В телефонах главный ограничивающий фактор — энергопотребление. По мере повышения энергоэффективности процессоров росло значение IPC, и пока ещё есть куда двигаться дальше в этом направлении.
Так, за последние 10 лет производительность на ядро для мобильных процессоров выросла почти на порядок, тогда как для десктопных процессоров — в полтора-два раза.
edo1h
02.08.2021 10:20но и число ядер в телефона за те же 10 лет увеличилось на порядок, было бы странно наращивать их число, если софт не умел использовать более одного ядра
Am0ralist
02.08.2021 10:28+1Вот только на примере 8 ядерных телефонных процессоров — там обычно 4 энергоэффективных медленных ядра и 4 больших жрущих дуры. Плюс при работе смартфона обычно далеко не один поток данных. То есть 4 ядра хорошо иметь просто ради того, чтоб потоки друг другу не мешались. А вот в умеющий потоки софт — это игры и какие-нибудь видеообработки или нейронки.
Кстати, про «на порядок» — в 11 году были точно 2-ядреные процы, разве сейчас где-то в смартфонах есть ⩾20 ядер и я что-то пропустил?
Armmaster Автор
01.08.2021 19:44+5Последние 10 лет производительность процессоров растёт как раз за счёт улучшения микроархитектуры. Хотя , конечно же, рост там не такой, как в 90-х и начале 2000-х
kosmos89
02.08.2021 00:34Вот именно, за 10 лет получили 50% прироста. И какой ценой? Это говорит о том, что пора что-то менять. Например, систему команд с последовательной на явно параллельную.
Armmaster Автор
02.08.2021 00:53Изменение системы команд с последовательной на явно параллельную само по себе ничего не даст, пример Эльбруса это ярко демонстрирует. Современные процессоры умеют сами извлекать эту параллельность из кода.
kosmos89
02.08.2021 01:01+1Они умеют извлекать очень мало параллельности. К тому же, зачем ее извлекать, когда ее можно явно закодировать?
А то как-то странно получается, что мы пишем алгоритм (может даже в какой-то степени параллельный) на последовательном языке, потом процессор пытается извлечь параллелизм, и потом он же пытается заретайрить инструкции последовательно. Хотя можно было бы тут везде иметь слово "параллельно".
qw1
02.08.2021 09:28Весь код можно поделить на «классический последовательный» — это работа GUI (диспетчеризация вызовов), чек-суммы, сортировки, кодирование-декодирование Хаффмана и т.п.
И на «числомолотилки».
В первом случае «извлечь параллелизм» можно неглубокий, максимум на конструкциях типа (x+1)*(y+1), и там за 20-30 лет процессоры прекрасно справляются через OoO.
Это в 1990-х было сакральной идеей, что в выражении (x+1)*(y+1) компилятор должен указать порядок вычислений, сейчас это не актуально.
Во втором случае, с числомолотилками, хорошо справляется SSE/AVX.
Я не понимаю, почему вы хотите принципиально разные задачи обрабатывать единообразно. Понятно же, что специализированное решение будет быстрее, чем пытаться натянуть один VLIW на все случаи.
kosmos89
02.08.2021 01:02На столько умеют, что пришлось придумывать AVX512.
Armmaster Автор
02.08.2021 01:15Они умеют извлекать очень мало параллельности. К тому же, зачем ее извлекать, когда ее можно явно закодировать?
Потому что в огромном количестве случаев её нельзя "закодировать", т.к. не хватает информации для статического анализа.
На столько умеют, что пришлось придумывать AVX512.
Если мы не говорим об изменении алгоритма, то параллельность, которую эксплуатирует AVX512, процессор вообще говоря видит. Там проблема в том, что он не всегда может эффективно использовать её. Поэтому, чем городить огород в микроархитектуре и тратить на это много транзисторов и энергии, проще сделать новые архитектурные расширения.
kosmos89
02.08.2021 02:01>Там проблема в том, что он не всегда может эффективно использовать её. Поэтому, чем городить огород в микроархитектуре и тратить на это много транзисторов и энергии, проще сделать новые архитектурные расширения.
Ну вот собственно, вы и признались, что дальше уже не получается получить параллельность, приходится использовать другую систему команд.
>параллельность, которую эксплуатирует AVX512, процессор вообще говоря видитчто-то я сомневаюсь, что процессор видит на 16 инструкций вперед, да еще и налету. А если предсказатель ошибётся, сколько тогда будет стоить эта ошибка? За 1 такт же он не сможет 16 инструкций заново проанализировать.
Armmaster Автор
02.08.2021 02:15+5Ну вот собственно, вы и признались, что дальше уже не получается получить параллельность, приходится использовать другую систему команд
Я написал совершенно другое - то, что используется более эффективный подход. Просто нет смысла городить огород ради специфических задач, где AVX512 даёт реальный привар. На большинстве кода от него толку ноль
что-то я сомневаюсь, что процессор видит на 16 инструкций вперед
Правильно сомневаетесь, он видит вперёд примерно на 100 инструкций.
А если предсказатель ошибётся, сколько тогда будет стоить эта ошибка?
Цена ошибки предсказателя сильно зависит от микроархитектуры, но можете считать что она ~20 тактов. Но там, где используется AVX512, считайте что ошибок предсказателя не бывает.
edo1h
02.08.2021 04:38+1Ну, во-первых, есть и обоснованная позиция «avx512 не нужно».
Во-вторых, avx512 даёт гигафлопсы числодробилкам, не ломая при этом производительность обычных приложений. Не особо ломая, как минимум.
anonymous
00.00.0000 00:00
flx0
01.08.2021 23:33Я прикинул для Арм64 на Cortex-A77 по данным отсюда, для кода, скомпилированного в моей голове с -О0:
# pipeline | latency / throughput # (такты / количество подходящих пайплайнов) // while (a < 10000) { 0: CMP X1, #10000 // I | 1 / 3 BGE 1f // B | 1 / 2 // a += get_inc_val() BL get_inc_val // B | 1 / 2 ADD X1, X1, X0 // I | 1 / 4 B 0b // B | 1 / 2 // } 1: ...Первые 2 инструкции не паралеллятся, так как BGE ждёт результатов CMP. А вот BGE и BL похоже сработают одновременно на пайплайнах B0 и B1 (при необходимости результат второй будет отброшен), ADD будет их ждать, и выполнится одновременно с последней B, а CMP следующей итерации, соответственно, ждет ADD. Итого получается 3 такта на собственно итерацию цикла, плюс сколько-то внутри функции.
Но кажется можно сэкономить еще такт, введя дополнительный счетчик, чтобы CMP не ждал результата в X1 (думаю что компилятор так и сделает, но проверять лень):
... MOV X2, #10000 0: BLE 1f // B | 1 / 2 BL get_inc_val // B | 1 / 2 ADD X1, X1, X0 // I | 1 / 4 SUBS X2, X2, X0 // I | 1 / 3 B 0b // B | 1 / 2 1: ...То что вне цикла неинтересно, BLE и BL заходят в B0 и B1 параллельно, ADD и SUBS тоже параллелятся и заходят в 2 разных пайплайна I, B выполняется одновременно с ними, итого всего 2 такта.
true-grue
01.08.2021 15:50+5Пункты автора об "эльбрусах" я затрагивать не буду, однако, автор, на мой взгляд, увлекся и перешел к неверным обобщениям. Два положения из заметки, определенно, напрашиваются на комментарии.
Архитектура VLIW "плоха": менее производительна чем RISC/CISC и не энергоэффективна.
Оригинальные процессорные архитектуры разрабатывать вовсе не следует.
Выше уже справедливо заметили, что в области специализированных процессоров первое положение полностью безосновательно. Но специализация может быть достаточно широкой. Возьмем, к примеру, VLIW-процессор 2018 года от Kalray для задач Embedded HPC, Networking, Storage. Что он собой представляет: 16 nm, 85 64-bit VLIW-ядер, энергопотребление 5-15W. Тактовая частота (1.2 Ghz) этого процессора даже ниже, чем у современных "эльбрусов", но, очевидно, это еще ни о чем не говорит, правильно?
Почитайте того же Д. Паттерсона -- он считает VLIW-архитектуры вполне перспективными и для будущих domain specific architectures. Даже в популярной архитектуре RISC-V нашлось место стандартному VLIW-расширению.
И я уже не говорю о том, что сама классификация RISC/CISC уже сильно устарела. Есть хорошая фраза в одной недавней статье: "CPUs are gradually becoming sets of discrete accelerators around a shared register file".
По поводу целесообразности создания собственных архитектур. Работа в проекте по созданию процессора с оригинальной архитектурой -- это ценнейший практический опыт для представителей целого ряда редких профессий (RTL-дизайнеры, топологи, компиляторщики, ...). Это важно и для развития академических исследований. В мире количество экзотических процессорных архитектур только растет. Из свежего могу, к примеру, вспомнить Ascenium Aptos и Tenstorrent Tensix. В целом, отмена закона Деннарда, замедление выполнения закона Мура -- побуждают искать новые решения в области процессорных архитектур. Современные технологии компиляции и средства разработки компиляторов (те же LLVM/MLIR) сильно снижают остроту проблемы "процессор-то мы спроектируем, а где оптимизирующий компилятор взять".
Уверен, что заметка получилась бы лучше, если бы автор сконцентрировался исключительно на критической оценке "эльбрусов" в конкретной области их применения.
Armmaster Автор
01.08.2021 16:33+6Вообще-то в заголовке чётко написано про "general purpose CPU". То, что VLIW может быть неплох в каких-то специализированных применениях - спору нет, никто про это не говорил, вы невнимательно статью прочитали.
Что касается "ценнейшего" опыта. Ценнейший практический опыт - это когда вы создаёте продукт, конкурирующий с последними Интелами. А для этого надо уметь проектировать сложную микроархитектуру процессора. А в случае Эльбруса как раз этот момент не развивается - парадигма другая. А создать собственную архитектуру я могу на коленке за вечер под пиво. В этом нет никакой особой научной ценности на самом деле.
true-grue
01.08.2021 16:52+4Имело бы смысл упомянуть о современных применениях VLIW, чтобы не было вопросов к уровню компетентности автора. Вы же в тексте просто "поставили крест" на архитектуре. Это относится и к весьма наивному разделению на CISC (x86) и RISC (ARM). Я, конечно, могу предполагать, что Вы в таком ключе пишете, рассчитывая на аудиторию, не вникающую в подобные тонкости, но, все же.
А вот реакция на мои слова о "ценнейшем опыте", как мне показалось, получилось чрезмерной. Уже достаточно давно процессоры не принято разрабатывать "на коленке за вечер под пиво". Мне кажется, Вы здесь поторопились с ответом и, на самом деле, вполне в курсе понятий design space exploration, compiler-in-the-loop, hardware/software codesign. Процессор со статическим параллелизмом -- как раз очень интересный объект научного исследования на компиляторную тематику. По мотивам "эльбрусов" мне вспоминается несколько вполне приличных научных статьей, диссертаций и даже стартапов международного уровня.
vkni
01.08.2021 19:05+1Ещё можно добавить доведение продукта до конечного потребителя. То, что может использовать «баба Маша», и то, что находится в лабораториях — это совершенно разные вещи. Это тоже очень ценный опыт.
beeruser
02.08.2021 16:09-1Имело бы смысл упомянуть о современных применениях VLIW
Например какие?
Остались только DSP-хи TMS или Hexagon.
Из CPU общего назначения и GPU VLIW давно выкинули.
Мне нравится VLIW сам по себе. Руками на асме набивать слоты — это классно.
Но я реалист и понимаю что это нежизнеспособная технология за пределами DSP.Процессор со статическим параллелизмом — как раз очень интересный объект научного исследования на компиляторную тематику.
«Весёлый рисёрч». Пусть таким и остаётся.
yalex1442
01.08.2021 17:34+6>Ценнейший практический опыт - это когда вы создаёте продукт, конкурирующий с последними Интелами.
Приравнивание последних интелов с эльбрусами с его бюджетом равным бюджету на дизайн наклеек этих самых современных чипов выглядит как скрытая реклама Эльбрусов)
vkni
01.08.2021 19:02+1Что касается «ценнейшего» опыта. Ценнейший практический опыт — это когда вы создаёте продукт, конкурирующий с последними Интелами.
Это опыт мирового уровня. Вроде как больше нет нигде VLIW в железе в качестве «general purpose CPU». Это громадный спектр проблем, которые доходят даже до уровня «техподдержка в Astra Linux».
Этот опыт открывает возможность создания и развёртывания каких-то других совершенно не RISC/CISC архитектур — мы же надеемся, что текущее состояние процессоростроения — это не конец развития.
Наша страна редко где находится на переднем крае. И будет очень жалко лишиться такого опыта со всех точек зрения.Armmaster Автор
01.08.2021 19:22С таким подходом мы никогда не будем делать процессоры мирового уровня. Вообще, умение признавать ошибки - это залог успешного развития.
vkni
02.08.2021 06:26Он уже мирового уровня. Никто больше не делает универсальные VLIW процессоры.
Да, сейчас эта ветка выглядит менее перспективно, чем ведущие RISC/CISC. Но отставание-то, положа руку на сердце, невелико (на уровне софта даже 4 раза в скорости процессора почти не чувствуется — почти всегда можно что-то оптимизировать на порядок).
А самое главное — нельзя класть все яйца в одну корзину. И тут РФ вносит свой, пусть и не очень большой, но настоящий вклад в мировое процессоростроение, поддерживая маргинальную ветвь, которая в перспективе может выстрелить.amartology
02.08.2021 09:09Никто больше не делает универсальные VLIW процессоры.
Паровозы тоже больше никто не делает. Потому что появились превосходящие их решения.А самое главное — нельзя класть все яйца в одну корзину.
Вот чего, а корзин с микропроцессорами в РФ с десяток. Есть микроархитектурные разработки MIPS, SPARC, power, RISC-V, кварк, кролик… да даже 32-битная версия mcs-96 есть. Плюс пачка спецвычислителей — ELcore, neuromatrix, комдив-128, мультиклет, IVA.
На фоне этого разнообразия Эльбрус выделяется исключительно агрессивным маркетингом, а не какими-то выдающимися ноу-хау.vkni
02.08.2021 10:52+1Эльбрус — это, всё-таки, уникальная экосистема, доведённая до потребителя (я участвую в проекте ALT, который работает на e2k). То есть, это не просто набор инструкций и какое-то количество камней, это ещё компетенции по созданию универсального АПК (аппаратно-программного комплекса).
Эти компетенции не ограничиваются МЦСТ, есть ещё масса других контор, других людей.
Все остальные микроархитектуры не имеют вот этой сквозной экосистемы внутри РФ. Они требуют внешних специалистов.
Кстати, RISC-V вроде как ещё не имеет серийного десктопа, ждём с нетерпением. А MIPS/SPARC уже давно не имеют серийного десктопа (поэтому у меня дома стоит SunBlade пятнадцатилетнего возраста).amartology
02.08.2021 11:51Все остальные микроархитектуры не имеют вот этой сквозной экосистемы внутри РФ.
КОМДИВ имеет.vkni
02.08.2021 11:55MIPS умер.
amartology
02.08.2021 15:32MIPS умер.
MIPS — возможно, а КОМДИВ — нет.
И вокруг него прямо сейчас имеется достаточно «компетенций по созданию универсального АПК (аппаратно-программного комплекса).»
В частности, ПК на КОМДИВе я видел своимии глазами еще лет пять назад.
Насколько это перспективная история — другой вопрос. Но ваша фраза «Все остальные микроархитектуры не имеют вот этой сквозной экосистемы внутри РФ. Они требуют внешних специалистов» по состоянию на сегодня не является правдой.
OpenA
06.08.2021 16:32Цимес в том что весь перечисленный зоопарк не обладает стеком унникального софта как intel и arm, они все вместе с эльбрусом могут рпассчитывать максимум на открытое ПО под линукс и ПО от отечественных разработчиков, никакой риск-5 который по скорости будет максимум как эльбрус, не поможет, никто на него не перенесет ни кады ни сапры его самого будут проектировать на интеле а путину чемезов представит очередной планшет, только уже с третьегномом если его к тому времени портируют с полноценной графикой. Это максимум что будет через 5лет, очередной никому не нужный процессор без софта.
Надо все силы киидать в софт, переносить всё необходимое спо под эльбрус, допиливать трансляцию x86, чтоб где это безальтернативно, он мог интел заменить.
Байкалу дать по репе и привести их в чуства, у нас огромный спрос на арм/мипс устройства, мультимедийные системы типа яндекс авто, сеилфиш ос она же аврора, роутеры всякие, кассы станки, они компьютеры на линуксе собирают никому не нужные и лезут в госзакупки по квотам, и еще серверы собираются так же толкать, они или не нормальные или кто-то там пилит бабло тупо.
Элвису пусть делает ускорители потокового видео и прочего, модуль тензорные ядра и всех объеденить в группу чтоб использовали наработки друг друга и свободно лицензировались.
amartology
06.08.2021 17:53+1риск-5 который по скорости будет максимум как эльбрус
Расскажите об этом Apple M1 и AWS Graviton.и всех объеденить в группу чтоб использовали наработки друг друга и свободно лицензировались
АХАХАХАХАХАХАХАХ
СЧАСТЬЯ ВСЕМ, ДАРОМ И ЧТОБЫ НИКТО НЕ УШЕЛ ОБИЖЕННЫМ
Такого примерно у вас уровня рассуждения. Жаль только к реальности они имеют примерно ноль отношения.OpenA
06.08.2021 19:54Ты в барнауле живешь, ау. Причем здесь эпл или гравитон?
Риск-5 это система команд, простая, последовательная, сама она дает только бинарную совместимость (с кое как портированным на нее спо, лол) все что нужно для ее эффективного исполнения необходимо разрабатывать с нуля. Хотя бы на уровне кортексов не самых новых, а уж что бы их переплюнуть и подобраться ближе к интел/амд надо перейти на кастомный физ. дизайн. Уверен в 2ггц 12нм восьмиядернике все будет и физдизайн и кокаин и шлюхи. И все на частные деньги - 18млрд даст частная компания ростех а 5млрд ядро возьмет кредитом во внешэкономбанке у шувалова, и на госзакупках в школы и куда то там еще отобъют, все честно рыночно, интел напрягся.
amartology
06.08.2021 21:51+1все что нужно для ее эффективного исполнения необходимо разрабатывать с нуля
Далеко не с нуля.надо перейти на кастомный физ. дизайн.
Вот эта мантра про мифический кастомный физдизайн, честно говоря, надоела уже хуже горькой редьки. Особенно — в исполнении людей, которые никогда не видели никакой физдизайн.OpenA
07.08.2021 08:03-4О, кастомный дизайн - лженаучный миф капитализма https://www.electronicdesign.com/technologies/analog/article/21807187/11-myths-about-custom-silicon
А под светлым знаменем risc-v пролетарии всех стран объединятся и пойдут в светлое будущее. Уже тысячи компаний обратили на него свой пристальный взор и нет никаких сомнений, товарищи, что это будущее вот вот наступит. Нет, мы уже в нем живем, прямо сейчас. Предлагаю единогласно проголосовать "ЗА". Похлопаем.
amartology
07.08.2021 09:17+4Дада, я именно об этом — вы настолько не понимаете, о чем речь, что прислали мне ссылку на рассказ «чем заказная ASIC лучше FPGA», а не на что-то имеющее отношение к кастомному физдизайну. Собственно, по ссылке вообще никакой физдизайн не упоминается ни разу.
В следующий раз, пожалуйста, больше внимания уделяйте фактам, а не своему феерическому сарказму. А то может случиться, что в Барнауле это вы живёте, а не собеседник.
OpenA
07.08.2021 10:01Это что, шутка? Кто вообще на серьезных щах будет доказывать что кремний лучше чем фпга.
Полагал ты скажешь что нибудь типа реклама компаний которые на кастомных блоках бабки дела делают но отрицания вообще не ожидал. https://www.asicnorth.com/offerings/
ASIC North will work with your design team to create and verify a custom Intellectual Property (IP) block design. We have years of experience developing IP blocks such as biomedical sensor interfaces, voltage references, multiple A/D and D/A converters architectures, RFID circuits, IoT components and more.
We will also generate a complete set of IP deliverables (*.v, *.lib, *.lef, etc) which allow you to easily integrate the IP into your ASIC design.
И чтоб совсем уж поставить точку в вопросе:
https://www.eng.uwo.ca/people/wwang/ece616a/616_extra/notes_web/1_dintro.pdf
amartology
07.08.2021 10:12+1Кто вообще на серьезных щах будет доказывать что кремний лучше чем фпга.
Те, кто умеет считать экономическую модель на малых и средних тиражах. ASIC всегда строго лучше технически, но не всегда имеет экономический смысл.Полагал ты скажешь что нибудь типа реклама компаний которые на кастомных блоках бабки дела делают
Я сам работаю в такой компании, если что.
Только вот кастомные блоки не имеют отношения к кастомному физдизайну цифровой части чипа. Он всегда делается автоматизированно. А то, о чем вы говорите — это типичнейшая разработка IP-блоков под конкретного заказчика. Принципиально такие блоки ничем не отличаются по качеству от IP-блоков более широкого применения, если только у заказчика нет каких-то очень специфических нужд. И в случае с цифровыми чипами блоки (кроме памятей и mixed-signal) поставляются в виде RTL-кода, а физдизайн делает сам заказчик.
А вы все ещё не понимаете сути собственной фразы про кастомный, напоминаю, ФИЗдизайн. Поэтому и мешаете с ним в кучу совершенно не связанные вещи.
OpenA
07.08.2021 12:31-2Я обычный человек и говорю так как понятно мне и таким же как я. Под физ.дизайном я в данном контексте подразумеваю дизайн транзисторных блоков/элементов а не какой то логики. То что это в какой то там среде проектировщиков считается оскарблением меня не касается, завтра придет дядя вася с паяльником и скажет что ФИЗ это когда ты вот руками берешь травишь, паяешь, дорожки чертишь и у них в мастерской за такие ошибки вообще убивают сразу же.
Ещё в первой статье выше (которая якобы про фпга), содержит раздел про Analog-Digital Mixed дезигн - оно? Как бы там нибыло я подразумеваю разработку специальных блоков под разные устройства, не может это не давать прирост.
Вон мцст сделали кастом дизайн кешей у них поместилось 1мб L2 на ядро вместо прежних 512к. Сразу же вспоминаются интел и амд середины нулевых, у амд и полноценный четырехядерник и мму в кристалле но кэш 300кб на ведро и слив интелу с кэшами полтора три мегабайта.
amartology
07.08.2021 13:11+2Я обычный человек и говорю так как понятно мне и таким же как я.
При этом, к сожалению, перевирая суть. Именно вот это постоянное непонимание и перевирание людьми, далекими от сути задач, и вызывает у меня негодование и усталость.Под физ.дизайном я в данном контексте подразумеваю дизайн транзисторных блоков/элементов а не какой то логики.
А логика по-вашему не из транзисторов делается?Ещё в первой статье выше (которая якобы про фпга), содержит раздел про Analog-Digital Mixed дезигн — оно?
Нет, не оно. Фраза про «надо перейти на кастомный физдизайн, чтобы догнать Интел» говорит о ручном рисовании топологии именно цифровых блоков — в противовес автоматизированной разводке, которая применяется на самом деле. А дизайн аналоговых и mixed-signal блоков в любом случае ручной и в любом случае не влияет на производительность цифровой логики. Вот и получается ровно то, о чем я сказал — вы услышали где-то мантру про то, что нужен кастомный физдизайн, а что она означает, толком не понимаете. И тот, от кого вы ее услышали — тоже не очень понимал.Вон мцст сделали кастом дизайн кешей у них поместилось 1мб L2 на ядро вместо прежних 512к.
Это хорошо и правильно, но не имеет отношения к «кастомному физдизайну». Все, сто разумно делать руками и делать самостоятельно — в Эльбусах уже делается именно так, и никаких огромных резервов для повышения производительности в этой части нет уже давно.
OpenA
07.08.2021 14:26-6Товарищь профессионал форумов и клавиатуры, маневры от отрицания до придирок к каким то якобы не правильным терминам я могу проигнорировать, но обвинения меня в мантрах и тут же мне зачитать мантру про то что в эльбрусе там все уже что можно сделано и все , не на что тут смотреть это просто ни в какие ворота уже. С чего ты это взял вообще, ты в глаза не видел кто и на чем его разрабатывает и такие заявы делаешь.
amartology
07.08.2021 17:08+1Я, в отличие от вас, профессионал не в хамстве, а в разработке микросхем. И поэтому довольно хорошо себе представляю, кто, как и на чем проектирует Эльбрусы — и знакомых в отрасли порядочно, и публикуется в профильных изданиях МЦСТ очень много.
Civil
06.08.2021 18:20+1Мне кажется Вы не очень понимаете что такое risc-v и сколько людей и компаний его развивают. Одно из преимуществ тут в том, что на него сейчас активно смотрят множество компаний во всем мире и активно портируют под него софт (преимущества открытой ISA и относительно доступных dev-плат, которые и дешевле Эльбруса и в отличии от него можно купить в интернете). Просто для справки - сейчас на risc-v работает примерно 95% пакетной базы debian unstable. Просто из коробки, только добавь свое ядро (если плата в mainline не поддерживается):
civil@debian:~$ apt-cache show gnome-shell | head -n 3 Package: gnome-shell Architecture: riscv64 Version: 40.2-1А насколько оно хорошо работает - зависит графики. К сожалению на девайсе что у меня нет 3D ускорителя, а только с 2D графикой и llvmpipe'ом далеко не уедешь в плане десктопа.
никакой риск-5 который по скорости будет максимум как эльбрус
Более чем спорное утверждение, с учетом того что Байкал-М1 уже в целом догнал или даже перегнал Эльбрус, по производительности на МГц у даже некоторые российские компании (см. cloudbear BI-674) показывают лучше результаты (понятно что надо ждать реальных изделий, но нет причин полагать что они окажутся сильно хуже, чем заявленное). Так что если даже просто лицензировать их ядро - будет уже строго лучше. И я молчу о ядрах от SiFive, которые бывают еще быстрее.
Надо все силы киидать в софт, переносить всё необходимое спо под эльбрус
Вы как будто статью, которую комментируете, не читали. С ее учетом и с учетом того что я выше про risc-v написал, точно ли не пора подвести итоги и признать что Эльбрус это тупиковый путь развития?
И да, я писал выше в том числе про детские болезни risc-v, и я по-прежнему уверен что ARM в текущий момент лучше как краткосрочный путь развития. Но тем не менее risc-v куда более перспективная штука, нежели Эльбрус.
OpenA
06.08.2021 22:45-4для моторолы68k в дебиане наверное пакетов еще больше и что? либреофис запущеный на "правильном процессоре" майкрософт офисом не станет. Эльбрус лучше потому что мцст контролирует систему команд, патенты с ней связанные, систему прерываний, всю платформу. Имеет ядерщиков, библиотечников и компиляторщиков. Охват базового стека софта и полный контроль железа приблежает на одну ступеньку к таким компаниям как интел и нвидиа, про которых кто бы что не говорил но их железо ставят в серьезные системы, а в амд только школьники гоняют в киберпанк и майнят. Тот же майор может позвонить в мцст и сказать: "на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь" и мцст выделит специалиста заниматься этим делом либо знает кому передать на аутсорс, а что скажет байкал или синтакор? "пишите в мазилу в багзиллу или nekonekonyan -у в гит ижуи, мы к софту который на нашем железе работает не имеем отношения"? Сопровождение нужного тебе софта и помощь от сообщества ты не получишь нахаляву, все равно требуется чью то еще отдельно покупать. Свободное от патентов ISA - это не спо и не свободное железо даже, его нельзя взять себе как нельзя взять себе питон или с++, это стандарт только языка железа. я не слышал аргументов в духе "зачем делать раст если есть го", или "зачем делать свифт если есть котлин". или вот зачем эплу понадобился Obj-c вместо плюсов? Да потому что у них было иное виденье ООП и оно лучше реализовывало те задачи, которые эпл реализовали в своей ос и ее api. Примут ли в риск-5 расширения касающиеся ускорения российских криптоалгоритмов, или там тензорных для росатома или двигателистов? Никогда, а вот aes или sha1024 я уверен вполне. Про безопасные режимы даже говорить бессмысленно, нужна ли нам не удобная под наши задачи, а некая "стандартизированная" какими то джонами система команд? Я не вижу в этом плюсов, одни минусы. Отпортировать весь стек СПО и протолкнуть арч в апстримы это дело наживное, хоть и не простое в случае с эльбрусами тупо в силу того что это в первую очередь теговая и стековая архитектура, что создает проблемы в адаптации низкоуровневых приложений, ну и влив мешает портированию компиляторов. Но зато все знают что е2k это е2k, семейство процессоров с конкретной архитектурой а не подмножество с вольным набором расширений.
Am0ralist
06.08.2021 22:58+1а в амд только школьники гоняют в киберпанк и майнят.
ага, а так же куча суперов сделана и строится, ибо не на интеле же их собирать последние года, даа
qw1
07.08.2021 02:09+2Тот же майор может позвонить в мцст и сказать: «на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь»
Как у нас решаются проблемы, я скорее поверю в то, что пользователь, который запостил злополучного тормозящего браузер котика, поедет в Магадан валить лес. Ну а что, диверсия против православной архитектуры, не иначе.
Civil
07.08.2021 02:36+1для моторолы68k в дебиане наверное пакетов еще больше и что?
Во первых не важно сколько для моторолы68k, важно что больше чем на Эльбрус в данном случаи. Притом всего за пару лет.
Ну к тому же не больше, больше только на ppc и мажорных архитектурах. Под m68k собрано где-то 85% пакетной базы деба.
Эльбрус лучше потому что мцст контролирует систему команд, патенты с ней связанные, систему прерываний, всю платформу. Имеет ядерщиков, библиотечников и компиляторщиков.
Первая часть как раз еще один минус Эльбруса. Не такой важный как качество архитектуры конечно, но следующий за этим. А почему? Да потому что монополия на архитектуру ведет к текущей ситуации, когда все закрыто донельзя и никто не спешит открываться.
А ядерщики-библиотечники-компиляторщики могли бы с тем же успехом пилить под RISC-V или ARM, был бы тот же эффект.
Охват базового стека софта и полный контроль железа приблежает на одну ступеньку к таким компаниям как интел и нвидиа
И Вы привели в пример компании, которые стали тем что они сейчас благодаря открытой инфраструктуре и понятной ISA. А одна из них вообще жива только потому что поделилась лицензией на свою ISA с несколькими другими компаниями. Пример хороший, но к сожалению против Вашего же утверждения.
а в амд только школьники гоняют в киберпанк и майнят.
Вопрос на засыпку: сколько из мажорных игроков (топ10 например) на рынке облачных вычислений не предоставляют решений на AMD?
Тот же майор может позвонить в мцст и сказать: "на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь" и мцст выделит специалиста заниматься этим делом либо знает кому передать на аутсорс
Не вижу почему была бы такая уверенность. МЦСТ выделит специального человека, который объяснит товарищу майору в очередной раз, что это все авторы ВК или браузера, а не они виноваты, так как принципиально вопрос они решить не смогут.
Сопровождение нужного тебе софта и помощь от сообщества ты не получишь нахаляву, все равно требуется чью то еще отдельно покупать.
Так ровно потому что разработка и сопровождение это тяжкий труд и стоит фокусироваться на том, что действительно работает как положено. Представь себе, какая помощь была бы всем, если бы компиляторщики МЦСТ вкладывались бы в развитие того же risc-v? Ну или в софт, который правда нужен заказчику. Сейчас этот ресурс тратится впустую.
Примут ли в риск-5 расширения касающиеся ускорения российских криптоалгоритмов, или там тензорных для росатома или двигателистов? Никогда, а вот aes или sha1024 я уверен вполне.
В данном случаи за такой уверенностью должна быть какая-то фактическая база. Собственно почему Вы так уверены, что не примут? Это впрочем касается всего Вашего поста.
DistortNeo
03.08.2021 18:22+1Отлично, мы пришли к явной однородной адресации памяти. Для одноядерного процессора — норм. Но что предлагаете делать для многоядерных процессоров, разделяющих общую память? Согласовать доступ к памяти между ядрами вы никак не сможете, и поэтому время доступа к памяти будет недетерминированным. А это уже задержки при явном параллелизме.
А что делать с виртуальной памятью? При таком подходе мы не сможем позволить процессору запинаться на page fault при обращении к памяти.
Какой код, чего делать? Что это значит? Откуда он(код) взялся? На что это ответ? Как он связан с цитатой?
Я к тому, что невозможно на практике сбалансированно загружать все вычислительные устройства.
DistortNeo
03.08.2021 20:14Какой-нибудь атомарный доступ к общей памяти детерминирован.
А, собственно, почему? Память у нас медленная, работает по принципу "вас много, а я одна", даже одно ядро может полностью утилизовать её пропускную способность. Если 16 ядер одновременно захотят прочитать данные из памяти, то их хотелки будут обрабатываться по очереди. Немного улучшит эту ситуацию использование многоканального доступа и интерливинга.
И это я ещё не затронул тему примитивов синхонизации, lock-free контейнеров.
Armmaster Автор
02.08.2021 11:25Отставание огромно и они в рамках данной VLIW архитектуру непреодолимо. Это то, что я показываю в статье. А то, что делаете вы - это кормите обещалками людей, заведомо вводя их в заблуждение.
vkni
02.08.2021 11:57Да начхать на эти 10 раз максимум. Впрочем там нет 10 раз, там есть ну 2-4.
DistortNeo
03.08.2021 16:37+1Нет никакой чуши. Просто вместо ссылки на документ надо приводить из него выдержки, а не безапелляционно утверждать, что cmov — говно:
The advantage of a conditional move is that it avoids branch mispredictions. But it has the disadvantage that it increases the length of a dependency chain, while a predicted branch breaks the dependency chain. If the code in example 9.9c is part of a dependency chain then the cmov instruction adds to the length of the chain. If the same code is implemented with a conditional jump as in example 9.9b and if the branch is predicted correctly, then the result does not have to wait for b and c to be ready. It only has to wait for either d or e, whichever is chosen. This means that the dependency chain is broken by the predicted branch, while the implementation with a conditional move has to wait for both b, c, d and e to be available. If d and e are complicated expressions, then both have to be calculated when the conditional move is used, while only one of them has to be calculated if a conditional jump is used.
As a rule of thumb, we can say that a conditional jump is faster than a conditional move if the code is part of a dependency chain and the prediction rate is better than 75%. A conditional jump is also preferred if we can avoid a lengthy calculation of d or e when the other operand is chosen.
DistortNeo
03.08.2021 17:48Я предложил — многоуровневую память. Практически так с кешами и работают, если мы говорим о какой-то производительности. Зачем за давать вопросы на которые я уже давал ответ?
Нет, вы не давали ответов. Пока что ваши комментарии выглядят как лозунг: давайте не будем делать плохо, а сделаем хорошо. Где детали реализации?
Как я понимаю, вы хотите память вместо кэша. Фактически, это явная адресация быстрой кэш-памяти. Вместо того, чтобы просто решать какую-то задачу, программисту придётся тратить адовое количество ресурсов на реализацию механизмов памяти из медленной памяти в быструю и обратно. Значит, будет больше говнокода, и работать он будет медленнее, чем на неэффективных (по вашему мнению) архитектурах.
Далее, вы писали про однородный доступ к памяти. Что вы имеете в виду?
Допустим, один из трейдофов — это всякие спайки операций. Нам нужно как-то согласовывать одно с другим и не перегружать те части которые работают с тяжелыми уопами.
А почему вы считаете, что это проблема? Вот у вас тяжёлый вычислительный код, что предлагаете с ним делать?
byman
02.08.2021 10:50+2"Даже в популярной архитектуре RISC-V нашлось место стандартному VLIW-расширению. "
не могли бы Вы дать ссылку на содержание этого расширения?
true-grue
02.08.2021 11:36+1С удовольствием! Информация есть в документе The RISC-V Instruction Set Manual (https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf). См. раздел Supporting VLIW encodings. Он начинается со следующего абзаца:
"Although RISC-V was not designed as a base for a pure VLIW machine, VLIW encodings can be added as extensions using several alternative approaches. In all cases, the base 32-bit encoding has to be supported to allow use of any standard software tools".Мне известно о существовании нескольких академических RISC-V VLIW-процессоров, но, в целом, разумеется, типичный современный VLIW-ускоритель удобнее добавлять к RISC-V-ядру отдельно.
byman
02.08.2021 12:20Как Вы и сами видите , в архитектуре RISC-V нет ничего про VLIW кроме пары общих фраз. Так можно добавить какие угодно расширения.
true-grue
02.08.2021 12:40+2Жаль разочаровывать, если Вы ожидали увидеть там скрытый намек на "Эльбрус" или Itanium.
Авторы RISC-V не верят в перспективы VLIW в области GPP, об этом они неоднократно заявляли. Как и большинство специалистов сегодня, Хеннесси с Паттерсоном разделяют мнение, что VLIW-архитектуры замечательно себя показывают в области предметно-ориентированных ускорителей и в этом отношении RISC/CISC им, в целом, не конкуренты.
Перед авторами RISC-V стояла непростая задача обеспечения точек роста новой архитектуры. Поэтому в RISC-V стандартизированы возможности расширения команд, добавления специализированных ускорителей. Естественно, речь не идет о "каких угодно расширениях" (это самое "что угодно" добавляется в отдельные ускорители) и, в частности, вы не найдете в документе ничего о TTA, Dataflow или каких-нибудь CGRA.
По какой причине возник небольшой, укладывающийся в одну страницу, раздел VLIW-расширения? Думаю, авторы предполагали возможность реализации простых компактных вариантов в духе 2-issue in-order.
byman
03.08.2021 13:00+2Вы меня не разочаровали. Я просто хотел чтобы Вы сами уточнили , что у RISC-V ничего про VLIW нет :) Просто из вашего прежнего комментария можно было сделать вывод, что у RISC-V есть какое-то VLIW расширение подобно V,P,B и т.д.
creker
03.08.2021 12:26+3Не простаивают. Для этого суперскаляры делают OoO и SMT. Как раз VLIW будет простаивать. Либо он будет стоять ждать результата условия, либо тупо тратить ресурсы на бесполезные вычисления. И то и другое плохо. По этой причине всегда и везде код с условиями на VLIW всеми силами выпиливается какими угодно костылями. Хороший пример GPU, где условия смерти подобны были. Не знаю как сейчас с тех пор, как от VLIW даже они отказались.
Помочь может нормальная isa и нормальный код. В нормальном коде при наличии нормальной isa 95% ветвлений выпиливаются.
Ну в теории много чего возможно, а практика показывает, что ни кода такого, ни ISA такой нет. Вам выше уже все объяснили. Суперскалярные процессоры придумали для выполнения реального кода, а не теоретизирования как все было бы хорошо будь у нас идеально оптимизированный под архитектуру код.
Даже на х86 один cmov позволяет выпилить чуть ли не половину ветвлений.
И ухудшить этим производительность. На практике cmov имеет неочевидные последствия. Вот вам авторитетный источник с описанием проблемы https://www.agner.org/optimize/optimizing_assembly.pdf и почему на деле предсказание и спекулятивное выполнение скорее всего будет быстрее.
DistortNeo
03.08.2021 16:45+1Есть золотое правило: критикуете — предлагайте альтернативу. Что предлагаете вместо кэшей? Чем так плох x86, если под капотом все равно работает микрокод? Ну кроме убогого кодирования системы команд.
user_man
01.08.2021 16:10-6Автор смешал тёплое с мягким. Он объявил бесперспективной конкретную разработку, а в реальности оспаривает лишь технологию, задействованную в данной разработке.
Эльбрус, как конкретная разработка, бесперспективен в рамках системы, в котрой ему приходится существовать. А технология, объявленная автором плохой, вполне может выиграть конкурентную борьбу даже в рамках существующей системы.
Далее рассмотрим конкретнее некорректность претензий автора именно к технологии VLIW.
Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям
Разумеется, это не так. Портированию подлежит лишь то, что скомпилировано под конкретную архитектуру. Но мир развивается, и равитие несёт нам свободу от монополий. Есть всем известные примеры языков, компилируемых в байт-код или же в оптимальный машинный код, но на этапе исполнения. Если автор обратит внимание на эти всем известные подходы, то "проблема" с портированием моментально испарится. Останется только осилить базовые библиотеки на компилируеммом в байт-код языке, что бы не плакать о "невозможности портировать" что-то чужое.
Да, к сожалению мы не можем делать аналог x86.
Не "мы не можем", а система, которая ограничивает нас всех, не способна ни на что большее, нежели набор завиральных обещаний о великих победах в будущем.
VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам
Абсолютно необоснованное заявление. Сравнение может проводиться (если сторона обвинения VLIW вообще этим озадачивалась, в чём я сомневаюсь) только с одной известной приличной попыткой - Itanium. Всё остальное - либо теоретизирование без денег, либо вот Эльбрус, который рождён в условиях всем известных ужасных ограничений. И вот на основании стравнения с явно ограниченными вариантами, делается далеко идущий вывод.
Пришедший указатель или сложная работа с памятью - и вы не можете спланировать Load выше операции Store (и наоборот)
Здесь всё зависит от объёма памяти и количества вычислений на этапе компиляции. У процессора, который в железе реализует то же самое, и памяти и вычислений на порядки меньше. Но автор настаивает на своём, забывая об очевидных возражениях.
Но при компиляции без профиля установить какие циклы горячие невозможно.
Опять же здесь стоит напомнить о технологиии, которая существует уже лет 25. Называется она "just in time" компиляция. И профиль там, безусловно, есть. А вот значимость, придаваемая автором данной проблеме, явно завышена. В целом статья демонстрирует именно произвольно надёрганный набор из ряда типичных возражений сторонников традиционного подхода, но ни в коем случае не демонстрирует системность подхода и уж тем более, какие-то расчётные или статистические выкладки.
В то же время классические RISC/CISC архитектуры с OoO автоматически оптимизируют и конвейеризируют любой исполняемый код.
А здесь вообще декларируется наличие магии внутри традиционных решений. То есть всю логику, которая зашита в железе, противники VLIW считают в принципе недоступной для реализации в альтернативных решениях. Как может быть недоступно то, что доступно процессору с его крошечными мозгами, полноценному компилятору с его доступом к гигабайтам памяти и десятку ядер при компиляции? Только за счёт магии. Но здесь главное - верить, ну и излагать мксимально безапелляционно.
Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал.
Если что-то не заинлайнено компилятором, то это что-то, по мнению автора, автоматически заинлайнится процессором. А теперь вспомним про различие в количестве доступной памяти и вычислительных циклов между полноценным компилятороми и ограниченным в этом всём процессором. Вопрос - кто сможет оптимизировать лучше?
В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.
Ну это же классическая манипуляция с указанием на худший вариант против лучшего. Автор берёт VLIW и предполагает, что он совсем тупой и ничего не умеет. Потом он берёт обычный процессор и предполагает, что он умеет абсолютно всё. А затем автор сравнивает два таких варианта. И, о чудо, внезапно побеждает именно идея автора о превосходсьтве "белой расы".
В целом статья пустая. Нет ни статистики, ни расчётов, хотя есть много необоснованных зявлений и натянутых предположений.
creker
01.08.2021 16:27+12Как может быть недоступно то, что доступно процессору с его крошечными мозгами, полноценному компилятору с его доступом к гигабайтам памяти и десятку ядер при компиляции?
Ему доступно еще одно измерение — время. Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление, куда пойдет джамп, где будет зависимость между инструкциями, а где не будет. Это динамические характеристики, которые проявляются только в процессе выполнения кода. Поэтому мы видим, что все процы общего назначения имеют предсказатели, OoO, кучу другой «магии» и эти блоки постоянно оптимизируются и улучшаются, давая серьезный прирост в IPC, а VLIW может справляться только с примитивным векторным кодом. Итаниум был просто самый громкий пример, но тупиковость этого подхода всем давно известна и понятна, поэтому никто больше не пытается ткать VLIW куда попало. Всему свое место и для VLIW это место совсем не центральный процессор ПК.
Ирония в том, что именно ваш пост набит необоснованными заявлениями. Статья автора это просто ликбез на тему архитектур с перечислением общеизвестных фактов. Какие еще расчеты и статистика? Можете конечно не верить, но сами тогда и ищите расчеты, раз вам очевидные вещи кажутся неправдой.Armmaster Автор
01.08.2021 16:45+2Спасибо за ответ. Я просто даже не знал, как прокомментировать такой поток мыслей. Это надо брать человека, сажать рядом за стол с ручкой и листочком и начинать с объяснения азов.
Sabubu
01.08.2021 17:07-2Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление,
Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.
где будет зависимость между инструкциями
Это как раз известно еще на этапе компиляции.
creker
01.08.2021 17:19+5Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.
Т.е. может все таки. В этом и смысл. А компилятор не может вообще и никак. Он может только PGO прогнать или подсказки от программера использовать, но это даст код, который не умеет адаптироваться к изменяющимся данным. А процессор умеет. Вон выше пример со сравнением строк как раз в тему.Это как раз известно еще на этапе компиляции.
А если адрес динамически вычисляется? Компилятор в любом случае должен быть более консервативен в своих оптимизациях и догадках о коде. Даже на уровень языка (C/C++ и их тонна UB) приходится вон костыли выносить, чтобы развязать ему руки хоть немного.
DistortNeo
01.08.2021 17:23+3Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.
Разница в том, что процессор может менять свои предположения о ветвлении на лету, подстраиваясь под данные.
user_man
02.08.2021 16:49+1>> Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление
Это ваш единственный аргумент? Пробегитесь по комментариям, там уже дали на него ответ. Хотя ответ любому разбирающемуся в матчасти и так понятен.
Что такое предсказание ветвлений? Направления два - исполнение сразу по двум ветвям и сбор статистики. Эти функции в обычных процесорах реализованы в железе. Для VLIW ровно эти же функции ничто не мешает реализовать в виде наполнения пустующих слотов в потоке инструкций. То есть в обоих случаях предсказание будет. А если оба случая эквивалентны по имеющейся информации, но один из случаев всё же более качественно оптимизирован за счёт привлечения полноценного компилятора, то кто же выиграет? И вот таких элементарных вещей вы не понимаете?
creker
02.08.2021 17:16+2Что такое предсказание ветвлений? Направления два - исполнение сразу по двум ветвям и сбор статистики.
Предсказатель делает именно предсказание и процессор идет по одному предсказанному пути, не тратя попусту ресурсы на другую ветку. Исполнение двух веток сводит на нет всякий смысл идеи. Ваш VLIW будет тратить впустую ресурсы, исполняя обе ветки, а потом еще выкидывать результат одной из них. Да, я не понимаю, каким образом компилятор в этом может чему-то помочь, хоть терабайт оперативы ему отсыпь. Если в ваших упомянутых комментариях таким же образом опровергается тезис, то я их даже искать не буду.
edo1h
03.08.2021 08:22Для начала — неявная неоднородная память это рак
ну… может быть. но мы уже привыкли к гигабайтам (десяткам, сотням) ram. и многоуровневые кэши.
предлагаете руками управлять загрузкой данных в кэш?
и да, память — это половина проблемы. вторая половина — когерентность кэшей между ядрами, атомарные операции с мьютексами. тут куда бежать?
Подобные же паттерны не являются большой проблемой для vliw. Эти пару инструкций записываются просто до того, что может заблокировать исполнение.
насколько я представляю, являются. и код «рыхлый» получается, и предсказание ветвлений пока только в планах…
Но у суперскаляра есть smt и решает эту проблему. smt это источник полностью независимых друг от друга цепочек
и это да, кто же спорит.
Оно есть даже на мусорном суперскаляре типа х86.
ну я бы не стал называть x86 мусорным. у кого-то производительность на такт заметно лучше?
anonymous
00.00.0000 00:00edo1h
01.08.2021 16:33+5Здесь всё зависит от объёма памяти и количества вычислений на этапе компиляции. У процессора, который в железе реализует то же самое, и памяти и вычислений на порядки меньше
у компилятора нет информации попал ли этот байт в кэш или нет, например. в то время, как типичный суперскалярный процессор заблокирует только зависимые от текущей команды, vliw застопорит всё ядро.
и да, я знаю, о том, что можно явно загружать в кэш нужные адреса, но это не панацея.
а ещё есть всякие LOCK, время исполнения которых, насколько я понимаю, тоже недерменировано.
anonymous
00.00.0000 00:00qw1
01.08.2021 23:38+2
Как вы себе это представляете? В каждую ф-цию (а вдруг она станет «горячей» в будущем), вокруг каждого ветвления, добавить немного диагностического кода, который будет жрать такты, регистры и memory traffic? (куда-то все эти логи писать надо)Но при компиляции без профиля установить какие циклы горячие невозможно.
Опять же здесь стоит напомнить о технологиии, которая существует уже лет 25. Называется она «just in time» компиляция. И профиль там, безусловно, есть
А потом, когда приложение поработало (сколько? 2 секунды или 2 минуты?), перекомпилируем часть функций, удаляя из них тормозную диагностику? А вдруг ситуация изменится, диагностику надо всегда оставлять, и она будет хорошо так тормозить.BugM
01.08.2021 23:47Да, примерно так это и работает. Оверхед на профайлинг порядка единиц процентов, если я ничего не путаю.
Профилирование не удаляется никогда. Пошел другой паттерн данных и код оптимизировался под него.
creker
01.08.2021 23:49+1tiered compilation и деоптимизация это все умеет. JVM и вроде .net core их поддерживают.
qw1
01.08.2021 23:56Ну то есть ф-ция типа
int next(int a) { return a+1; }
у такого JIT не 2 инструции, а сколько?BugM
01.08.2021 23:58Она просто заинланится.
JIT компиляторы сложные и навороченные. Такими простыми штуками вы их не обманете.
qw1
01.08.2021 23:59А если ф-ция виртуальная?
BugM
02.08.2021 00:05В Джаве все функции виртуальные. И ничего, отлично инлайнятся. Не вижу проблем.
qw1
02.08.2021 00:12+2Так они инлайнятся в большинстве случаев из-за того, что они все виртуальные. jit знает, какие не перегружены в наследниках, т.е. виртуальность избыточна. А если ф-ция сделана виртуальной, чтобы вызываться по разным адресам в одном и том же цикле, например
foreach (shape in shapes) n += shape->getVerticesCount();
тут никакой компилятор ничего сделать не сможет.BugM
02.08.2021 00:20Если у вас на самом деле разные типы с разными реализациями
getVerticesCountвнутриshapes, то компилятор ничего не сможет сделать и будет все честно вызывать. Увы, вам не повезло.В любом другом случае смело инлайним. Если внезапно прилетели разные типы с разными реализациями, а до этого тысячи раз были одинаковые кидаем исключение и откатываемся на неоптимизированный вариант. В итоге выигрыш будет больше чем такая неоптимальная обработка изредка.
qw1
02.08.2021 00:25Если внезапно прилетели разные типы с разными реализациями, а до этого тысячи раз были одинаковые кидаем исключение и откатываемся на неоптимизированный вариант
Мне просто интересно, реально ли jit на такое способен. Внутри одной ф-ции могут быть десятки виртуальных вызовов, если пример реальный, а не модельный.BugM
02.08.2021 00:32Да. Определять конкретные реализации и убирать виртуализацию он умеет.
Там ограничения на размер блока кода который можно инлайнить. Со всем замудреным не сработает. А вот в простых случаях работает неплохо.
Писать горячий код в рассчете на инлайн надо небольшими функциями. Коллекции с разными типами и разными реализациями функций в горячем коде могут сильно навредить производительности. И так по всему стеку вызовов горячего кода.
А еще неплохо бы посмотреть нет ли подходящей функции в jdk с аннотацией IntrinsicCandidate. Вероятно она будет быстрее чем любые твои старания. Там люди постарались и заранее все сильно оптимизировали уровнем ниже.
creker
02.08.2021 00:37Если внезапно прилетели разные типы с разными реализациями
Вот подтверждения этого я не смог найти. В моем понимании, она опирается на иерархию классов, и если есть несколько реализаций, то оптимизация не применяется никогда. Действительно ли JVM может спекулятивно делать оптимизации и если вдруг что-то некорректное, то откатываться назад? Это ж получается нужно в оптимизированный вариант проверки вставлять, что мы вызвали заинлайненный метод не того класса.BugM
02.08.2021 00:47В оптимизированном коде совершенно точно есть проверки и сбор статистики. JIT же работает на статистике. Ее в любом случае надо собирать постоянно и обновлять код если все пошло не так.
Проверки с медленной веткой срабатывающей раз на миллион вызовов это нормально. Пресказатель ветвлений cpu делает такую проверку почти бесплатной. Или вообще бесплатной.
Лично копаться в оптимизациях для меня перебор. Оно того стоит если ты разработчик JIT, Спринга и подобного, или от большой любви к ассемблеру. Я статьями ограничиваюсь. Или видео каким интересным по теме.
0xd34df00d
08.08.2021 04:51+1Пресказатель ветвлений cpu делает такую проверку почти бесплатной.
Так мы от него уйти хотели, не?
BugM
08.08.2021 14:36Вот как напишут хороший jit для Эльбруса без рассчета на предсказатель ветвлений тогда и приходите со статьей с описанием. С удовольствием почитаю и даже попробую, если не очень дорого будет.
Я немного знаю только про то как он работает на процессорах с предсказанием.
OpenA
08.08.2021 23:00-2Предсказатель ветвлений это костыль предугадывающий инструкции из какого бранча готовить прежде чем вообще дойдет до инструкции вызова или перехода. Программисту на него нельзя никак вообще опираться, так как это чисто аппаратная хреновина, программисты наоборот чаще его пытаются обойти всякими уродливыми ухищрениями, если в коде поджидают явные или частые ошибки предсказания.
У эльбруса проблемы с джитом из за своей процедурной безопасности и стековости. Джит подразумевает что безопасность обеспечивается его рантаймом, а машине безопасной быть не нужно, так как это тоже забирает эффективность/скорость. В принципе у них же есть небезопасный режим для совместимости с интелом, не знаю почему они его не хотят использовать для рантайм языков а заставляют портировать в обычный режим с его защищенными стеками, либо может там дофига делов с тем что бы увязать все это в ядре ОС.
Ну и еще проблема с байткодами виртуальной машины, там посути поток команд для виртуального процессора, а эльбрусу надо чтоб ему код раздербанили на задачи.
BugM
08.08.2021 23:24Программисту на него нельзя никак вообще опираться, так как это чисто аппаратная хреновина, программисты наоборот чаще его пытаются обойти всякими уродливыми ухищрениями, если в коде поджидают явные или частые ошибки предсказания.
Мы тут про jit говорим. Ему ориентироваться на предсказатель ветвлений и генерировать код где этот предсказатель покажет всю свою силу милое дело.
Ну и еще проблема с байткодами виртуальной машины, там посути поток команд для виртуального процессора, а эльбрусу надо чтоб ему код раздербанили на задачи.
И опять jit же. Процессору поступает самый обычный нативный код. Байткод обрабатывается компилятором. При чем тут процессор непонятно. Нужно "всего лишь" написать оптимальный jit комплятор под Эльбрус.
OpenA
09.08.2021 08:02Ему ориентироваться на предсказатель ветвлений и генерировать код где этот предсказатель покажет всю свою силу милое дело.
jit компилятор не пишет код он его компилирует, вся разница в том что у него на руках есть статистика исполнения, он видит сколько у циклов итераций, в какой бранчь вообще никогда не переходят итп и может применять очень агрессивные оптимизации, разворачивать, выкидывать, заменять. Бранчпредиктор как раз при прыжках из неоптимизованного кода в отимизованный и обратно только мешается.
Процессору поступает самый обычный нативный код. Байткод обрабатывается компилятором. При чем тут процессор непонятно.
Байткод исполняется в виртуальной машине (виртуальном процессоре) который рабортает поверх настоящего, это такая схема работы. А эльбрусу надо полностью всю программу снизу доверху, а то еще и из дополнительных файлов, и строить оптимальное исполнение
Нужно "всего лишь" написать оптимальный jit комплятор под Эльбрус.
Проблема в том джиты для языков уже написаны, ты можешь только в них добавить поддержку своей архитектуры, но качественно поддержать все возможности эльбруса в них не получится так как изменения сумарно потянут на отдельный джит. Представляешь себе V8 в котором 100мб исходников для всех архитектур и 100мб персоонально для эльбруса. Врядли такое произойдет, надо либо держать форк согласованый с основной веткой либо написать свой отдельный vm/jit не связанный с конкретным языком а во все проекты протолкнуть поддержку его представления.
creker
02.08.2021 00:07Джава и другие умеют девиртуализацию.
qw1
02.08.2021 00:15Это и c++ умеет, для этого jit не обязателен.
creker
02.08.2021 00:32С той разницей, что JVM сможет девиртуализацию выкинуть, если условия изменятся. Например будет загружена новая сборка, которая поменяет иерархию классов и оптимизация станет не валидной.
qw1
02.08.2021 09:37Для C++ это эквивалентно пересборке бинарника с влюченной link-time optimization.
creker
02.08.2021 12:09Не эквивалентно. Пересборка вообще за рамками этого обсуждения находится. JVM все делает в рантайме.
PsyHaSTe
05.08.2021 14:41+2При чем тут пересборка? При первой компиляции джит генерирует что-то типа
void Foo(object bar) { if (bar is ConcreteBar) { goto BarFooImpl } goto RecompileFooForDynamicObject }
при первом вызове виртуальной функции он генерирут только код для единственного реального типа который туда попал. Дальше пока туда попадает объект этого же типа все идёт по шорткат пути на конкретный невиртуальный импл. Как только нам в функцию передали какую-то другую реализацию то все это добро перекомпилируется в честный вызов виртуальной функции.
Можно почитать интереснее, как устроено и какие бенефиты дает. https://shipilev.net/jvm/anatomy-quarks/16-megamorphic-virtual-calls/
creker
02.08.2021 00:06Подробностей реализации я не знаю. Думаю найти будет несложно. Сам факт, что такое есть и вовсю используется уже очень давно. Вот например фейсбук про свой кастомный PHP рантайм пишут research.fb.com/wp-content/uploads/2018/04/hhvm-jit-a-profile-guided-region-based-compiler-for-php-and-hack.pdf Тоже PGO в рантайме делается.
qw1
02.08.2021 00:13Мне интересно, какой конкретно код будет добавлен профайлером.
Чтобы оценить, сколько информации можно так собрать и какой оверхед.
qw1
01.08.2021 23:59А если код типа
for (int i = 0; i < 256; i++) { if (i%4 == 1) printf("%d", i); }
Процессор поймёт, какой паттерн срабатывания IF и сделает предсказание только на каждую 4-ю итерацию.
А jit-компилятор как будет этот паттерн определять? Писать лог за каждый IF, а другой поток это всё параллельно анализирует?OpenA
04.08.2021 20:14Это статический компилятор сделает в компаил тайме, тупо тебе принты с нужными патернами в стопочку напишет и все.
В динамических языках как правило работа с массивом переменной длинны и вызовом юзерской функции переданной аргументом и все это jit в рантайме ловит и оптимизирует в том числе используя инлайн.
PsyHaSTe
05.08.2021 14:44Так же как статический, но у джита обычно ограниченный набор времени и ресурсов (в отличие от аот который может хоть год компилировать если ему нужные флаги подсунуть).
qw1
05.08.2021 17:35Я пытаюсь сконструировать случай, когда статическое планирование не работает.
Вот, например
при входном массиве a (полученным из места, к которому компилятор не имеет доступа):for (int i = 0; i < 256; i++) { if (a[i] > 0) printf("%d", i); }int a[256]; for (int i = 0; i < 256; i++) a[i] = i % 4;
Процессор с динамическим планированием может понять, что каждый 4-й переход срабатывает.PsyHaSTe
05.08.2021 19:38Если мы как люди можем это заметить, значит мы можем заставить машину сделать так же. Весь вопрос в том, какой бюджет транзисторов (в случае ЦПУ) или времени (в случае джита) у нас есть и влезаем вы в него или нет.
В современных жвмах (и вроде clr) бюджет такой, что мы можем в фоне собирать статистику и оптимизировать "достойные" методы подобным образом.
Ну а бюджет ЦПУ на это дело тоже известен и судя по тому что я слышал про интеловские процы последних поколений там просто чудо какие паттерны он умеет замечать. Каким образом, правда, мне не очень понятно. Но, достаточно утонченная технология неотличима от магии, так что приму как данность нашего мира, что это есть.qw1
05.08.2021 21:05Каким образом, правда, мне не очень понятно
Нейросети и машинное обучение. Видел публикации, что AMD и Qualcomm это используют.
qw1
05.08.2021 21:09Весь вопрос в том, какой бюджет транзисторов (в случае ЦПУ) или времени (в случае джита)
С транзисторами понятно. А вот jit как работает… Сбор статистики не бесплатен. И чем больше собираем, тем сильнее тормозит код, который больше всего выполняется. Особенно статистика переходов. Это каждый branch надо обвешивать логированием?BugM
06.08.2021 00:42Семплирующий профайлер не очень дорог. На горячем и уже оптимизированном коде можно спокойно собирать статистику раз в тысячи, а то и миллионы, вызовов. И что-то делать только если оно изменилось.
Время реакции на измерение паттерна данных у Джавы не очень быстрое. (Субъективное наблюдение. По хорошему тут мерять надо, но это статья по объему)
OpenA
06.08.2021 09:25+1явное количество итераций цикла, это само по себе большой простор для оптимизаций вплоть до инлайн подстановки заранее посчитанного результата, во вторых твой код как раз заставляет дристать под себя предсказатель переходов и рекламирует условное исполнение через флаги или через предикаты (без разницы) которые целиком ориентированы на подстановку компилятором.
void ex(int arr[], const int idx[], const int isz) { for (int n = 0; n < isz; n++) arr[idx[n]] += n; }Поздравляю, мы не можем статически предсказать куда проходит запись может быть все пишут в один элемент массива а может быть в один элемент тут несколько раз запись проходит, и поэтому мы не можем спекулятивно (заранее) загружать значения из arr, а это значит что надо ждать пока загрузится idx[n] и потом только arr[ idx] и причем мы не можем параллельно итерации обрабатывать, так как вдруг следующая пишет туда же.
логически мы можем обрабатывать этот алгоритм только последовательно, тогда как в рантайме у нас на руках есть реальные данные и внеочередное исполнение может видеть что зависит а что нет, что можно обработать параллельно, а что нет.
Но даже в этом случае умный компилятор+адекватный программист эффективнее внеочередных костылей. Компилятор видит что ничего не мешает пихнуть указатели на один и тот же массив и картина обработки массива резко меняется, и можно подготовить код на оба случая если программист не запретил рассматривать такие случаи всякими там рестриктами и ассертами. Можно ловить пересечения сравнивая адреса и сопоставляя предикаты, в конце концов программист видя что компилятор слишком замороченый код генерит, разделит циклы, отсортирует сгруппирует а компилятору останется только развернуть итерации.
qw1
06.08.2021 10:07+1во вторых твой код как раз заставляет дристать под себя предсказатель переходов
Это почему? Предиктор Intel в моём примере понимает, что выполняется только каждый 4-й переход и перестаёт делать ошибки через некоторое время обучения.и рекламирует условное исполнение через флаги или через предикаты (без разницы) которые целиком ориентированы на подстановку компилятором
Не понимаю, откуда компилятор узнает содержимое массива a (допустим, оно генерируется внешней программой). И как тут помогут предикаты, предикаты могут выполнить printf по условию?OpenA
06.08.2021 12:49+1Даже если в твоем интеле супернавороченный предиктор, который запоминает интервалы между входом в бранчь, пароли от банковских карт и в какой папке хранится цп, то все равно он это выучит не сразу, а у твоих пользователей интел может быть не такой крутой и новый, или вовсе неинтел. Так то надо это тоже учитывать.
Компилятор в случае с амд атлоном с дедовским предсказателем, может развернуть цикл на несколько итераций вперед чтоб хотя бы помочь суперскаляру загрузки/сравнения запускать параллельно, так как он видит что они ни от чего не зависят. В случае с эльбрусом компилятор вовсе знает сколько длится подготовки переходов и загрузки, пока готовится конвеер с функцией принт, он может сравнить уже заранее подгруженный a[i] > 0, запустить загружаться a[i+1] условно выполнить подготовленный print ? p1 и перейти в следующую итерацию.
Бранчпредиктор - это умный лифт который пытается угадать на каком этаже ловить пассажира и подоспеть чтоб он как можно меньше ждал, подготовки - это два лифта с кнопками, один поедет за твоим другом наверх, второй поедет к тебе, и должно получится так что когда твой друг спустится приехал уже грузовой лифт куда вы вдвоем погрузите диван и поедете на первый этаж, чтоб никто никого не ждал.
Lazy_66
01.08.2021 18:09-6Собственный процессор - это прежде всего информационная безопасность. На этом фоне всё остальное уходит на второй план.
SerjV
01.08.2021 19:23+9Угу… Работающий на пиратском варианте линукса (хотя надо посмотреть видео, может они как-то наконец-то решили эту проблему?). Хотя да, если ради информационной безопасности еще и интеллектуальную собственность отменить — много народа скажет спасибо.
p.s. для «пиратскости» ключевой признак — не деньги (как следует из пропаганды копира… правообладателей), а (не)соблюдение лицензионных договоров (в т.ч. ими же самими).Lazy_66
01.08.2021 19:28-3Пиратский линукс? Вы сейчас серьёзно? :)
tbl
01.08.2021 19:47+9МЦСТ ловили на том, что они бинари распространяли без доступа к исходному коду (даже по запросу), что было нарушением GPLv2
Lazy_66
01.08.2021 19:54-4И? Какие последствия?
SerjV
01.08.2021 20:24Ну так в гражданско-правовой сфере кто-то должен озаботиться защитой своих прав для начала. Например, потребовать запрета распространения содержащей контрафакт продукции хотя бы.
А для привлечения МЦСТ и/или должностных лиц к административной ответственности скорее всего потребуются ОРМ, т.к. «в открытом доступе» достаточной информации о подробностях сделок, включавших поставку эльбрусОС, недостаточно для однозначного заключения, был там в каждом конкретном случае линукс контрафактным или нет.
Т.к. признаки осуществления приготовлений к нарушению прав есть, но этого достаточно лишь для гражданско-правового процесса, для административной ответственности нужно незаконное использование.
Armmaster Автор
01.08.2021 19:37+8Тогда уж надо все "информационно безопасные" чипы на производство на 90нм Микрона переводить. Но всё же печатается на Тайванях. И в проектировании отказаться от Синопсисов и Каденсов. И сторонние IP блоки не использовать (а МЦСТ их использует).
Я к тому, что "информационная безопасность" это такая бездонная и спекулятивная тема, в которую не хочется даже погружаться. Надо не "информационно безопасные" чипы делать, а конкурентноспособные, на мировом уровне а лучше даже выше. Тогда в России и индустрия появится. И тогда вопрос с "информационной безопаснотью" и "импортозамещением" решится сам собой.
edo1h
01.08.2021 19:58+3Тогда в России и индустрия появится. И тогда вопрос с "информационной безопаснотью" и "импортозамещением" решится сам собой.
Жаль только — жить в эту пору прекрасную
Уж не придется — ни мне, ни тебе
amartology
06.08.2021 09:30+1производство на 90нм Микрона переводить.
А оно заработало?Armmaster Автор
06.08.2021 12:25Честно говоря, не знаю актуальное состояние. Как минимум, что-то на 90нм делали. Ну вот будет повод довести до ума техпроцесс
vilgeforce
01.08.2021 20:22Если бы гораздо более очевидные и существенные проблемы с ИБ были бы решены - можно было бы заниматься и безопасностью процессоров, но...
victor_1212
01.08.2021 20:45+1>Микропроцессоры архитектуры Эльбрус (e2k) - это абсолютно аутентичная разработка компании МЦСТ, основанная на предыдущем опыте создания линейки Эльбрусов 1/2/3 ещё в СССР.
Именно, т.е. многопроцессорные симметричные системы высокой надежности с развитой операционной системой написанной на языке высокого уровня, повторная входимость кода и пр. Для поддержки языка высокого уровня (Эль78) на уровне машинных команд (безадресных, работающих со стеком) аритектура подходит, навеяна вероятно Burroughs D825.
Широкий формат команд вероятно получается при машинной интерпретации на уровне микрокода безадресных стековых команд cpu. Такое впечатление, что при микропроцессорной реализации этой архитектуры (несомненно интересной но слегка реликтовой) под управлением Linux, все это совершенно не оправдано, цель непонятна. Если бы к примеру ставилась цель совместимости, возрождения/развития уникального sw написанного для Эльбрусов 1/2/3, понять было бы можно конечно.
F376
01.08.2021 21:22+2Проблему VLIW архитектур можно обосновать просто, почти математически. VLIW имеет фиксированное окно, в которое должны уложиться элементарные шаги алгоритма по принципу максимального заполнения окна. Незаполнение окна вызывает потерю эффективности.
Но всегда найдутся такие алгоритмы, количество шагов которых будет либо короче, либо не кратно размеру фиксированного окна, а следовательно, алгоритмы будут выполняться неэффективно.
VLIW иходно предназначалась для узкой ниши - DSP, MATRIX, VECTOR, Image/Video Processing часто при hand-writen / hand-optimized коде "горячих" мест. Но в качестве General Purpose вычислителя (в особенности при компиляции) архитектура VLIW обречена проигрывать RISC.
AMD в Graphics Core Next с ее RISC SIMD (SIMT) ушли от VLIW SIMD (TeraScale) еще в 2010х. Этот уход вызван анализом результатов симуляции.
victor_1212
01.08.2021 21:50>VLIW иходно предназначалась для узкой ниши ...
именно, плюс большой опыт использования horizontal microcode в супер компьютерах, каковыми и должны были быть Эльбрус 1/2/3, если правильно помню, примерно так там и было сделано исполнение команд cpu
F376
02.08.2021 01:40+1"Эльбрус" исходно экономически был обоснован не как General Purpose процессор, всё это обросло вокруг проекта уже позже. Так что если такое утверждение положено в название статьи, то оно изначально с изъяном.
Эльбрус обосновывался как процессор для ВПК. Для работы в составе радаров. Радары это задачи DSP. Это определило выбор VLIW архитектуры.
Большинство компилируемых синтетических тестов из CISC/RISC мира не отражают реальную пиковую производительность VLIW архитектур.
F376
02.08.2021 01:59+1Реальность с Эльбрусом такова:
Исходно, приоритетной задачи создать general purpose процессор не стояло.
Было понимание, что создать General Purpose процессор превосходящий мировые многолетние разработки за адекватное время/деньги вряд ли возможно. Собирались создать именно специальный процессор, для специальных применений.
Процессор требовался на самом деле преимущественно для ВПК (DSP, обработка радарных сигналов в реальном времени), это налагало определенные требования.
Именно это (классически) определило выбор VLIW. Попутно, спроектировать производительный VLIW проще (а значит реально по деньгам и срокам). Но это налагает требования к написанию для него кода. Обычные general-purpose тесты реально достижимую производительность процессора не покажут.
По ходу проекта возникли как личные амбиции, так и определенные изменения в политике закрытости/открытости, отношения с общественностью, и даже политический псевдопатриотический пиар итд.
Именно это (п.5) определил широкое обсуждение "Эльбруса" общественностью (например эту статью). В противном случае это был бы просто очередной микропроцессорный комплект №XXXX о котором мало кто знает.
Armmaster Автор
02.08.2021 02:24+3Реальность такова, что в середине 90-х бытовало мнение, что VLIW как general purpose CPU крайне перспективен. Поэтому появились Итаниум, Трансмета, Эльбрус. Время показало, что мнение было ошибочным. Эльбрус изначально планировался именно как перспективный general purpose CPU.
victor_1212
02.08.2021 02:43и да, и нет, примерно как Burroughs, многоцелевой, в том числе для реального времени, но без жестких требований
victor_1212
02.08.2021 02:47ps
про VLIW в те благословенные времена никто не догадывался, думали скорее в терминах horizontal microcode, VLIW стали обсуждать в районе Эльбрус 3, если не позже, как обычно imho
Armmaster Автор
02.08.2021 03:08+1Эльбрус 3 это конец 80-х. И давайте наше обсуждение сведём всё же к VLIW. Иначе если мы тут начнём выяснять за EPIC, horizontal microcode и т.д., обсуждение укатится в сторону религиозных споров.
victor_1212
02.08.2021 03:44нет вопросов, только Эльбрус 3 в конце 80х в железе и близко не было (по памяти)
Armmaster Автор
02.08.2021 16:22Эльбрус 3 был сделан в районе ~90-го года что-то в порядке одного экземпляра и насколько он был работоспособен данные расходятся. Но вроде как идеи оттуда перекочевали в e2k. Я, ясное дело, свечку не держал, всё со слов старших товарищей.
victor_1212
02.08.2021 17:30+1примерно в это время часто бывал в институте, общался с основными действующими лицами на всех уровнях, и видел их машины, но конечно давно дело было поэтому по памяти, да и серьезно Эльбрус 3 мало интересовал тогда ввиду отдаленности перспективы, других забот хватало, жалко что такой интересный проект не довели до ума
victor_1212
02.08.2021 02:40+1>3. Процессор требовался на самом деле преимущественно для ВПК (DSP, обработка радарных сигналов в реальном времени), это налагало определенные требования.
сравнение с DSP и пр. для обработки сигнала не уместно, переключение контекста было слишком долгое, реальное время да, но не в том смысле как вы пишите, реальные времена тоже разные бывают, не знаю откуда у вас информация, но мне таки пришлось поработать, и не один день
victor_1212
02.08.2021 03:08+1>Радары это задачи DSP.
в те времена были специализированные процессоры, DSP это IC которых и близко не было с нужным быстродействием и уровнем интеграции
>Это определило выбор VLIW архитектуры.
интересные фантазии, про VLIW даже Joseph Fisher узнал слегка позже
VLev
01.08.2021 21:34+1Основной тезис статьи, а именно
процессорная платформа, которая претендует стать массовой и конкуретной на рынке десктопных и серверных процессоров, не может быть VLIW архитектурой
конечно правильная, но устаревшая лет на 20. Именно тогда и следовало бы выбирать "правильную" архитектуру на основе озвученных автором тезисов. Причём, как мы теперь знаем, названием этой "правильной" архитектуры -- это первые 3 буквы из имени автора. Но 20 лет назад OoO там не было. А когда появилась, то по этому пути пошёл Байкал, но тоже не особо преуспел, и это даже если не принимать во внимание судьбу Опанасенко.
В любом случае, обстоятельства сложились по-другому, и все последние четверть века МЦСТ "пилили" свою собственную e2k, прекрасно зная о её принципиальных недостатках (собственно, в статье так и написано). И по самым скромным оценкам на это уже потрачено несколько сотен миллионов долларов гос.финансирования. Кому именно автор теперь предлагает сказать сакраментальное: "Работа проделана большая, так дело не пойдёт" (с) ?
С другой стороны, вынесенный в название тезис "тупик для развития отечественной линейки general-purpose CPU" вообще с правильным тезисом мало связан, поскольку как минимум предполагает, что существует какой-то нетупиковый путь "развития отечественной линейки general-purpose CPU". Причём автор его знает. Очень интересно было бы чтобы он с нами поделился этим видением.
Иначе где вообще гарантия, что цели Yadro чем-то отличаются от целей МЦСТ, а возможности разработки (в том числе и квалификация разработчиков) успешно заменяется связями в правительстве.
Конечно можно рассмотреть и технические аспекты статьи. Например, автор конечно очень правильно разделил "архитектуру" и "микроархитектуру". И даже указал, что RISC/CISC победил благодаря развитию микроархитектуры. Но почему-то забыл даже упомянуть (а хотелост бы обсудить), что микроархитектура e2k со времён известной статьи в MPR претерпела лишь косметические изменения.
Короче, тут в комментариях мы вряд ли сумеем конструктивно продвинуться в данном вопросе "Тупик или не тупик?". Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?
Armmaster Автор
01.08.2021 21:46но устаревшая лет на 20
вполне современный тезис, в свете описанного в самом начале статьи
Причём, как мы теперь знаем, названием этой "правильной" архитектуры -- это первые 3 буквы из имени автора
Я намеренно обходил углы с вопросами о том, какая архитектура правильная. Но избежать обвинений в ангажированности не удалось. Нет, я не утверждаю, что ARM - это правильная архитектура. Какой тут правильный путь - вопрос сложный, и как минимум требует отдельной статьи. Но сразу скажу, если вы и в дальнейшем будете использовать такую же манеру общения, диалог не сложится.
Причём автор его знает. Очень интересно было бы чтобы он с нами поделился этим видением.
Если будет - отдельной статьёй.
Иначе где вообще гарантия, что цели Yadro чем-то отличаются от целей МЦСТ
Гарантий нет, но это не повод оставлять всё как есть
Но почему-то забыл даже упомянуть (а хотелост бы обсудить), что микроархитектура e2k со времён известной статьи в MPR претерпела лишь косметические изменения
Специально для этого упомянул вытекающие недостатки в конце статьи, где упомянуто, что одним из недостатоков является сложность развития микроахитектуры Эльбруса
Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?
Спасибо - не надо.
VLev
01.08.2021 23:55+1вполне современный тезис, в свете описанного в самом начале статьи
я как раз не собирался обвинять Вас в ангажированности, и потому наоборот, изначально хотел отделить "современность" дискуссии "VLIW vs [RC]ISC" от её "своевременности". Про второе, естественно, согласен. Ибо в концепции "сквозных проектов" надо найти потребителей, которые будут готовы через 3 года купить разработанное на эти самые "крупные инвестиции". А Эльбрусы покупать никто не готов (тут выше писали о каком-то "главном заранее удовлетворённом заказчике", но это всё из области тех мифов, отсутствие которых -- это главное, что проимпонировало мне в Вашей статье). А из тех причин, по которым потребители не готовы покупать Эльбрусы, "уникальность архитектуры" конечно самая простая, понятная, и никак не устранимая за предлагаемые сроки и деньги. Но я надеялся, что статья не только об этом.
Нет, я не утверждаю, что ARM - это правильная архитектура.
я наверное не очень внятно тут сформулировал: это я утверждал, что с технической точки зрения, ставка на ARM у Байкал Электроникс была правильной. Но, как бы то ни было, уверенно превзойти e2k по производительности Байкал-M удалось пока только в JS. Как это объяснить в рамках Вашего правильного тезиса? Вы же о производительности писали? Не о других свойствах Байкалов (в том числе и -T), которые позволяют легко обыгрывать Эльбрусы в тех немногочисленных тендерах, что удалось провести?
Но сразу скажу, если вы и в дальнейшем будете использовать такую же манеру общения, диалог не сложится.
Вероятно, это я буду виноват. Но, поскольку я очень редко пишу комментарии в статьи на habr-e, а с Вами вообще в первый раз общаюсь, то пока не очень понимаю как мне формулировать свои мысли, чтобы Вы не обиделись. Потому сразу и пригласил Вас в наш междусобойчик, где все друг друга за 20 лет хорошо узнали. Там я стараюсь не обижать даже упёртых эльбрусофилов...
Гарантий нет, но это не повод оставлять всё как есть
Вы считаете, что "сквозные проекты" имеют хоть один шанс не "просквозить как фанера над Парижем" в очередной раз? Ответьте пожалуйста, я перенесу Ваш ответ в нашу "вечную" ветку, и через 3-4 года мы узнаем были ли Вы правы или нет. Там за 20 лет уже много таких предсказаний накопилось...
Сложность развития микроархитектуры, т.к. в случае VLIW это почти всегда влечёт за собой изменение в архитектуре
да, это я пропустил --- упоминание действительно есть. Хотя с этим я бы как раз поспорил. Микроархитектура в том же Итаниум развивалась вполне себе в тренде, о чём Вам уже написали. Однако суть в том, что в e2k она не развивалась (даже не важно по каким именно причинам, например, там не только OoO нет, но даже аппаратного префетча), потому "Эльбрус это просто старые процессоры" --- это не совсем миф. IMHO конечно.
Armmaster Автор
02.08.2021 00:48+3Как это объяснить в рамках Вашего правильного тезиса?
Я не буду придираться, что Байкал-М обошёл Эльбрус не только в JS, т.к. вопрос по сути совершенно правильный. Ответ на него лежит на поверхности - Байкал-М это чип с энергопотреблением в 3 раза меньше, чем Эльбрус. Байкал-М это ванильная имплементация архитектуры Cortex-A57, вообще говоря ориентированной на сегмент носимых устройств. Проще говоря, микроархитектура там не особо оптимизирована и урезана для снижения энергопотребления. Если же ваша цель - максимальный перформанс, то можно разработать микроархитектуру, которая будет больше потреблять энергии, но цифры бенчмарков там будут существенно выше. Посмотрите, например, цифры того же Apple M1 для примера
с Вами вообще в первый раз общаюсь
вообще говоря, мы с Вами лично знакомы
Вы считаете, что "сквозные проекты" имеют хоть один шанс не "просквозить как фанера над Парижем" в очередной раз?
Это вопрос уже куда более сложный, чем сравнение архитектур. Но скажу так, что уж лучше вкладывать в "сквозные проекты" для разработки RISC процессоров, чем VLIW.
Однако суть в том, что в e2k она не развивалась
Опять-таки, строго говоря, она развивалась. Проблема в том, что любые серьёзные изменения в микроархитектуре сразу приводят к изменениям в архитектуре почти всегда - и далее как следствие переработка всего системного софта и перекомпиляция кода. Поэтому существенных изменений старались избегать, ибо такой цикл повторять никто в МЦСТ в здравом уме не захочет.
beeruser
02.08.2021 09:25+2существует какой-то нетупиковый путь «развития отечественной линейки general-purpose CPU»
В случае МЦСТ это был Sparc. Был.Микроархитектура в том же Итаниум развивалась вполне себе в тренде, о чём Вам уже написали.
Потому что Itanium это не ванильный VLIW, а EPIC, который проектировался с возможностью эффективно выполнять софт на новых процессорах.
Бандлы из трёх инструкций короткие, в отличии от VLIW, которые обычно делают подлиннее.
Poulson выполнял уже 4 бандла за такт, имел coarse-grained SMT и т.д.Короче, тут в комментариях мы вряд ли сумеем конструктивно продвинуться в данном вопросе «Тупик или не тупик?». Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?
VLev, вы прекрасно знаете что слово "конструктивно" в случае ixbt не может быть применено.
Пороховая бочка, доверха набитая хейтерьём, которое переклинивает от слова «отечественный». Особенно иммигрантов из Штатов и Израиля, c одной стороны и людей с синдромом ПГМ с другой :)пока не очень понимаю как мне формулировать свои мысли, чтобы Вы не обиделись
Там я стараюсь не обижать даже упёртых эльбрусофилов…
Человек с ixbt зашёлв барна хабр(с)VLev
02.08.2021 13:01+1В случае МЦСТ это был Sparc
нелюбимое дитя.
Потому что Itanium это не ванильный VLIW, а EPIC
на самом деле я был бы совсем не против развития микроархитектуры Эльбруса и по пути "ванильного VLIW". Собственно, даже у Бабаяна была большая программа развития микроархитектуры. То, что озвучивалось -- удвоение числа вычислительных кластеров.
Пороховая бочка, доверха набитая хейтерьём, которое переклинивает от слова «отечественный»
надеюсь, это Вы про "Политику" пишете, а не про тематические разделы. Наша ветка в "процессорах" находится, н никого там от её названия не клинит.
Единственное что: к нам регулярно приходят неофиты и, искренне считая, что своим приходом несут светоч истины, вываливают в ветку стандартный набор мифов об Эльбрусе. Им конечно тяжело вначале приходится, но потом как-то приобтираются, если конечно у них было что-то в мозгах кроме этих мифов.
Человек с ixbt зашёл в барна хабр(с)
я действительно давно в комменты не заходил, и потому удивился как изменилось за это время мнение посетителей хабра на предмет отечественных процессоров. В частности -- как тут минусят этих самых мифоносителей, сразу и без дискуссий. Не, на ixbt таких инструментов бана просто нет, есть только чёрный список, так что в нашей ветке вполе себе уживаются все "сто цветов" мнений относительно Эльбруса.
beeruser
02.08.2021 19:26+1надеюсь, это Вы про «Политику» пишете, а не про тематические разделы.
Нет, я пишу про «Отечественные микропроцессоры. Состояние и перспективы».
Правда я уже давно туда не заходил, но не думаю что что-то изменилось.
Неужели вы даже но названию стран не опознали «пациентов»? :)VLev
02.08.2021 20:14+1ну Ok. Констатирую, что моя жалкая попытка заманить автора в нашу ветку провалилась :(
yleo
01.08.2021 22:55-16Каждый волен заблуждаться, в том числе и автор. Тем не менее, автору хотелось-бы посоветовать:
1. Как можно меньше уподобляться эмигрантам/ренегатам ругая "Alma Mater".
2. Тщательнее и глубже изучить состояние дел (в том числе проблемы и недостатки) других "правильных" (микро)архитектур, чтобы избежать использования ошибочных доводов.Armmaster Автор
01.08.2021 23:25+3Хочется посоветовать давать поменьше пустых советов, особенно когда их у вас не справшивают
amartology
02.08.2021 03:44+5Как можно меньше уподобляться эмигрантам/ренегатам ругая «Alma Mater».
Это что-то из серии «о мертвых или хорошо, или никак»? Кто же ещё сможет качественно и конструктивно разобрать недостатки, как не люди, хорошо и глубоко знакомые с предметом обсуждения?yleo
02.08.2021 07:54-6качественно и конструктивно разобрать недостатки, как не люди, хорошо и глубоко знакомые с предметом обсуждения
Это сарказм такой про автора статьи?
Ходить на работу 10 в организацию, заниматься бинарной трансляцией, не хватать звезд с неба, выгореть и разочароваться - это примерно совсем не то, что вы подразумеваете.
amartology
02.08.2021 09:14+2Я ничего не подразумеваю. Мой пост был ровно о том, что пытаться запрещать кому-то что-то говорить — это цензура, а цензура — недопустима.
Armmaster Автор
02.08.2021 15:56Достаточно показательно, что вы сразу пропустили этап хоть какой-то технической дискуссии и сразу перешли на личности, приводя аргументы в стиле "автор дурак! не верьте ему!".
Что касается ваших пространных рассуждений о звёздах, выгорании и разочаровании (про выгорание особенно смешно в контексте стиля работы в МЦСТ ). Вы вряд ли в теме вопроса, т.к. мы лично не знакомы, а пересказ чьих-то мнений из третьих рук дело достаточно скользкое и необъективное априори. Но могу сказать, что если мы сейчас углубимся в данную тему, то там у меня есть запас "окуительных" историй, которые смоют в трубу последние остатки мифа о великих МЦСТ. Мне кажется, это заведомо не в ваших интересах.
Поэтому, я могу вам предложить ограничиться чисто технической дискуссией. И в данном плане я предлагаю пригласить звёзд МЦСТ (хоть всех сразу) и устроить публичную дискуссию по данному топику (RISC/CISC vs VLIW). А там и посмотрим, кто чего стоит на самом деле.
yleo
02.08.2021 17:09-3Рекомендую не-предвзято перечитать мой первый комментарий.
Armmaster Автор
02.08.2021 17:22+2Ваш первый комментарий - это пустое надувание щёк. Вам нечего сказать по существу, но пытаетесь что-то из себя изобразить.
yleo
02.08.2021 17:45-3"Уважаемый", с такими "позывами к дискуссии" вам - к малахову.
Но таки в чем-то соглашусь - и первого (моего) комментария было слишком много как для самой статьи, так и для комментариев/ответов.
yleo
06.08.2021 02:56-3Хомячки опять негодуют в карму!
Ножкой топ - не пущать, такскаать, нельзя такие комбинации букв слагать, наверное.
А как там было?... саморегуляция, но от хомячков ничего не устоит!
Короче, спать не могу ;)Тем не менее, занимательно что аффтар сумел убедить аудиторию что он (внезапно) прям-таки в теме проблематики, светоч в перспективах развития "микроархитектур", а его мнение авторитетно и достойно внимания ;)
Не доронин, но явно с задатками для "хабра-пипл хавает".
Хорошо что ничего, по большому счету, от этого НЕ зависит = бальзам.
Сам-то кто? Ой, бросьте - уже 20 лет как читать разучился и мимо-крокодил.
kosmos89
02.08.2021 00:46Мне интересно, а какие перспективы развития у x86 и ARM, например? AVX1024 что ли? :)
DistortNeo
02.08.2021 01:30AVX1024 что ли? :)
Ага. С 6-байтным префиксом RVEX и 4-байтными опкодами.
Armmaster Автор
02.08.2021 01:36Ага. А сколько там каналов памяти потребуется, мне даже думать не хочется ))
qw1
02.08.2021 09:44+1Мне интересно, а какие перспективы развития у x86 и ARM, например? AVX1024 что ли? :)
А какие перспективы у Эльбруса? Сейчас в широкой команде 6 слотов. Чтобы увеличить пропускную способность, увеличат до 16? Причём на обычных последовательных задачах (gui, архиваторы, драйверы) в команде будет 2-3 выполняемые инструкции, а остальные NOP-ы, потому что параллелизма не нашли.
beeruser
02.08.2021 10:46+1Перспективы развития определяются спросом и предложением.
Причём тут SIMD набор?
Впрочем на ARM векторный набор с переменной длиной слова вплоть до 2048 бит.
developer.arm.com/documentation/102476/0001/Introducing-SVE
MaOR
02.08.2021 02:39+1Интересная статья, видно, что у автора наболело, да и он действительно представляет о чем пишет. Но вот по отдельным моментам есть вопросы.
Несколько забываем о легаси. Т.е. да, Эльбрус со своими VLIW заморочками не идеален, но он есть. И он может исполнять х86 код здесь и сейчас. Для любых других архитектур придется пересобирать софт или запускать под эмулятором. А х86 под эмулятором даже на х86 это туго, молчу уж про RISC, в качестве хост системы.
-
Таблица про сравнение архитектур: частоты/tdp и т.д. Во-первых в ней не хватает столбца производительность. Толку с 5ГГц на проце, если он все время с заблокированным конвейером и ждет данных?. Во-вторых. Сами данные в таблице:
Первые две строки: у Xeon почти в полтора раза меньше транзисторов (раз уж вы именно их используете в качестве основы для сравнения площади, а не саму площадь), частота меньше на +-20%, но TDP только на 12% больше. Так ли плох Итаниум?
По Эльбрусам вообще завал - СПАРК аж в 7 раз меньше, и по частоте быстрее только на треть, зато по TDP VLIW больше только в 2 раза. Так, получается, VLIW очень даже неплох?
Умолчим про то, что сравнивать TDP только по количеству транзисторов не совсем корректно, все же есть памяти, а они тоже едят и очень немало...
Что до вывода: а какое решение вы предлагаете? Купить лицензию на х86? Малореально, да и в текущей ситуации не факт, что перспективно. MIPS уже нельзя назвать перспективным, к сожалению. Перспективы ARM тоже не совсем ясны, RISC-V пока только развивается, хотя направление интересное, но серьезных процессоров на нем я пока не видел.
Armmaster Автор
02.08.2021 02:51+2Эльбрус запускает x86 код через бинарную трансляцию. Ничто не мешает делать также на любой другой архитектуре.
Есть миллион факторов, которые влияют на приведённые цифры. Например, у Спарка выше частота, а значит выше напряжение питания, а TDP зависит от этого квадратично. Плюс на SOC'e Эльбруса есть много всякой периферии и т.д., которые в обычном режиме особо ничего не потребляют. Ну и т.д. и т.п. Эта таблица была приведена лишь для того, чтобы показать, что чипы VLIW от одних и тех же производителей уступают по частотам их RISC конкурентам. Производительность проца - это грубо микроархитектурная скорость + частота. И VLIW проигрывает и там, и там. Ну и по ней также видно, что энергоэффективности там нет (если бы частота была ниже, но и TDP ниже, можно было бы утверждать, что "зато он более энергоэффективен").
Что касается решения - у меня есть своё мнение, но это тема для отдельной статьи, т.к. это куда более дискуссионный вопрос. Здесь я хотел лишь показать проблемы VLIW и то, что он заведомо проигрывает любой RISC/CISC архитектуре при прочих равных.
le2
02.08.2021 03:20+1Я так, мимо крокодил.
Но однажды я два дня курил официальную документацию на Cortex-A. (интересовало в первую очередь исполнение из тесносвязанной памяти, кэширование, сколько там АЛУ, и прочее)
Ребят, камон, полезную работу выполняет не процессор, а весь компьютер. И где там бутылочные горлышки сразу совсем не понятно. В частности, я пришел к выводу, что системная шина (шины) сложнее и противнее в разработке чем вычислительное ядро. Как еще объяснить что MIPS лицензировало её у АRM? Да и полной документации на неё нет в открытом доступе. А ведь это целый «интернет» с пакетной передачей данных.
Или вот взять такие аппаратные блоки как USB или PCIe. Это также огромная огромная работа, которая влияет на производительность всего компьютера.
Короче я считаю что Эльбрус это как Жигули (новые Lada) собственной разработки. Нужно хоть чем-то заниматься чтобы не похоронить конструкторскую школу. Очень важно уметь доводить работу до конца, а не быть специалистом по фрагментарным знаниями
В процессе разработки компьютеров необходимо решать очень много задач, которые не упираются только в архитектуру процессора.
Всё быстро развивается и мы можем попасть в совсем другую реальность. Прямо сейчас я пишу с компьютера в 48 ядер и 96Гигабайт. Вы уверены что то что вы описываете будет важно, если вдруг ядер у всех будет по 4800?amartology
02.08.2021 03:46я считаю что Эльбрус это как Жигули (новые Lada) собственной разработки. Нужно хоть чем-то заниматься чтобы не похоронить конструкторскую школу
Почему бы не делать вместо «Жигулей» нормальные процессоры? Конструкторская школа — она не только в МЦСТ, она ещё в десятке других мест в России развивается, и в некоторых случаях с как минимум не меньшим успехом.le2
02.08.2021 03:59да нет никаких других мест. Этож референсные дизайны от вендоров, где ты можешь (в зависимости от типа лицензии) максимум поменять периферийные блоки. Мы же сейчас не про микроконтроллеры? Большинство также это только прототипы на ПЛИС без воплощения в чипе.
Проблема референсных дизайнов, если отбросить политику, это то чем тебя ограничили буржуинские менеджеры по продажам. Например у Cortex-M0 раньше нельзя было заявлять частоту выше 48 МГц.
Я как-то читал статью про разработку вакцины Спутник-Ви. Что я прочитал между строк — предыдущие вакцины формально сделали, но никуда не успели с внедрением, а зато последняя выстрелила за счет того что руку набили.
Так и с Эльбрусием. При необходимости можно заменить ядро на Risc-V. Это будет, вероятно, только процентов 5 от всех работ где компетенцию уже наработала.
Другое дело что, как понимаю, сейчас большая интрига. Куча контор влошилась в Эльбрусий, а государство их кинуло. Вероятно сейчас отечественность будет доказываться наличием внутри отечественного контроллера, который будет мигать светодиодами, а внутри будет Интел.amartology
02.08.2021 09:16Референсные дизайны от вендоров? Нет никаких других мест?
Вы сейчас довольно серьезно обидели как минимум НИИСИ и Синтакор, а как максимум ещё Элвис, Модуль и IVA. Все они ведут собственные микроархитектурные разработки вещей совсем не микроконтроллерного уровня.
vkni
02.08.2021 08:10+2«Пусть расцветают сто цветов.»
Уважаемый Vlev выше написалИ по самым скромным оценкам на это уже потрачено несколько сотен миллионов долларов гос.финансирования.
Сотня миллионов долларов — это примерно стоимость квартир в одном доме типа «корабль» в Москве. Да хоть миллиард пусть потрачен, это немного на масштабах страны. В конце-концов, государств со своей школой микропроцессоростроения очень мало.amartology
02.08.2021 09:22+1Дайте мне тысячу рублей? Вам несложно, а государств, в которых мне дают тысячу рублей, очень мало.
Am0ralist
02.08.2021 10:21Моему другу прям только что перечислили 10к государство. Таких как он — миллионы в РФ. И что это должно доказать?
А уж сколько государство тратит на закупку компов с сертийикатом ФСТЭК — это ж вообще сказка. Просто на пустом месте цена х3-х5. Да, за дырявый интел
vkni
02.08.2021 10:45+2Вот из этого и других ваших аргументов следует, что у нас с вами принципиально разное понимание экономической сущности государства РФ. Насколько я понимаю, пожалуйста поправьте меня, если я неправ, вы полагаете, что на разработку Эльбруса будут затрачены деньги, дополнительно отобранные у нас с вами.
С моей (и, кажется, ув. Am0ralist) точки зрения, деньги у нас отнимут в любом случае налогами. То есть, эту тысячу у меня уже забрали. А дальше уже есть несколько вариантов — либо их потратят на понты в виде очередной яхты/недвижимости, либо на МЦСТ. Вот второй вариант меня устраивает несравнимо больше.
Да, разумеется, у меня есть знакомые в науке, сидящие на грантах, лучше бы моя налоговая тысяча пошла им. Но такого выбора у меня нет.qw1
02.08.2021 11:03Это как в анекдоте «папа, ты теперь пить будешь меньше? нет, доча, это вы с мамой будете меньше есть».
То есть траты на яхты/виллы никуда не денутся, а вот деньги, ушедшие в МЦСТ, могли бы уйти в школы или на ремонт дорог.
amartology
02.08.2021 11:15+1либо их потратят на понты в виде очередной яхты/недвижимости, либо на МЦСТ. Вот второй вариант меня устраивает несравнимо больше.
А если два варианта — это Эльбрус и какой-то другой более перспективный процессор?Am0ralist
02.08.2021 11:46-1А если два варианта — это Эльбрус и какой-то другой более перспективный процессор?
Что значит если? Вон выше 27,8 млрд рублей за риски-В от «ядра». На эльбрусы суммарно за всё время столько хоть потратили? Вы рады?amartology
02.08.2021 12:00Вы рады?
Да, рад.Am0ralist
02.08.2021 12:37-2То есть если у вас отняли тысячу — вы не рады, если у вас отняли 10 тысяч — то норм? Ну, с учетом, что проект выглядит именно распильным по тому количеству процессоров, которые получит государство в итоге.
На минуточку, это вдвое больше чем инвестиции в SiFive — компанию, в которой работают чуваки, которые этот самый RISC-V с нуля разработали и такие ребята как Крис Латтнер (разработчик свифта и LLVM) и вот-вот уже выпустят приличную версию. И которых интел хотел купить за два лярда, но они не продались. И это за пять лет с ровного места :)
Ссылка на комментamartology
02.08.2021 12:49Ну, с учетом, что проект выглядит именно распильным по тому количеству процессоров, которые получит государство в итоге.
А что, Эльбрусов или Байкалов предполагается больше?Am0ralist
02.08.2021 13:15+1Им выделяли за всё время меньше в сумме, чем оному (тут же только первый раунд, как говорится), причём данную сумму выделяют просто в молоко (ну не шмогли, ответят, и кто-то даже может сесть). И при подсчёте, что через 5-6 лет мы получим всего тысяч 60 по 12 нм, получится, что их себестоимость будет выше, чем текущие эльбрусы (у который так-то уже 16с пошли насколько помню), с вероятностью к тому же явно не оказаться в лидерах производительности среди аналогов к тому моменту. То есть отставать так же, как сейчас эльбрусы.
Зато на то, что вам типа нравится потратят больше денег, чем на то, что вам не нравится и это — гуд по вашему.
amartology
02.08.2021 15:41Зато на то, что вам типа нравится потратят больше денег, чем на то, что вам не нравится и это — гуд по вашему.
Начнем с того, что на выделенные оллайтм на Эльбрус деньги спроектировать нормальный процессор в принципе было невозможно. Деньги, которые предполагается потратить на процессор от Yadro, хотя бы примерно соответствуют реальной стоимости подобного проекта.
А когда выделяются копейки, которых еле хватает на поддержание штанов и зарплаты, это плохо вне зависимости от того, о чем конкретно идет речь.
Am0ralist
02.08.2021 15:53Начнем с того, что на выделенные оллайтм на Эльбрус деньги спроектировать нормальный процессор в принципе было невозможно.
16С вполне себе нормальный процессор мог бы быть. При этом не требовал столько лярдов для уже таки внедрения (компы и так постоянно закупаются по диким ценам из-за сертификатов фстэк) в реальность, а не мифическое производство мелкими партиями по ещё большему прайсу ещё через 5 лет.
victor_1212
03.08.2021 03:35это возможно означает, что решение проблемы не находится в технической плоскости, не исключено что в итоге нарисуется перспектива совместно развивать Kirin 9000, Balong и пр. если конечно будет желание с обеих сторон, кажется события развиваются в этом направлении
wigneddoom
02.08.2021 14:17Это неизвестно. Но сейчас судя по тому, что МЦСТ проигрывает контракты Байкал, последних было произведено больше, ну или как мимнимум, их смогли поставить в нужных количествах. А Байкал-Т так вообще можно в магазине купить, жаль что он уже никому не нужен.
Что касается Syntacore + Yadro, так они планируют окучить совсем другую область. МЦСТ при должном финансировании и т.д. к 25-му году смогли бы предоставить 32С, который в любом случае будет производительнее запланированного RISC-V (тут я конечно из новостей информацию беру).
Вобщем двоякое ощущение, с одной стороны я скептически отношусь к МЦСТ и VLIW, но с другой, они хоть что-то показывают реальное, пригодное для серверного применения. Как бы за двумя зайцами не погнаться...
vkni
02.08.2021 11:54Я лично был бы счастлив. Но пока я полагаю, что только реальная угроза настоящей холодной войны как-то заставляет тратиться хотя бы на Эльбрус.
Armmaster Автор
02.08.2021 11:32+2Вы занимаетесь подтасовкой. Вариантов больше. например, дать деньги на разработку процессоров другим. Или МЦСТ, но на разработку другой линейки, государство же заказчик и определяет требования.
vkni
02.08.2021 11:52Ни мы, ни вы выбором этих вариантов не занимаемся. А по-факту, я значительно более пессимистичен — только возможность натуральной войны заставляет хоть как-то тратиться не только на яхты.
VLev
02.08.2021 13:29ну вообще эти самые то ли 360, то ли 270млрд руб уже выделены. Если их не раздадут разработчикам микроэлектроники -- они просто уйдут в бюджет. Причём на данный момент озвучено всего 12 сквозных проектов. С ограничением по максимальной стоимости. То есть денег ещё есть на несколько проектов.
Так что если надо -- подавайте заявку. Я вот не очень понимаю почему не подают...
edo1h
02.08.2021 08:27+3Линус Торвальдс согласен с автором статьи (правда, он пишет про итаник):
static instruction scheduling is a monumentally bad idea. It's stupid beyond words, unless you're doing the tiniest of microcontrollers or DSP's. Doing it for a processor design that was supposed to take over the server world? Unbelievably stupid.
https://www.realworldtech.com/forum/?threadid=193189&curpostid=193515
Armmaster Автор
03.08.2021 02:59+6Да, спасибо, я кстати забыл про этот поста Линуса. Он пишет здесь не просто про Итаник, а про то, что даже Итаник ( который типа не просто VLIW, но ещё и EPIC, что в идеале должно давать больше гибкости) уступает процам с OoO. Заметьте, Линус - это тот человек, который 6 лет в Трансмете делал индустриальный VLIW процессор. Т.е. он один из немногих людей, который не просто рассуждает теоретически, а реально поел все реальные проблемы с перфом лопатой. Неудивительно, что наше мнение с ним в данном вопросе совпало ))
Imobile
02.08.2021 08:57+1где антагонисты утверждают, что Эльбрус это просто старые процессоры Итаниум с переклеенными шильдиками,
В любом случае процессору Итаниум сказал рынок давай - до свиданья, а эльбрусу никто такого кроме чиновников сказать не может. И будут все Россияне платить за него. И это не значит, что он себе приобретёт для работы, скорей всего будет пылится на складе у какого-нибудь чиновника, а он на маке будет работать
tangro
02.08.2021 10:27Люди считают какие-то байты, такты, деньги, производительность - кому это всё интересно? Идея Эльбруса всегда была в одном - чтобы в случае полномасштабной войны, санкций, перекрытия вообще всех границ и поставок остаться ну хоть с каким-нибудь процессором, ОС, софтом. Пусть в 10х медленнее мировых аналогов, но всё-таки на нём можно будет запустить какую-то программу расчётов чего-небудь, связи, офисный пакет, и т.д. Никто никогда не собирался конкурировать с х86 или arm. Конкурировать собирались только с ситуацией "в стране не осталось компьютеров вообще" и у этой ситуации вполне себе Эльбрусом выиграли.
qw1
02.08.2021 10:45+1А что мешает клонировать ARM? И остаться в случае войны со своими процессорами, но кучей написанного софта.
tangro
02.08.2021 11:02Ну, как... Платить за лицензию надо (вот сейчас, пока ещё надо соблюдать видимость законности). Нельзя гордо вещать "сделано у нас!". Ключевые спецы, которые это всё придумали и понимают, почему оно сделано так, а не иначе - находятся вне страны.
При этом всём вполне может быть, что стратегия "скопипастить arm" тоже на всякий случай лежит в ящике, это ведь сделать можно в любой момент, там ведь всё на виду лежит.
Am0ralist
02.08.2021 11:50А кто вам будет производить «клонированные» армы с нарушением лицензий?
Тогда уж риски-в делать, но там тоже пока вопросов хватает.qw1
02.08.2021 15:08А зачем нарушать лицензию? Нельзя, как apple, заплатить 1 раз за неограниченное право на ARMv8, например?
Am0ralist
02.08.2021 15:46А можно купить заводик-банкрот по производству европейских машинок?
Не знаю. Может можно, а может нужно разрешение по экспорту от США.
Ну как зен1 продали китайцам без криптографии, а дальше уже не продали.qw1
02.08.2021 17:59Китайцам зен1 продали с «исходниками», или фотошаблоны?
Потому как если с исходниками (как в случае с ARMv8), то никакой проблемы, что ARMv9 не продадут. Можно самостоятельно развивать v8Am0ralist
02.08.2021 19:25Эм, не думаю, что АМД могли продать фотошаблоны под китайскую криптографию. Была совместная компания, часть которой контролировал АМД, которая вроде как и разрабатывала, и заказывала чипы. А вот лицензии могли не продать. То есть эти делать можешь, а развивать — нет. А могли и продать. Я хз, такие данные в открытом доступе не лежат же.
Civil
03.08.2021 01:27+2А тут можно не думать, а почитать что говорилось в новостях:
AMD reached out and clarified that it did not transfer the RTL to the JV, but JV can modify some parts of the design to customize the chips for the China market. AMD isn't being more specific about the licensed technologies. Sources close to the matter tell us that while some portions of the core can be modified, other parts cannot.
ALXN
02.08.2021 11:38+2Так не в России же он делается, а на Тайване. Так что в этом смысле никакой разницы.
amartology
02.08.2021 11:40+2чтобы в случае полномасштабной войны, санкций, перекрытия вообще всех границ и поставок остаться ну хоть с каким-нибудь процессором
… производимым на Тайване?
rogoz
02.08.2021 15:10А сетевой контролёр и прошивку HDD/SSD (ну и сами HDD/SSD) в Эльбрус компьютере кто сделал??
pirate_tony
02.08.2021 10:28+1Отличная статья про эти процы.
Но большинство комментариев здесь похожи на какие-то философские рассуждения "а вот если так сравнивать, то было бы вот так". Хотя автор вроде развёрнуто изложил всю базовую ущербность VLIW. И вообще эта статья является отличным пособием "вы никогда не заработаете денег на VLIW"...
yalex1442
02.08.2021 10:50А как вы смотрите на развитие VLIW и OoO (с его тратами топлива на динамическую оптимизацию снова и снова) не в вакууме без ограничений, а в рамках мировой повестки борьбы с глобальным потеплением?
Вот реальный пример того, где это уже вылилось в реальные нормативные акты:
https://habr.com/ru/news/t/569888/
при определенных вложениях есть ли у VLIW перспективы обойти прочие подходы пусть и не в производительности однопотока, а в плане Вт/попугай?qw1
02.08.2021 11:10Ерунда это полная. Любой КАМАЗ выделяет больше тепла и CO2, чем стойка в дата-центре, а потому, если глобально подходить к проблеме потепления, с них надо начинать оптимизацию.
Не говоря уже о всяких металлургических производствах и т.п.
Armmaster Автор
02.08.2021 11:37Только в каких-то узких нишах, и то не факт. OoO не так уж много стоит пауэра, если цель - снизить потребление.
dzavalishin
02.08.2021 11:49При динамической JIT компиляции проблем с инлайнингом и вообще глубоким анализом алиасинга нет. А если пишешь на си - ну - страдай и оптимизируй руками.
kostjaden
02.08.2021 12:09Зачем своя микроархитектура? Чтобы не быть зависимым от "партнера", который хочет тебя извести. Если бы в мире был коммунизм, можно было не ставить дверей и открыто обмениваться знаниями. Как номенклатура СССР решила покупать в купе со станками и импортные ЭВМ ч софтом (IBM, DEC, прочие), то не убили бы собственное вполне конкурентоспособное, более того, перспективные направления развития ВТ и кибернетики. Решили: зачем "геморрой", как Вы сказали, если можно купить готовое или лицензию? Эффект будет таким же, как если всю жизнь пользоваться шпаргалками и ненаучиться мыслить самостоятельно. Это выстрел даже не в ногу, это выстрел в голову. А теперь поздно пить боржоми и сорить деньгами, теперь именно что геморрой и нужен, свой путь (тем более что западный уже тупиковый, зачем догонять?). Но не деньгами решать проблему, потому что набегут разного рода жулики и казнакрады, а перспективамт стать долговременным лидером отрасли. Пусть академические инстититуты на кафедрах ломают голову. В том числе и над разработкой фундаментальных основ и прикладных технологий интегральный процессов, конструкции и принципов действия средств тиражирования. Неужели остались люди, кто хочет только нахапать и беспечно прожигать жизнь, и не интересно быть не только свидетелем, но и творцом нашего общего будущего?
amartology
02.08.2021 12:18Пусть академические инстититуты на кафедрах ломают голову.
Так уже все равно разработано в НИИСИ РАН и производится серийно. Прсто с меньшей помпой, чем Эльбрусы.
wigneddoom
02.08.2021 13:31В целом согласен с автором.
Но есть нюанс. Сейчас и в ближайшие 5 лет Эльбрус это самый производительный отечественный процессор. С 16С, который вроде как вот-вот уже будет доступен, нечего сравнить. Байкал-М - заурядный ARM, который больше подходит для эмбеддед и тонких клиентов. Есть конечно надежда, что их планы сбудутся и они выпустят 48 ядерный Байкал-S. КОМДИВ-64 - это тоже сугубо встраиваемые системы. Поэтому 16С безальтернативен как для тех кого поставили в позу импортозамещения, так и для тех кто хочет на этом заработать, но при этом требуется производительность: СХД, СУБД, миникластеры числодробилки и т. д. И, возможно в этих областях, он ещё долго будет существовать и развиваться.
Как general-purpose Эльбрус видят только его создатели, которые в лице А. Кима, постоянно устраиваю плач Ярославны, о том как их зажимают, не пишут в контрактах ISA E2K, отдают Байкалы в РЖД. А государство похоже не видит его таковым в силу разных причин, будь-то создание видимости конкуренции, лавирование между заинтересованными лицами и т. д. Да и те же госконторы будут его саботировать в тех областях где ему есть адекватная замена и цена.
В будущем, в качестве ISA хотелось бы видеть развитие RISC-V, т.к. при всех недостатках, она сможет покрыть задачи от микроконтроллеров до серверов. Ну и второе направление - это конечно развитие переферии. 100 Гбит/с сетевя карта с offload (TX/RX, TLS, iSCSI, NFS, RDMA) дорогого стоит. Ну и конечно формировать некий альянс отечественных производителей с кросслицензированием и т.д.
Arioch
03.08.2021 21:28Ну так выпускали бы быстрый Эльбрус-E2K и одновременно с ним быстрый Эльбрус-SPARC и не было бы этих проблем, казалось бы. Или они как раз боятся прямого столкновения с Fujitsu, когда на одинаковой архитектуре сравнения микроархитектур не удастся скрыть?
amarao
02.08.2021 14:27Т.е. всё-таки "русский итаник". Ровно те же проблемы, которые были у Итаниума - перекладывание головной боли на компилятор, отсутствие нормального быстрого компилятора, своя архитектура с вытекающим из этого куцым юзерспейсом за который надо бороться.
Mox
02.08.2021 14:57Я думаю что проблема именно в том, как они развивают
Максимально закрытые спецификации
Весь софт пишут сами, минимально взаимодействуя с OpenSource сообществами. Хотя могли бы компилятор сделать на llvm, окрыть всем, и получить как встроенные в llvm плюшки, так и сами делать vliw оптимизации в OpenSource
Усложненный доступ к документации и рабочим экземплярам
Не предлагают лицензировать архитектуру другим организациям
Не проводят CusDev. Например - если эта штука хорошо молотит числа, то может быть нужно позиционировать его для нейросетевых применений, сделать соответствующие версии PyTorch, TensorFlow.
При таком подходе это все шевелится, пока деньги дает государство, но это может и закончится. Вместе с рисками миграции - на месте госзаказчиков я бы выбирал Байкал-S или RISC-V варианты.
wigneddoom
02.08.2021 20:23+1на месте госзаказчиков я бы выбирал Байкал-S или RISC-V варианты
Я бы тоже, но их пока не существует.
welga
02.08.2021 16:16В свое время, когда в СССР было принято решение в пользу серии ЕС ЭВМ, для военных оставили линейку БЭМС-Эльбрус. Эльбрус тоже был тогда жутко дорог, потому что выпускался поштучно. Были предложения использовать Эльбрус и в промышленности, чтобы увеличить объемы производства и тем самым уменьшить себестоимость. Но эти планы не были приняты, что по моему было правильно. Может и в нынешней ситуации, не стоит из Эльбруса делать универсальный процессор. Заказчики Эльбруса - военные. Вот пусть они и работают с ним. А что касается дороговизны Эльбруса, так военная техника всегда будет дороже гражданской.
Arioch
03.08.2021 21:21Вот сравнение самых топовых решений процессоров на базе VLIW-архитектур от Intel и МЦСТ с их RISC/CISC аналогами
Это не срачегенно, надо было табличку Radeon vs GeForce сделать, тем более там как раз вроде бы идеальный случай для VLIW - и рассчеты максимально однообразные, и код компилируется на машине пользователя при уже, потенциально, известных данных.
Кстати, неизвестность реальных данных и какие куски станут горячими - это для C++, а вот для всё более и более модных виртуальных JIT-машин (.NET, JVM, потенциально даже и LLVM) это уже не аргумент.
OpenA
04.08.2021 11:32-1r0 нельзя использовать в одной ШК сразу для трех операций, второй пример ассемблера демонстрирует так называемый конвейризованный цикл - аппаратную фичу эльбруса которая позволяет обращаться к массиву данных минуя кэш не используя обычные лоады/сторы а используя мувы из буфера подкачки.
Конечно без инлайна функции это не работает так как вызовы в конвейризованных циклах не допускаются и будет обычный цикл как на интеле с прыжком наверх - и чё? В чем недостаток, я не понял.
Как и не понял что там и где у тебя в коде нельзя проанализировать, где в чем тупик.
Понял только что ассемблер сложный-нипанятный а в документацию посмотреть хотя бы перед написанием статьи мы не умеем.
В общем статья уровня школьник для школьников пересказал какие то тезисы из интернета и приправил своей безграмотной отсебятиной.
Armmaster Автор
04.08.2021 14:32Конечно же можно r0 использовать для нескольких операций в одной ШК. Пример этого кода мной просто скопипастен отсюда
Что касается инлайна, по моему я достаточно доступно изложил, в чём проблема - если в Эльбрусе не сработал инлайн, то у вас исполнение итерации цикла увеличивается с 1 такта (это если конвейеризация сработала) до 17. В то время как на том же Интеле увеличение будет до 2-3х тактов, как мы тут в коментах немного уточнили
Остальные ваши напрыги я смысла коментировать не вижу
OpenA
04.08.2021 13:15-1>Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал. В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.
Начнем с того что с высокой долей вероятности компилятор для интела (clang/gcc) подставит вместо этого цикла константу, не то что что-то синлайнит. Во вторых хотелось бы какие то замеры увидеть куда интел денет вызов? Я понимаю бранчь предиктор сгладит это всё но сам вызов и ожидание из функции никуда не денется, и цикл сам по себе не развернется, процессор будет делать все вызовы и переходы. На эльбрусе нет бранчпредиктора, но там просто вызовы и переходы тупо явно подготавливаются в доп.конвеер (коих три у него) и переключаются за один такт. Но это не значит что итерация будет занимать такт, такт занимало бы простое сложение чисел, но никак не с вызовом чего то.
Armmaster Автор
04.08.2021 14:36+1Ваш комент явно говорит о том, что вы не поимаете ни как это работает на Эльбрусе, ни как не Интеле.
Давайте по порядку. Во-первых, я там сразу оговорился, что именно такой кейс компилятор почти наверняка заинлайнит и соптимизирует и он специально такой приведён для упрощения понимания. Потому что если бы я начал приводить примеры из реально
Armmaster Автор
04.08.2021 14:43+1[случайно отправилось - продолжение]
из реального кода, то там всё было бы гораздо труднее для понимания.
Дальше. У Эльбруса подготовка для перехода обычного занимает 5 тактов, return - 7. Вызов call мешает вам вынести подготовку регистра ctpr из цикла. Поэтому вы вынуждены будете сделать подготовку и ждать 5 тактов для вызова call, потом 7 тактов для return и ещё 5 тактов на переход на голову цикла. Отсюда минимум 17 тактов итерация.
В Интеле же весь этот код превратится просто в линейку add - mov-cmp , т.к. jmp-call-ret бранч предиктор просто сожрёт и выбросит (там есть некоторые накладные расходы, но они небольшие и требуют более глубокого погружения в детали работы процессора, здесь это неважно для понимания)
shcher
04.08.2021 18:49Тем не менее, примеры из реального кода были бы намного более интересны и содержательны (естественно, на горячих циклах). Можно справедливо допустить, что появление других операций приведёт к изменению поведения компилятора и отказу от подстановки функции. Но это приведёт и к увеличению наполненности ШК. Так что возникает вопрос: сохранится ли отставание в более сложном примере? Уверен, оно наоборот сократится.
К тому же, Эльбрус невозможно рассматривать в отрыве от конкретного компилятора. Не скажу, что это хорошо, это создаёт определённые неудобства разработчикам. Тем не менее, есть факт: при использовании различных версий компилятора ощущаются существенные различия. От версии 1.23 до 1.26 наблюдается улучшение производительности, в частности, от подстановок функций, которые раньше не происходили. Насчёт более ранних версий не знаю, не использовал, может быть, там не было видимого роста.
Потом следует отметить, что ваш пример показывает, с какими проблемами можно столкнуться из-за отсутствия предсказателя переходов. Точно так же можно привести альтернативный пример: условный переход в цикле. Традиционно компиляторы под x86-64 генерируют код с переходом. Ручное переписывание с заменой условного исполнения на арифметические операции позволяет добиться кратного ускорения. С другой стороны, из-за предикатного исполнения на Эльбрусе такой проблемы нет. И ни один из этих примеров не показывает явного преимущества одной архитектуры над другой.
Кажется, появление предсказателя переходов решит определённый пласт проблем. Почему его довольно давно обещают, но ещё не сделали — это не выглядит как технический вопрос. Но отсутствие предсказателя — это недостаток строго текущей версии архитектуры, а не идеи в целом. Боюсь, заявлять тупиковость развития на основании этого — слишком громко.
Armmaster Автор
04.08.2021 22:26+3Тем не менее, примеры из реального кода были бы намного более интересны и содержательны
Это, безусловно, так, с той лишь поправкой, что они потребовали бы куда более глубоких знаний для восприятия статьи. Я всё же ставил цель сделать её максимально технически доступной. Ну и сути происходящего они бы не изменили.
Так что возникает вопрос: сохранится ли отставание в более сложном примере? Уверен, оно наоборот сократится.
Оно сократится, но сохранится. Этот пример призван показать, что на том коде, который компилятор не смог соптимизировать, производительность VLIW падает куда более драматично, чем на RISC/CISC. А в реальных сложных проектах это будет происходить сплошь и рядом.
Ручное переписывание с заменой условного исполнения на арифметические операции позволяет добиться кратного ускорения. С другой стороны, из-за предикатного исполнения на Эльбрусе такой проблемы нет.
Добиться кратного ускорения на x86 в таком случае можно только если бранч предиктор часто ошибается в таком коде. А это крайне редкий случай. Что касается Эльбруса - предикатный код может сгладить проблему наполненности ШК, но надо понимать, что такой подход всё равно уступает OoO с бранч предиктором, где просто исполнятся только те команды, которые нужно. А Эльбрусу всё равно придётся дожидаться статически спланированных инструкций по критическому пути. Ну и для хорошего предикатного кода нужен хороший профиль, что тоже часто непременимо.
Кажется, появление предсказателя переходов решит определённый пласт проблем.
Согласен, что набор проблем решит. Но останутся другие. Я, кстати, про Итаниум недаром в статье упомянул. Там бранч предиктор был (и вообще там VLIW-архитектура изначально более гибкая). Но он всё равно по итогу существенно проигрывал x86.
edo1h
05.08.2021 01:37Это, безусловно, так, с той лишь поправкой, что они потребовали бы куда более глубоких знаний для восприятия статьи
вообще странный аргумент для хабра.
я не говорю о том, что если сложно, то технические моменты можно и опустить.
OpenA
04.08.2021 18:52-4Э нет, уважаемый, подготовка перехода происходит ДО входа в цикл, а попутно еще надо проверить условие вообще входа в цикл, в самом цикле подготовку каждую итерацию не делают, уж если не хватило конвеера для функции (хотя как раз три то и хватает - цикл+функция+выход из цикла) проще непосредственный бранч/вызов делать.
А вызовы он не может делать только в конвейризованных циклах (loop mode) - это специальный аппаратный режим необходимый прежде всего что бы вращаемые регистры по базе автоматически сдвигалить, ну и плюс там счетчики автоинкриментировались и прочее.
У оутофордеров нет такого режима, у них бранч - раз инструкция - два инструкция - сравнение каких-то операндов - хоп джамп в тот же бранч, процессор даже не знает что он в цикле работает, эльбрус делает так же в самых глухих случаях типа while (ptr1 != NULL) он не отличается (с точки зрения процессора) от обычной процедуры и вызовы из нее делаются хоть куда. У интела будет колл и мов константы у эльбруса подготовленный кол и add литерал с r0, хочешь показать пример на котором эльбрус обсирается так хоть у знающих людей спрашивай совета перед тем как что то объяснять на глупых примерах. В данном примере эльбрус скорее потому что его компилятор будет этот цикл оптимизировать, тогда как гцц на*уй выкинет вообще и вставит загрузку константы.
numas13
04.08.2021 20:34+5Премного уважаемый, не могли бы прекратить нести полную околесицу?
подготовка перехода происходит ДО входа в цикл
После вызова процедуры значения в регистрах подготовленных переходов нельзя использовать, т.к. будет выброшено исключение. В этой ситуации необходимо будет делать подготовку на начало цикла в самом цикле (+5 тактов), после вызова другой процедуры.
А вызовы он не может делать только в конвейризованных циклах (loop mode) - это специальный аппаратный режим необходимый прежде всего что бы вращаемые регистры по базе автоматически сдвигалить, ну и плюс там счетчики автоинкриментировались и прочее.
В таком цикле можно сделать вызов, но надо будет самостоятельно сохранить/восстановить всё нужное состояние не переживающее вызовы.
OpenA
04.08.2021 23:42Я с ваами сам отупел уже, думаю про волшебную коробочку где чик брик все за один такт исполняется и напрочь забыл про конвейер.
Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, просто потому что (не знаю как это работает) они в конвеере не опустошаются а мотаются бесконечно пока не переключишься. В иных случаях после каждого вызова/перехода надо готовить конвейер заного, но это не значит что нельзя сделать подготовку ДО потом прыгнуть в цикл вызвать подготовленный CALL вернуться и тут же его опять начать готовить вместе со сложением и прочим до возврата в начало цикла, так как это все в рамках одной процедуры которая задается процедурным окном о каких таких исключениях речь я не понимаю.
У интела пайплайн в два три раза длиннее кстати, какой там нахрен один такт при переходах.
Ну и алу все конечно тоже конвейризованные, конечно можно r0 на считывание всем заюзать, тут я тупанул.
numas13
05.08.2021 06:20+3Я с ваами сам отупел уже
Мне кажется, что мы тут не при чём.
Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, ...
Нет, вы опять несёте какую-то пургу.
Я бы не хотел ссылаться на авторитетность, но я один из тех кто написал эмулятор для e2k и имею определённое представление о том как он работает.
Давайте вы прекратите распространять нелепицу и вводить в заблуждение тех, кто не согласен с автором?
Можете не утруждать себя ответом, т.к. я на него не отвечу.
OpenA
05.08.2021 08:25-3Да вижу.
Один писал эмулятор команд суперскаляра для эльбруса пришел к выводу что раз в ассемблере х86 микрокода и пайплайна не видно значит там такой проблемы нет, а декодируется исполняется,конвейризируется и инлайнится там все так же как в компиляторе и все за один такт а то и меньше.
Второй поверх суперскаляра городил явно управляемую машину и пришел почему то к выводу что на целевой машине тоже при переходах все откидывается и берется со стека, а порядок исполнения интеловский ассемблер не позволяет нарушать и поэтому это проблема эльбруса что он не позволяет силами x86 isa реализовать какие то свои причуды с порядком исполнения действий с операндами. А пайплайн это что то из мифологии и 6 тактов подготовка просто потому что глупые люди делали надо просто прыжок делать за один такт и всё, как на умных интелах.
Так и живем.
Armmaster Автор
04.08.2021 21:11Вы сначали написали глупости про r0, теперь пишите ерунду про подготовки в Эльбрусе. Вам верно заметили что из цикла в данном случае ничего вынести нельзя будет, т.к. подготовка не переживёт call.
santey_tm
04.08.2021 14:46Автор утверждает, будто VLIW при тех же нанометрах имеют более высокое тепловыделение и больше транзисторов.
И приводит в пример Intel Xeon Processor E3-1290, у которого объем кэша 8Мб в сравнении с Итаником 2017г, у которого этого кеша 32МбПосле такой ловкости рук все остальные сентенции вызывают мало доверия.
Хотя в статье и есть достоверные сведения, но по своей направленности она явно ангажирована. По сути, лайт-вариант антиэльбрусовских пасквилей образца начала нулевых, авторство которых принадлежит одному деятелю родом с Незалежной, известному под ником matik
Судя по всему, Yadro перехватила все контракты на лисковые хранилища под закон Яровой. При том, что в их хранилищах используются Интелы.
Отсюда и обещания по скорому созданию своего варианта Risc-V, отсюда и подобные статьиArmmaster Автор
04.08.2021 14:58Так у этого Intel'a и TDP почти в 2 раза меньше по сравнению с Итаниумом 4-х ядерным. При существенно более высокой частоте. Выше есть сравнение 32MB Итаниума и 20MB x86 и ситуация там схожая.
Невозможно найти абсолютно одинаковые примеры 2х процессоров, есть куча нюансов. И данная таблица в первую очередь показываюе, что VLIW процессоры не достигают топовых частот аналогов RISC/CISC, т.е. проигрывают не только по микроархитектурной скорости, но и по частотам. Энергоэффективность это я написал вдогонку, но это косвенно вытекает из приведенных цифр. И кстати, большое количество кэша на Итаниуме - это следствие недостатков VLIW, о которых я выше писал. Т.е. RISC/CISC здесь имеет преимущество, т.к. ему нужно меньший размер кэшей для достижение хорошей производительности - т.е. это опять-таки снижает энергоэффективность VLIW.
shcher
04.08.2021 19:13Большая проблема приведённой в статье таблицы — это перечисление характеристик конкретных выпущенных процессоров. Вы берёте конкретные модели и обобщаете их опыт на весь подход. Данные образцы отстают, но является ли это свойством архитектуры на базе VLIW? А как же вопрос затраченных на разработку ресурсов. Неудача гиганта уровня Intel заставляет задуматься, но весьма вероятно, что из-за отсутствия быстрого успеха они потом вкладывали в IA-64 меньше, чем в x86. А исходная неудача IA-64 — это, естественно, сумма факторов, недостатки VLIW в которой сыграли не в первую очередь.
Civil
04.08.2021 19:50+4Автор не упомянул еще и попытку Nvidia с их Denver и Carmel. Тоже, можно сказать, не очень удачную, так как они отказались на текущий момент от собственного vliw в пользу лицензированного arm
Armmaster Автор
04.08.2021 22:36+2Очевидно, что мне нужно было продемонстрировать проблему на каких-то конкретных примерах (и мне кажется, я привёл достаточно честное сравнение). Иначе бы данная статья превратилась бы в научную монографию в несколько сот страниц. Конечно, всегда можно сказать - "а вот на самом деле просто туда недостаточно вложились" и доказать или опровергнуть такой тезис будет практически невозможно. Но т.к. я достаточно много занимался разработкой компилятора под Эльбрус, то прекрасно понимаю, что проблемы VLIW достаточно фундаментальны. И данное мнение разделяют многие люди из индустрии. Собственно, в данной статье хотелось на каком-то базовом уровне проблемы осветить. Насколько получилось - судить читателям.
VarinskiyV
04.08.2021 18:30+1я думаю, что если они больше откроются для общества, то развитие пойдет гораздо быстрее
palex34
04.08.2021 18:35-2Огромное преимущество Эльбруса - его отлично оптимизированная логика. Пока на западе тупо гонялись за гигагерцами, у нас оптимизировали логику так, что процессор считает гораздо больше данных при меньшей частоте.
Armmaster Автор
04.08.2021 18:36+3На Западе гонялись за Гигагерцами и догнали их. А у Эльбруса с оптимизированной логикой не получилось, про то и статья
amartology
04.08.2021 18:47+1у нас оптимизировали логику так, что процессор считает гораздо больше данных при меньшей частоте
Вообще нет. Если бы все было так, как вы говорите, то «оптимизированную логику» можно было бы просто разогнать до той же частоты, что и плохую логику конкурентов, и получить огромное преимущество в производительности.Am0ralist
05.08.2021 15:49Если бы все было так, как вы говорите, то «оптимизированную логику» можно было бы просто разогнать до той же частоты, что и плохую логику конкурентов, и получить огромное преимущество в производительности.
Это вы про АМД и интеловские 5 ГГц? Ну, когда амд уже в zen2 вроде получал большую производительность при равных частотах, но проигрывал из-за 5 ГГц у интела?
Боюсь, у нас работают люди не уровня АМД...amartology
05.08.2021 17:17Ну пять — это, допустим, перебор, но до двух с половиной с полутора «оптимизированную логику» не должно составлять труда разогнать)
Am0ralist
05.08.2021 18:21Ну 16С вроде уже 2 ГГц на инженерном образце, при 16 ядрах на 16 нм (и 12 млрд тразисторов) — подозреваю, что таки тут ещё и вопрос в ТДП, и на 2,5 там все 200 ватт могло бы получиться.
Но в данном случая я чисто так, про то, что не всегда даже у ведущих разрабов одной компании получается наращивать частоту так же, как в другой, даже имея более производительную на такт логику (с другой стороны, ходили упорные слухи, что на 10 нм у интела тоже эти 5 ГГц никак не брались, а переобуться ещё и насчёт ГГц — окончательно все свои маркетинги похерить было)
Civil
04.08.2021 20:11+2Это не очень важно на самом деле. Что полезно - это сложность чипа, его энергопотребление и быстродействие, в целом баланс всех трёх этих параметров. Какой бы виртуозной ни была архитектура, если чип вышел сложный, жрущий и медленнее конкурентов, то обосновать его использование будет крайне непросто (мягко говоря)
SailorMax
12.08.2021 19:00Эта статья никак не связана с этой темой?
amartology
12.08.2021 20:03+4Вообще нет, но на примере этой статьи и видео можно хорошо заметить, чем взвешенное мнение отличается от предвзятой позиции, полной необоснованного бахвальства и многочисленных передергиваний.
Civil
12.08.2021 20:55+3Не просто передергиваний, а местами фактически неверной информации, притом выдаваемой не только автором видео, но и теми у кого он брал интервью.
tundrawolf_kiba
13.08.2021 00:12+1А если вы уже смотрели и не очень сложно — можете вкратце пересказать, о чем там вообще речь?
edo1h
13.08.2021 00:45+5основные утверждения:
- эльбрус — уникальная архитектура, которая обеспечивает непревзойдённую производительность на такт и у которой большое будущее, скоро все страны будут стоять в очереди за процессорами (нет, хотя бы в этой статье много написано);
- собственный дизайн процессора обеспечивает независимость от санкций (скорее нет; это только один из элементов, пусть и очень крутой, гигантского пазла, который не «работает» пока не собран целиком);
- использование процессоров собственной разработки — ключевой момент в обеспечении информационной безопасности (я не эксперт в безопасности, но считаю, что нет);
- risc-v — это низкопроизводительные процессоры, которые не смогут в обозримом будущем конкурировать с лидерами рынка и даже с эльбрусом (нет)
Civil
13.08.2021 02:08+4Довольно странный опус (с кучей самоповторений разными словами), о том что:
Россия - уникальная страна, одна из двух у кого есть свои архитектуры, и эту свою архитектуру "Эльбрус" душат, хотя у него большое будущее, все злые конкуренты (тут статья целая о том почему это не так и почему даже если дать много денег, убийцы интела не получится).
Новые правила импортозамещения в плане вычислительной техники неадекватны и позволяют читерить поставив пару российских светодиодов назвать сервер российским (не возьмусь судить, так как не читал оригиналы постановлений)
На risc-v есть только слабые процессоры для IoT, неспособные запустить линукс и вообще не более 450 МГц, а его прям сразу уже тянут в сервера (и это не так, у того же sifive'а есть платы заметно мощнее, да и даже у Syntacore пару лет назад были ядра в разы более мощные, чем там говорилось)
OpenSource сущее зло, потому что весь контролируется корпорациями, а значит не свободен, а если не контролируется, то убивает инженерную школу так как не позволяет определять курс (думаю очевидно, почему это не так и те кто так говорил не знают что такое OpenSource).
В общем и целом, автор выбрал довольно сомнительных экспертов, которые говоирил не всегда вещи, соответствующие реальности (тут не возьмусь судить, злой ли это умысел или незнание темы или их тоже ввели в заблуждение), соотвественно и все видео соответствующее по качеству.
amartology
13.08.2021 08:32Лучшая часть: «приказ 66 в star wars — это о ссылка к приказу 66 Совмина СССР об отказе от собственных архитектур компьютеров и копированию западных». Остальное видео в целом примерно того же уровня.
Автор не отличает архитектуру от системы команд, а систему команд от микроархитектуры.
ptr128
02.09.2021 22:15-1Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением.
Не все с этим согласны. У ребят получилось совсем наоборот. Выигрыш VLIW от 1.2 до 1.57 раз против пятиступенчатого конвеера на, по сути, одной и той же архитектуре RISC-V.Brak0del
03.09.2021 10:16+2У ребят получилось совсем наоборот.
Не все согласятся, что получившееся у ребят является VLIW.
Во-первых, здесь имеется динамическое планирование (см. Scheduler).
Во-вторых, динамическое разруливание конфликтов по данным (см. Hazard Unit).
В-третьих, а чем этот процессор принципиально отличается от multiple-issue superscalar?
В-четвертых, а кто из этих малюток RISC-V, с которыми они сравнивают, является Out-of-Order? Гугл утверждает, что Kronos и NeoRV32 являются in-order, а PicoRV32 вообще не конвейеризированный, DarkRiscV имеет трехстадийный конвейер, так что тоже без OoO.
ptr128
03.09.2021 10:46Прочитайте статью, пожалуйста, прежде чем отвечать. Некрасиво получатеся.
здесь имеется динамическое планирование
«implementing a VLIW architecture based on that ISA is the lack of a powerful compiler to schedule original instructions in accordance with the VLIW instruction format»
«We design a simple instruction scheduler to exploit the parallelism potential of sequentially original instructions dynamically.»
Если коротко и по-русски, то они реализовали динамическое планирование в связи с отсутствием компилятора, который должен был бы осуществлять статическое планирование.кто из этих малюток RISC-V, с которыми они сравнивают
Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.
Как раз тем это исследование меня и заинтересовало, что тут сравниваются процессоры с одинаковой (насколько это вообще возможно) микроархитектурой. Тогда как все остальные стравнения суперскалярных CPU с VLIW были явно с разной микроархитектурой.Brak0del
03.09.2021 11:07Если коротко и по-русски, то они реализовали динамическое планирование в связи с отсутствием компилятора, который должен был бы осуществлять статическое планирование.
Если коротко и по-русски, то можно ли относить к VLIW архитектуру с динамическим планированием и динамическим разрешением конфликтов? Имхо, нет. Они в своей работе упоминают гибрид VLIW и Superscalar под названием DISVLIW. Вот это, пожалуй, оно и есть.
Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.В исходном комменте, вы ссылаетесь на эту статью, утверждая, что не все согласны, что VLIW уступает в производительности ОоО CISC/RISC. Между тем, в статье нет сравнения с ОоО-архитектурами. Следовательно, ссылка не состоятельна, она не демонстрирует выигрыша VLIW против ОоО. Это не значит, что вы не правы, просто эта статья не подтверждает этого никак.
ptr128
03.09.2021 11:15можно ли относить к VLIW архитектуру с динамическим планированием и динамическим разрешением конфликтов
Боюсь, это риторический вопрос. У ребят просто не было выбора, так как написать компилятор для VLIW архитектуры слишком трудоемко. IMHO, это получилось очень хорошее приближение. Причем совершенно корректное, так как возможности оптимизации статического планирования в компиляторе намного выше, чем простейшего динамического на FPGA.нет сравнения с ОоО-архитектурами
Это только Ваше предположение. Такие подробности в статье опущены.Это не значит, что вы не правы,
Я могу быть не прав только посмев разместить ссылку на статью? Лично я до сих пор вообще ничего не утверждал, кроме констатации факта, что есть статья со следующими выводами. Вы о чем вообще?Brak0del
03.09.2021 11:23Это только Ваше предположение. Такие подробности в статье опущены.
Там приводится сравнение в производительности с процессорами, которые не являются ОоО, о чём я писал выше.
Причем совершенно корректное, так как возможности оптимизации статического планирования в компиляторе намного выше, чем простейшего динамического на FPGA.
Это не совсем так и много раз обсуждалось выше. Приближение не очень, т.к. динамическому планировщику видна занятость ресурсов в динамике, статическому она видна не всегда и ему приходится принимать консервативные решения, просаживая производительность.
ptr128
03.09.2021 11:35Там приводится сравнение в производительности с процессорами, которые не являются ОоО, о чём я писал выше.
Я этого не вижу. Процитируйте, пожалуйста. Мы вообще об одной и той же статье говорим?обсуждалось выше [...] динамическому планировщику видна занятость ресурсов в динамике
Обсуждать можно сколько угодно. А экспериментальных измерений на одном и том же FPGA я не видел. Опять жду пруфа.Brak0del
03.09.2021 12:11Я этого не вижу. Процитируйте, пожалуйста. Мы вообще об одной и той же статье говорим?
Табличка сравнения из вашей статьи: https://ieeexplore.ieee.org/mediastore_new/IEEE/content/media/6287639/8948470/9200617/nguye.t4-3024851-large.gif
По ссылкам можно убедиться, что ни один из них не ОоО.
Обсуждать можно сколько угодно. А экспериментальных измерений на одном и том же FPGA я не видел. Опять жду пруфа.
В качестве экспериментального пруфа ограничусь упоминанием того, что большинство современных General Purpose процессоров являются суперскалярами с ОоО, а не VLIW. Если бы на статике можно было далеко уехать, на ней бы уезжали и не городили динамический огород.
ptr128
03.09.2021 12:27Табличка сравнения из вашей статьи
Вы явно статью не читали. Табличка служит, в первую очередь, для сравнения их суперскалярного ядра с прочими.
При этом они явно пишут:
«However, our design recognizes a few tradeoffs. First, as stated in the Synthesis Results section, the instruction scheduler consumes substantial hardware utilization. The instruction scheduler is simple to utilize less hardware than other modules. Second, scheduling eight sequential instructions from the fetch stage requires one extra clock cycle for each scheduling turn. This requirement increases program execution time, indicating that IPC is slightly degraded. Our VLIW core still achieves higher IPC compared with existing open-source RISC-V cores at the expense of hardware resource, as presented in Table 4.»В качестве экспериментального пруфа
По точно такой же логике автомобиль с ДВС намного лучше электромобиля. При том, что электромобилям больше лет, чем ДВС )
Пока высказывание не подтвержденго экспериментально, оно может быть не более, чем гипотезой.Brak0del
03.09.2021 12:41+1Вы явно статью не читали. Табличка служит, в первую очередь, для сравнения их суперскалярного ядра с прочими.
Простите, но там указаны оба их ядра, и их не-VLIW ядро ни разу не суперскалярное, с IPC-то ниже единицы и single-issue.
ptr128
03.09.2021 12:53-1Пруф? Я не понимаю ход Вашей логики.
С чего Вы взяли, что их ядро не поддерживает параллелизм на уровне инструкций. Что-то мне подсказывает, что без этого оно проиграло бы VLIW в разы, а не в десятки процентов. Или Вы пользуетесь иным определением суперскалярности?
qw1
03.09.2021 12:15+2Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
То есть, они взяли своё ядро, без OoO, без всяких плюшек «больших» процессоров (типа переименования регистров), с 5-ступенчатым конвеером, и стали думать, как его ускорить. Сделали инструкцию в 8 раз шире и получили прирость 20-50%. Ну разумеется, какой-то прирост они должны были получить в ответ на увеличенный транзисторный бюджет. Но это не даёт ответа на главный вопрос: а какой бы они прирост получили, если бы пошли не в сторону VLIW, а в сторону мейнстрима: длиннее конвеер, горизонт декодирования команд на 300 шагов вперёд, спекулятивное выполнение, предсказание ветвлений, OoO.
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.
Как раз тем это исследование меня и заинтересовало, что тут сравниваются процессоры с одинаковой (насколько это вообще возможно) микроархитектурой
Это и было бы аргументом в ответе на вопросVLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением
А не то, что они сделали.ptr128
03.09.2021 12:31-2они взяли своё ядро, без OoO
Есть ли в их ядре OoO или нет — я не знаю. Дайте пруф, откуда Вы это взяли, пожалуйста.не даёт ответа на главный вопрос: а какой бы они прирост получили, если бы пошли не в сторону VLIW, а в сторону мейнстрима
Да, я не вижу ответа на этот вопрос ни в этой статье, ни в какой-либо другой. А мой уровень навыков работы с FPGA не позволяет провести такой эксперимент. То бишь, вопрос остается открытым.amartology
03.09.2021 12:37+2Дайте пруф, откуда Вы это взяли, пожалуйста.
Вам выше дали пруф того, что ни одно из использованных в статье открытых ядер не имеет OoO. Или вы решили проигнорировать набор ссылок?ptr128
03.09.2021 12:48-1Вам выше дали пруф того, что ни одно из использованных в статье открытых ядер не имеет OoO
Я не понимаю Вашу логику. То есть, исходя из того, что четыре ядра в таблице не OoO, Вы делаете вывод, что пятое тоже не OoO?
Я по прежнему жду пруф на то, что именно дизайн суперскалярного ядра выполненого авторами статьи на FPGA не является OoO.Brak0del
03.09.2021 12:55+2Я по прежнему жду пруф на то, что именно дизайн суперскалярного ядра выполненого авторами статьи на FPGA не является OoO.
Пруф в том, что их ядро имеет singe-issue в названии, за такт выдается на исполнение не более одной инструкции, и количество инструкций за такт (IPC) меньше единицы. У суперскаляра оно > 1 и multiple issue.
ptr128
03.09.2021 13:01-1Спасибо. С этим утверждением согласен. Параллельно у них выполняются пять инструкций, но без OoO.
Но их издержки («scheduling eight sequential instructions from the fetch stage requires one extra clock cycle for each scheduling turn») тоже следует учитывать.
Не считая того, что компилятор может позволить себе менять порядок выполнения инструкци в почти неограниченном горизонте, чего не скажешь про аппаратный OoO планировщик.qw1
03.09.2021 13:26Мне бы не хотелось приобрести процессор, у которого производительность заявлена на 500 попугаев, в реальности он выдаёт только 100, потому что «очень сложно написать компилятор». И у этих ребят из статьи так и получилось. Выходит, что проблемы с компиляторами это особенность VLIW и её нельзя игнорировать.
qw1
03.09.2021 13:23+1Да, я не вижу ответа на этот вопрос ни в этой статье, ни в какой-либо другой
Хорошо, тогда зачем на этот вопрос вы ответили: «У ребят получилось совсем наоборот» со ссылкой на статью. Может, вы что-то другое имели ввиду, но прозвучало так, что вы нашли в статье отрицательный ответ, и вам бросились все доказывать, что в статье нет ответа.ptr128
03.09.2021 15:21Я имел в виду только то, что утверждение
VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением
является ГИПОТЕЗОЙ. И строго оно НЕ ДОКАЗАНО.qw1
03.09.2021 16:32Ссылка на статью сбивает с толку. Зачем она, если не подтверждает и не опровергает оспариваемое утверждение.
ptr128
03.09.2021 18:10Она напрямую оспаривает утверждение, переводя его в статус гипотезы, а вовсе не доказанного факта.
Я нисколько не исключаю, что эта гипотеза верна. Так же, как физики не исключают правильность стандартной модели элементарных частиц, при этом отдавая себе отчет, что это лишь гипотеза, описывающая текущие знания. Из чего совершенно не следует, что завтра результаты какого-то эксперимента не потребуют пересмотра или кардинальной ревизии этой стандартной модели. Следует признать, что такое уже не раз случалось.Brak0del
03.09.2021 18:31+1Она напрямую оспаривает утверждение, переводя его в статус гипотезы, а вовсе не доказанного факта.
Так в статье же нет ОоО, а гипотеза/утверждение про ОоО.
ptr128
03.09.2021 18:52+1Вы можете доказать, что OoO даёт больший прирост производительности, чем явное параллельное выполение N операций в VLIW? Особенно на сравнимом количестве транзисторов на кристалле и максимально схожей микроархитектуре. Я таких экспериментальных доказательств не видел.
А вот в истории уже была конкуренция между IA-64 (VLIW) и x86-64. И основным фактором проигрыша IA-64 считается вовсе не производительность.
edo1h
04.09.2021 00:24И основным фактором проигрыша IA-64 считается вовсе не производительность.
а что же? вот гуглоперевод из немецкой википедии:
Performance comparison with Power7 and Xeon
According to measurements ("benchmarks") from 2010 with Itanium 9350, the CPU is clearly behind the current Power7 family from IBM and also behind the current Xeon CPUs in the SPEC comparison of the CINT 2006 rate and the CFP 2006 rate from Intel (for better comparability, the Power7 test results were standardized to 8 computing cores [2] ).HP Integrity BL860c i2 (1.73 GHz / 24 MiB Quad-Core Intel Itanium 9350 ): CINT-2006 rate: 134; Cores: 8; CPUs: 2; Date: March 2010
HP Integrity BL860c i2 (1.73 GHz / 24 MiB Quad-Core Intel Itanium 9350 ): CFP-2006 rate: 136; Cores: 8; CPUs: 2; Date: March 2010
IBM BladeCenter PS702 Express ( Power7, 3.0 GHz, 8 core estimated): CINT 2006 rate: 260; Cores: 8; CPUs: 1; Date: April 2010
IBM BladeCenter PS702 Express ( Power7, 3.0 GHz, 8 core estimated): CFP-2006 rate: 215; Cores: 8; CPUs: 1; Date: April 2010
Fujitsu PRIMERGY BX620 S5 (Intel Xeon E5540, 2.53 GHz): CINT-2006 rate: 214; Cores: 8; CPUs: 2; Date: September 2009
Fujitsu PRIMERGY BX620 S5 (Intel Xeon E5540, 2.53 GHz): CFP-2006-Rate: 166; Cores: 8; CPUs: 2; Date: September 2009
ptr128
04.09.2021 00:53Вики, как всегда, в своем репертуаре. Сравнение 65нм с 45нм. Ну так и без указания архитектур и процессоров было изначально понятно, что 45нм техпроцесс выиграет у 65нм )))
edo1h
04.09.2021 02:40производительность на гигагерц у зиона оказалась выше.
разве техпроцесс позволяет улучшить IPC?
edo1h
04.09.2021 02:44+1является ГИПОТЕЗОЙ. И строго оно НЕ ДОКАЗАНО.
ИМХО это демагогия. строго не доказано и что человек не может полететь просто усилием мысли.
Armmaster Автор
03.09.2021 13:48+3Вам собственно уже ответили, но на правах автора резюмирую.
Эти ребята мечтают о PhD и высоком индексе Хирше, поэтому им необходимо писать статьи. Пятиступенчатый single-issue конвейер - это классика от Паттерсона из начала 80-х. После этого индустрия столкнулась с проблемами роста производительности такого подхода, стала популярна идея VLIW и 90-ые ознаменовались попытками сделать хорошие чипы на базе такой архитектуры, столкнулись с проблемами, которые я в статье упомянул, а потом просто в итоге был сделан ОоО где-то в начале 2000-х и вопрос с тех пор по сути закрылся.
Т.е. данная статья не имеет отношения к моему утверждению. Они сравнивались с простейшим in-order чипом, а у меня речь о современных ОоО процессорах.
ptr128
03.09.2021 15:17В данной статье высказано достаточно обоснованное мнение, что VLIW рано хоронить. Не более того.
Мне никаких ссылок на иные экспериментальные исследования не привели. А толкать гипотезы — это явно в стиле демагогии, а не технической дискуссии.
Лично меня никто не убедил, что OoO на этапе компиляции (не ограниченный по глубине, теоретически, ничем) хуже, чем OoO аппаратный (всегда ограниченный длиной конвеера).
На сегодня имеем откровенно финансовую проблему VILW — стоимость компиляторов для них существенно превышает стоимость аппаратного решения OoO. Потому что компилятор для каждого ядра надо писать свой.
А если завтра появятся средства автоматизации написании эффективно оптимизирующих компилятров для VLIW хотя бы из LLVM, то все гипотезы будут или подтверждены, или опровергнуты экспериментами. Куда более дорогими и качественными, чем уже произведенные.Armmaster Автор
03.09.2021 15:40+3В статье высказано лишь то, что можно сделать VLIW лучше, чем single issue in-order процессор. А мы говорим про OoO процессоры. Это совершенно разные вещи.
Что касается экспериментальных исследований и т.д. Они все давно проведены. Результатом является результаты на бенчмарках VLIW архитектур и современных OoO процессоров. Можете взять цифры Spec'ов от МЦСТ, потом зайти на spec.org и посмотреть на результаты современных процов. Даже если мы отнормируем на частоту, разница там будет в разы для single thread performance.
ptr128
03.09.2021 16:07Можете взять цифры Spec'ов от МЦСТ
Ну пожалуйста, не надо демагогии. Оптимизация для Эльбрусов ныне на уровне плинтуса.
Например:
«Обход элементов списка представляет собой цикл с рекуррентностью (зависимостью между итерациями) вида p=p->next, иными словами, адрес, по которому производится чтение на текущей итерации, зависит от результата чтения на предыдущей итерации.
При таком обходе темп перебора элементов списка не превышает 1 элемент на время доступа в L1$. Например, для процессора Е8С этот темп в 24 раза (!) меньше максимально возможного»
Каким образом можно проводить эксперименты, если уже доказано, что эффективность оптимизации компилятором для Эльбрусов существенно уступает любому конкуренту?amartology
03.09.2021 16:15+1Каким образом можно проводить эксперименты, если уже доказано, что эффективность оптимизации компилятором для Эльбрусов существенно уступает любому конкуренту?
А сложности с компилятором — это тоже принципиальное свойство VLIW и плата за упрощение хардвера. Так что тут все честно.ptr128
03.09.2021 17:52Что честно? То что сейчас, пока сложности с компилятором не имеют рентабельных методов решения, VLIW проигрывает? А с этим разве кто-то спорит?
Но я уже приводил пример выше с ДВС и электромобилями. Вы в XX веке тоже утверждали бы, что электромобили нужно похоронить? )))
Armmaster Автор
03.09.2021 16:18+1Вы вообще уже не понимаете, что пишете. Данный абзац просто описывает проблему зависимости инструкций чтения друг от друга при обходе списка. И о сложностях для Эльбруса в таких случаях. Качество компилятора тут совершенно непричём. На x86 в gcc будет то же самое (просто x86 сгладит проблемы ввиду наличия продвинутой микроархитектуры с префетчем аппаратным)
Собственно, вы сейчас пытаетесь уйти куда-то в сторону. Я вам по существу ответил. Если вас ответ не устраивает- это уже не ко мне.
ptr128
03.09.2021 17:55Отлично понимаю. По ссылке утверждается, что продвинутый компилятор, благодаря поддержке в Эльбрус спекулятивных операций с отложенным прерыванием, вполне мог бы выполнить обход списка в 24(!) раза быстрее, чем текущая реализация.
Где я ухожу в сторону?Armmaster Автор
03.09.2021 18:10+1Там нет такого утверждения, это вы выдумали.
Это принципиально неразрешимая ситуация, т.к. у вас каждый следующий лоад зависит от предыдущего (вам нужно дождаться адреса, по которому считывать следующий элемент списка). Тут не поможет ни компилятор, ни ОоО.
Спекулятивные операции имеют несколько другую цель. Но давайте я тут не буду устраивать лекции по архитектуре e2k. В конце концов, для этого есть сотрудники МЦСТ, можете у них проконсультироваться.
ptr128
03.09.2021 18:27Это принципиально неразрешимая ситуация, т.к. у вас каждый следующий лоад зависит от предыдущего
Если не знаете, зачем утверждать? Вот я могу утверждать, что рекурсивные запросы к БД (а ведь это и есть по сути обход по списку!) нередко оптимизируются на порядок, а то и два, по сравнению с подходом «в лоб». Для примера, hierarchyid тип данных в MS SQL.Armmaster Автор
03.09.2021 19:03Я знаю, потому и утверждаю. Если вы не понимаете сути предмета - это ваши проблемы.
qw1
03.09.2021 19:26Ясно, понятно. Если для вас не очевидно то, о чём написал комментатор выше, думаю, мы не придём к консенсусу.
ptr128
03.09.2021 19:36+1Ну зачем Вы так? Или Вы не в курсе, что слово «очевидно» является ключевым признаком демагогии и потому в технических дискуссиях не может употребляться?
ptr128
03.09.2021 18:30x86 сгладит проблемы ввиду наличия продвинутой микроархитектуры с префетчем аппаратным
Спекулятивные операции имеют несколько другую цель
Вы утверждаете, что спекулятивные операции не могут выполнять функции префетча?Armmaster Автор
03.09.2021 20:47"Спекулятивных операций с отложенным прерыванием" - о которых вы тут написали, это совсем иное, чем префетч. И префетч - это отдельный вопрос. Перестаньте заниматься демагогией.
ptr128
03.09.2021 21:35С какого перепугу это не предзагрузка?
«Встроенная функция __builtin_prefetch() позволяет заблаговременно подкачать данные в кэш-память. Подкачивается целая порция кэш-строк — 64 байта.»
«При использовании __builtin_prefetch() в ассемблере можно увидеть спекулятивное чтение, но не в регистр назначения, а в empty»Перестаньте заниматься демагогией.
Жду извинений.
qw1
03.09.2021 23:25-2Здесь в документации термин «спекулятивное чтение» применён ошибочно. Спекулятивное — значит, процессор делает эту операцию до того, как станет известно, нужна ли она, в предположении, что операция будет нужна.
__builtin_prefetch() же генерирует обычную инструкцию чтения, которая выполняется в своём порядке появления в коде. С какого перепугу это чтение «спекулятивное»?
ptr128
03.09.2021 23:44+1По определению в словаре
Базируется на предположении.Спекулятивное — значит, процессор делает эту операцию до того, как станет известно, нужна ли она, в предположении, что операция будет нужна
«6.4.3. Спекулятивный режим
Для повышения параллелизма на уровне операций часто бывает полезно начать выполнять операцию до того, как станет известно, нужно ли было выполнять эту операцию. В случае, если операция может привести к прерыванию (например, чтение из памяти по недопустимому адресу, или деление на 0), такое преждевременное исполнение может привести к некорректному аварийному выходу из программы. Для того, чтобы решить эту проблему, в архитектуре «Эльбрус» допускается выполнение операций в режиме отложенного прерывания, также называемом спекулятивным режимом исполнения операции.»
Вы, похоже, не понимаете идеологии VLIW. Одна машинная команда уже содержит в себе N инструкций. И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно сделать что то из предположения (speculative). Например, загрузить блок данных в кэш.
qw1
04.09.2021 01:17Зачем вы процитировали кусок мануала спекулятивного режима, когда речь о prefetch?
И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно сделать что то из предположения (speculative). Например, загрузить блок данных в кэш
О какой загрузке вы тут говорите? Откуда должен взяться адрес для загрузки?
ptr128
04.09.2021 02:21-1Потому что в VLIW предварительная выборка реализуется именно спекулятивным выполнением команд. В частном случае — загрузкой в кеш блока при указании целевого регистра empty.
qw1
04.09.2021 11:18Про адрес вы вопрос проигнорировали, а он был важным, чтобы вы разобрались, какую нелепость пытались выдать о простое исполнительного блока.
Потому что в VLIW предварительная выборка реализуется именно спекулятивным выполнением команд. В частном случае — загрузкой в кеш блока при указании целевого регистра empty
Очень интересно. __builtin_prefetch() компилируется в обычную команду чтения памяти ld.s
По вашему, любое явное чтение памяти можно назвать спекулятивным, или только чтение в регистр empty?
ptr128
04.09.2021 12:30-1Про адрес вы вопрос проигнорировал
Я счел его риторическим. Я думал и так понятно, что адрес будет содержаться либо в коде программе, либо находиться в регистре, если он вычисляется в ходе исполнения программы.компилируется в обычную команду чтения памяти
Нет, конечно. В команду спекулятивного чтения, что я и процитировал выше. Мало ли, вдруг содержимое регистра, содержащего этот адрес все же изменится в ходе исполнения программы, а текущее содержимое содержит некорректный адрес. Это не должно приводить к аварийному завершению программы.
qw1
04.09.2021 13:58Я пытаюсь указать вам на ошибку в этом заявлении:
Вы, похоже, не понимаете идеологии VLIW. Одна машинная команда уже содержит в себе N инструкций. И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно сделать что то из предположения (speculative). Например, загрузить блок данных в кэш
Идеология явного планирования такова, что на все операции в ширикой команде (ШК) хватает исполнительных блоков, за этим следит компилятор, когда компонует инструкции в широкую команду. Одна из этих команд — загрузка данных для prefetch. Тут нет никаких «если», все инструкции ШК начинают выполняться одновременно.
ptr128
05.09.2021 01:01Как это никаких «если», когда именно этим руководствуется компилятор формируя широкую команду из N инструкций? Если можно выполнить спекулятивную операцию — хорошо. Если и это не возможно, то какие-то из N операций вообще окажутся NOP.
qw1
05.09.2021 10:02вы же пишете
Одна машинная команда уже содержит в себе N инструкций. И если в текущий момент исполнения программы не все N инструкций можно выполнить, вместо простоя исполнительного блока можно… например, загрузить блок данных в кэш
Нельзя вместо простоя исполнительного блока выполнить то, чего нет в ШК. А исполнительных модулей на все инструкции ШК точно хватает, об этом позаботился компилятор.
ptr128
05.09.2021 13:01И в чем противоречие? Почему на этапе компиляции нельзя предусмотреть выполение вместо простоя спекулятивной операции?
А исполнительных модулей на все инструкции ШК точно хватает, об этом позаботился компилятор.
По ссылке, которую я приводил выше, даже примеры есть детальные, когда для конкретного кода ширина команды избыточна и востребована спекулятивная операция. Причем дающая существенный прирост производительности. Прочто читайте пруфы и не будете позориться публично, как сейчас.
qw1
05.09.2021 16:31Об этом я писал выше, что мы никогда не придём к консенсусу. Для меня ясно, что вы не разбираетесь в предмете, выдёргиваете рандомные ссылки, чтобы лишь бы что-то ответить и не потерять лицо (перед кем?). Вам же кажется, что то же самое я делаю. Предлагаю на этом закончить.
ptr128
05.09.2021 17:36-1Если при обуждении Эльбрус Вы отказываетесь даже почитать его документацию, гордо утверждая, что она ошибочная и Вы лучше знаете Эльбрус и VLIW, чем его разработчики — это, IMHO, диагноз )
qw1
03.09.2021 16:37Ну пожалуйста, не надо демагогии. Оптимизация для Эльбрусов ныне на уровне плинтуса.
Очень интересно. Вы говорили, что проблема VLIW в компиляторах. Вы ожидаете, что появится компилятор, который самостоятельно заменит односвязный список на массив и перепишет алгоритмы? И тогда VLIW себя покажет…
Например:
«Обход элементов списка представляет собой цикл с рекуррентностью (зависимостью между итерациями) вида p=p->nextptr128
03.09.2021 17:56Я ничего не ожидаю. Я этого не исключаю, пока не доказано обратное. Разницу замечаете?
А вот многие здесь утвердают то, что НЕ ДОКАЗАНО, а является лишь гипотезой. Разницу замечаете?qw1
03.09.2021 20:03-1Кстати, эту гипотезу несложно доказать, если она верна.
Берёте и вручную пишете код, который на эльбрусе ускорит обход списка в 24 раза, раз компилятор не справляется. Если вы не умеете в ассемблер, можете поискать непредвзятого спеца, который разбирается и спросить, представляет ли он хотя бы теоретически, как такое сделать.ptr128
03.09.2021 20:16+1Я не собираюсь тут доказывать какие-либо гипотезы. Я призываю только не возводить гипотезы в ранг доказанных теорем или экспериментально подтвержденных теорий.
edo1h
03.09.2021 16:57-2Лично меня никто не убедил, что OoO на этапе компиляции (не ограниченный по глубине, теоретически, ничем) хуже, чем OoO аппаратный (всегда ограниченный длиной конвеера).
- OoO на этапе компиляции ограничен возможностями предсказания. если процессор оптимизирует «по факту», то компилятор этого сделать не может.
запустили код на машине с другими таймингами памяти — и как это это сможет учесть компилятор? да или просто сегодня на соседнем ядре работает задача, которая вымывает l3-кэш, тайминги обращения к памяти «съехали», заранее оптимизированный VLIW-код будет страдать; - как скрестить VLIW и SMT?
тут уже говорили, что многие задачи сами по себе не особо параллелизуются, что с ОоО в процессоре, что с VLIW-компилятором IPC получается низким. SMT может кардинально улучшить ситуацию, при этом есть слухи, что скоро в x86 появится SMT4 (у в powerpc ЕМНИП и SMT8 давно есть).
qw1
03.09.2021 17:17-1Ладно там другие тайминги, код можно перекомпилировать при замене оборудования.
Что делать с тем, что предсказатель суперскаляра подстраивается под обрабатываемые данные и, если сжимаем архиватором файл из нулей, через несколько десятков/сотен итераций процессор подстроится под данные.
Тут обычно говорят про PGO, но это значит, что разработчик должен профилировать код ровно на тех данных, которые есть у клиента. А если характер данных меняется, кто будет код перекомпилировать…ptr128
03.09.2021 18:02+1если характер данных меняется, кто будет код перекомпилировать
На SQL серверах эту проблему ведь смогли решить, адаптируя компиляцию запросов на лету, в соответствии с текущими статистиками. Я ни в коем случае не пытаюсь утверждать, что и тут именно такой подход даст плоды. Я только указываю на то, что мы просто не знаем сейчас всех возможных методов оптимизации VLIW. Слишком мало эта проблема изучалась в научных кругах, по причине низкой востребованности вплоть до настоящего времени.qw1
03.09.2021 19:36+1Я понимаю, что вы не хотите окончательно ставить крест на VLIW, пока нет строго формального доказательства, что он тупиковый путь. Опыт, примеры из индустрии — ничего не доказывают формально. Нужно продолжать пытаться, вкидывать миллиарды денег и всё такое, а вдруг взлетит, так? А за чей счёт банкет, вас не волнует.
ptr128
03.09.2021 19:42Не ставить крест и финансировать развитие — это очень разные вещи. Опять по примеру выше. Сначала появились электромобили и только через несколько десятков лет — автомобили с ДВС. Следует ли считать, что это поставило крест на электромобилях? Или все же это было временным явлением?
Под «не ставить крест» я имею в ввиду примерять новые научные и инженерные разработки к VLIW, проверяя, не смогут ли они обеспечить кардинальный толчок развития для него.amartology
03.09.2021 19:54+2Под «не ставить крест» я имею в ввиду примерять новые научные и инженерные разработки к VLIW, проверяя, не смогут ли они обеспечить кардинальный толчок развития для него.
Это вполне можно делать в рамках малобюджетных университетских RnD, а не в рамках дорогостоящего серийного производства и принудительного внедрения продуктовых чипов. Нормальный и принятый во всем мире путь — университеты разрабатывают новые подходы и прикидывают их эффективность, а потом все самое лучшее забирается индустрией и коммерциализируется.ptr128
03.09.2021 20:07Можно. Но опять, обращаясь к примеру с электромобилями и автомобилями с ДВС, хочу обратить внимание, что электромобили последние полтора века производились серийно. Просто долгое время имели довольно узкую нишу (электрокары, электропогрузчики и т.п.). То есть, сто лет назад Вы бы призывали вообще отказаться от серийного производства электромобилей в пользу автомобилей с ДВС?
«Нормальный и принятый во всем мире путь» — это коммерческий риск. Чем больше возможная прибыль, тем выше вероятность провала. Тот же VLIW не раз коммерциализировлся (Transmeta, IA-64, некоторые GPU). Я слишком плохой коммерсант, чтобы давать рекомендации об опраданности рисков. Но успешные рисковые разработки в IT не редкость. Так же как и провальные.qw1
03.09.2021 20:12Просто долгое время имели довольно узкую нишу (электрокары, электропогрузчики и т.п.). То есть, сто лет назад Вы бы призывали вообще отказаться от серийного производства электромобилей в пользу автомобилей с ДВС?
Никто не призывает забыть VLIW, он себя коммерчески успешно показывает в DSP. Речь тут о GP CPU, то бишь ниша автомобилей на общественных дорогах.
ptr128
03.09.2021 20:22Опытные электромобили для общественных дорог разрабатывались регулярно различными производителями все последние полтора века. И у меня почему то есть уверенность в том, что результаты этих разработок оказались в итоге востребованы в последствии. Вы считаете иначе?
Эльбрус и в СХД показывает себя совсем неплохо. Вполне могу представить его востребованность для специфичных серверных задач. А вот для десктопа он явно сейчас проигрывает. На настоящий момент для десктопа я обеими руками за RISC-V.
qw1
03.09.2021 20:27-1В СХД не нужны процессорные мощности. Поэтому туда может подойти и RISC-V, чтобы увеличить объём партии и уменьшить себестоимость. Вывод: Эльбрусы в СХД не нужны.
ptr128
03.09.2021 21:20+1В СХД не нужны процессорные мощности.
Это идиоты Intel® Xeon® E5-2697-v4 18 core processors в СХД ставят? Или Вы все же погорячились? )))
ptr128
03.09.2021 21:53+2Производители СХД достаточно консервативны. Уверяю Вас, не пройдет и двух-трех лет, как и эти CPU Вы увидите в СХД. На данный момент требования клиентов к производительности СХД заметно превышают возможности их производителей.
amartology
03.09.2021 20:45-1«Нормальный и принятый во всем мире путь» — это коммерческий риск.
Поэтому такого рода вещи и поручают университетам: они могут развивать даже ошибочные теории до момента, пока не станет ясно, работает, или нет, не неся при этом финансовых потерь.
А потом успешные идеи коммерциализируются.
ptr128
03.09.2021 21:24+2Вы вообще читаете, что я пишу?
Опытные электромобили для общественных дорог разрабатывались регулярно различными производителями все последние полтора века. И у меня почему то есть уверенность в том, что результаты этих разработок оказались в итоге востребованы в последствии. Вы считаете иначе?
Ответьте на прямой вопрос. Без демагогии. Или проведем анализ, сколько опытных автомобилей за эти полтора века было произведено университетами, а сколько производителями?
Вы явно путаете фундаментальные исследования с отработкой технологии.
amartology
03.09.2021 22:04-3Или проведем анализ, сколько опытных автомобилей за эти полтора века было произведено университетами, а сколько производителями?
Сколько опытных материалов для аккумуляторов было разработано в университетах, а сколько — автопроизводителями?
ptr128
03.09.2021 22:14+2Если Вы не демагог, то ответьте сначала на мой вопрос, который Вы уже дважды проигнорировали. В противном случае прощаюсь.
amartology
04.09.2021 00:07Разумеется, прототипы автомобилей в основном разрабатывают автоконцерны, тут с вами нельзя не согласиться.
Но вы привели неверную аналогию, о чем я и написал сообщением выше. Верная аналогия фундаментальных микроархитектурных исследований — не менее фундаментальные материаловедческие исследования, а не прототипы авто.
qw1
03.09.2021 21:27+1По такой логике, все языки программирования должны создаваться исключительно в университетах. Но на практике, Mozilla, Google, Microsoft, JetBrains — все что-то изобретают и пытаются ввести это в продакшн.
amartology
03.09.2021 21:52-2Язык программирования — это аналог прототипа автомобиля или прототипа процессора. Наш же разговор начался с исследования того, можно ли ускорить VLIW. Такого рода исследования в нормальной ситуации — удел университетов или специальных RnD отделов в коммерческих компаниях. Но никак не хорошее место для многолетней проверки одной новой идеи прямо в продакшене.
qw1
03.09.2021 19:56+1Если продолжать аналогию с электромобилями, попытки толкать сейчас VLIW в серию, всё равно что выпускать и продавать электромобили в 1980-х.
Оно должно вызреть и когда дозреет, само всплывёт наверх и станет модной хайповой темой. Может, до расцвета VLIW надо подождать ещё 20 лет, а может 50 или 500.ptr128
03.09.2021 20:11выпускать и продавать электромобили в 1980-х.
Но это же делали! Просто электромобили имели довольно узкую нишу в виде электрокаров и электропогрузчиков. И если бы это не делали, то нынешний рывок производства электромобилей мог и не состояться, а растянуться еще на долгие десятилетия.edo1h
04.09.2021 02:50+1Просто электромобили имели довольно узкую нишу в виде электрокаров и электропогрузчиков. И если бы это не делали, то нынешний рывок производства электромобилей мог и не состояться, а растянуться еще на долгие десятилетия.
вот именно, что электрокары делали потому, что это было выгодно, а не чтобы доказать перспективность электротранспорта.
то же самое и с vliw — оно используется там, где оно уместно. и ещё в эльбрусе.
- OoO на этапе компиляции ограничен возможностями предсказания. если процессор оптимизирует «по факту», то компилятор этого сделать не может.
abondarev
Спасибо за статью. Есть пара добавлений или комментариев.
Начну с несолгасия. Думаю, что для некоторых серверных задач, Эльбрус (VLIW) вполне подходит. Конечно в общем случае своя архитектура более затратна, по приведенным вами причинам, но Itanium занимал свою серверную нишу. И в качестве развития, интересной архитектуры, это может сработать. Еще одна, очень хорошая ниша, это DSP обработка, например TI имеет свою VLIW архитектуру для DSP ядер, и на этих задачах (числодробилка) VLIW может дать фору и CISC и RISC. Но тогда да, нужно отказываться от бинарной трансляции и упрощать сам кристалл.
Замечание по проблем работы с памятью дополню тем что все еще более сложно, ведь когда происходит прерывание, нужно как то завершить текущие операции памяти, и если их несколько и они в разных адресах (не в одной линейке) то это требует освобождать конвеер и так далее. То есть да, модель работы с памятью для VLIW не эффективна для процессоров общего назначения.
Ну и по поводу экосистемы, без которой не возможно развить конкурентоспособный продукт. Да, Elbrus Tech Day это был прорыв, и открытие описания команд тоже, но это все настолько закрыто, что данные вещи это капля в море.
acc0unt
Оптимальные для VLIW задачи - это специфика, под которую можно и нужно делать свои отдельные ядра. Со своими особенностями и своей архитектурой.
Собственно, именно это мы и видим на примере GPU и NPU. Задачи DSP в современных устройствах тоже решаются на отдельных ядрах - вроде тех же ядер на Hexagon (VLIW), на которых собираются модемы Qualcomm. Я могу поверить в будущее модифицированного Эльбруса как архитектуры для DSP-процессоров или иных ускорителей - но не в будущее Эльбруса как application processor.
А Itanium в серверном пространстве - это отдельная история. Идёт она от того, что несколько весьма крупных клиентов купились на обещания Intel, и сделали свои новые системы на Itanium. Вот только потом появился AMD64 (сейчас известный как x86-64) и всем вскоре стало ясно, что IA-64 не взлетает - но системы уже были сделаны и стали legacy. Поэтому Itanium в зомби-состоянии и продолжал существовать весьма долго. Только недавно его официально закопали, свернув линейку и обрубив поддержку.
abondarev
Да, я это имел в виду, когда сказал, что в этих ядрах нужно отказываться от бинарной трансляции и других вещей.
Про itanium, тоже частично согласен. Но я имел в виду, что в этой сфере можно найти сегмент где будет достаточно эффективен VLIW и если речь идет об поддержке и развитии архитектуры (я лично считаю что так и нужно делать) то это один из возможных вариантов
Armmaster Автор
Скажем так, на некоторых серверных задачах недостатки Эльбруса становятся минимальными, но при этом всё равно он будет проигрывать топовым RISC/CISC'ам. В HPC, где мы молотим много плавучки и паттерны доступа к памяти несложные - Эльбрус может показывать близкие к максимумам цифры. Но HPC - это лишь часть серверного рынка, причём довольно специфическая, там вообще на GPU переходят часто. А если ваши сервера хостят сайтики - там перформанс Эльбруса будет стремиться ко дну.
abondarev
Да я как раз про этот сегмент, как написал выше, что считаю нужным развивать данную архитектуру, как и вообще подобные компетенции. И это один из вариантов где это можно делать достаточно эффективно, не сильно уступая мировым производителям.
Так и есть, когда то Sun позиционировал Niagarа для сервера для веб серверов, и AMD если нужно высокопроизодительная считалка. Остается вспомнить что МЦСТ изначально Московский Центр Спарк (SPARC) Технологий.
Armmaster Автор
Если все понимают, что мы Эльбрусы развиваем именно для компетенций и для пары-тройки специализированных дата-центров, и стоит это столько и столько - нет вопросов. Но я за то, что не надо испытывать иллюзий по поводу широкого использования Эльбрусов в качестве базовой десктопной/серверной платформы
Psychosynthesis
Было бы круто, если бы вы дописали сей вывод в статью... А то как-то слишком уж разгромно получается и не очевидно для людей не погружённых в тему.
DonkeyHot
А делали его скорее для вояк и как раз для HPC применений – суперкомпьютеры, симуляция ядерных взрывов (испытания давно не проводят, а считают на суперкомпьютерах), обработка данных радаров раннего обнаружения и прочее.
Civil
Не очень понятно как можно вынудить компанию позиционировать свой продукт не в той нише в какой они хотят, если честно.
К тому же, можно посмотреть на историю Эльбруса. Там будет видно что его изначально позиционировали как убийц Pentium, что подразумевает и десктопные применения. В общем советую почитать материалы времен когда Бабаян работал в МЦСТ. Кажется в каких-то журналах были интервью и уже тогда МЦСТ позиционировали процессор как универсальный, и именно акцентировали внимание на том что VLIW традиционно таковым не считаются, но они стараются и делают и верят в свой успех.
DonkeyHot
Если они всерьез позиционировали Эльбрус как универсальный, зачем тогда основывать центр по RISC технологиям и развивать и выпускать линейки RISC процессоров?
Первый RISC процессор они выпустили еще в 2001.
Civil
В интервью тех времен об этом кажется тоже говорилось - потому что на разработку деньги были нужны. А SPARC в тот момент можно было лицензировать и относительно быстро сдать заказчику.
DonkeyHot
SPARC лицензировали в 1992 году, а RISC процессорами начали заниматься еще в 1986, так что связи тут нет — они изначально развивали RISC направление
Civil
Я повторюсь ещё раз: читайте историю мцст и интервью Бабаяна. Только пожалуйста а этот раз не выборочно, а целиком. А то сейчас вы занимаетесь довольно неприятной техникой: вырываете кусок из контекста и выдаёте его за неоспоримое доказательство своей точки зрения.
В данной ситуации вы упускает наработки по Эльбрус-3 и собственно то, как они там заразились идеей сделать отличный vliw.
DonkeyHot
Я прочитал интервью Бабаяна, там нигде не говорится, что они готовы конкурировать с Пентиумом, только что там используются схожие принципы суперскалярности, которые они начали разрабатывать как комерческий продукт еще до HP, IBM и Intel (и кстати бывший их сотрудник Пентковский работал над разработкой Пентиума). Что они хотят ставить VLIW Эльбрусы на десктопы там вообще ни слова. Зато есть про Эльбрус-90, который RISC.
И еще раз, что они почти всю дорогу занимались и RISC направлением, как раз хорошо показывает, что они не считали, что VLIW универсальный и «подойдет для всего», как говорите вы.
Civil
Есть простой ответ, открываем страничку про Эльбрус на сайте МЦСТ и читаем
Можете пойти дальше, в статью 2001 года (ее вообще в контексте данной статьи очень забавно почитать), там в общем-то прямое сопоставление идет с классическими подходами, нигде нет ничего про какую-то мифическую узкую специализацию.
Можно в общем пойти копать дальше, почитать публикацию Бабаяна в Спрингере (она правда на английском по очевидным причинам) - она в более сжатом виде повторяет ровно то же самое.
Вообще статью, которую я имюе в виду я не могу найти, помню что читал в свое время (период с 99 по 2002 год, точнее определить не могу) в бумажном виде. Мне почему-то казалось что это Компьютерра, но в ее архивах копаться не очень удобно оказалось. Есть отголоски этой статьи в виде заметок в Коммерсанте и некоторых цитатах из интервью, очень разрозненных впрочем.
Ну и Ваша ошибка в фокусе на слово "десктопное". Правильно смотреть на "Универсальное" или "общего назначения". Но Вы можете найти какие-нибудь официальные документы от МЦСТ где будет стоять слово "Специализированный" и очерчены области применения, этого будет достаточно чтобы доказать. А то сейчас вся ваша гипотеза основывается на том, что нигде не написано явным образом "для десктопа".
P.S. И в соседней части этой ветки Вы вообще об истории МЦСТ спорите с человеком, который очень много лет проработал в этом МЦСТ, мне честно говоря кажется что Вам просто стоит его послушать и принять к сведению.
Armmaster Автор
Рассказываю. В 90х были тяжёлые времена и Мцст тесно сотрудничали с Sun, занимаясь разными проектами по Sparc и в окрестностях, чтобы прокормиться. Но параллельно пытались развивать свою линейку Эльбрус как General purpose cpu, в том числе активно пытаясь найти деньги в Штатах. Всё это закончилось ничем, а в итоге когда военные в конце 90х пришли и сказали "дайте нам хоть что-то работающее ", единственный реальный вариант было взять простенький Sparc (на который была лицензия) и его сделать. Т. к. Эльбрус был крайне далёк от производства в то время. Собственно, так и получилось исторически 2 линейки General purpose cpu в Мцст
DonkeyHot
Armmaster Автор
Без сотрудничества с Sun они бы не получили лицензию на Sparc. В любом случае, даже если так, это никак не меняет того, что я написал
DonkeyHot
Это меняет причину-следствие.
С Sun они стали работать и лицензировать SPARC потому что уже ранее сами разработали RISC процессор. А не сделали RISC процессор, потому что от безденежья пришлось работать с Sun.
То есть у них был сознательный выбор RISC архитекторы и было желание заниматься этим направлением.
Andry_2014
Они выпускали Спарки что бы как то выжить в условиях экономического кризиса.
permeakra
HPC - это далеко не только серверный рынок в общем-то. Задач, упирающихся в числодробление, хватает в, например, мульмедиа и всяческой цифровой фотографии. И эти задачи обычно решают специализированным VLIW DSP. В приложении к военным задачам речь идет о работе с большими архивами спутниковых фото, например.
Civil
Ну это не совсем так. Если посмотреть на всем известный top500 суперкомпьютеров - там, кажется, в первом top100 ноль с VLIW DSP. top1 вообще без акселераторов, просто ARMv8 с SVE, потом идет пачка с nVidia V100 и nVidia A100, еще есть китайцы с кастомным RISCом и китайцы с Xeon-Phi подобным собственным акселератором (который есть 128 in-order RISC ядер собственной разработки), есть еще пачка с Xeon Phi и несколько где просто много x86 процессоров без акселераторов (в основном Epyc'ов).
Я конечно допускаю что кого-то упустил, но в массе своей это видеокарты или RISC-акселераторы.
DSP (и некоторые из них - VLIW) используются, но скорее в условно мобильных устройствах (начиная от смартфонов, заканчивая всякими радиоприемниками и военным оборудованием).
BugM
Не смотрите туда. Этот рейтинг мало чего показывает. Серьезные ребята не играют него. Там даже Гугла нет.
Civil
Автор выше говорил про HPC - для этого рейтинг очень даже адекватный.
BugM
Нет. FAAGN может занять все места одновременно. Просто на своих продакшен кластерах.
Да, даже Яндекс легко может занять первое или около того место. Если FAAGN не участвует. Тоже на своем обычном продакшен кластере.
Но никого из них нет. Значит рейтинг очень узкий и специфический. Клуб тех кому это интересно или зачем-то нужно.
Для проверки себя оцените количество серверов в одном датацентре Яндекса. Количество серверов в одном датацентре Гугла получить из этой цифры можно легко. По разнице количества этажей в этих датацентрах.
Civil
Прошу прощения за дубль, поправленный комментарий ниже.
Civil
HPС - достаточно определенный класс задач со своими узкими требования. Туда продакшн кластера IT компаний не попадают в принципе. Как и задачи, которые там типично гоняются, без адаптации (читай переписывания с применением других подходов) на не-HPC системах запустить не получится.
И это так, но обсуждение то про HPC идет, а это очень специфический и действительно узкий рынок. Там свои принципы построения систем, своя специфика написания ПО, своя специфика задач.
А это не имеет значения, их датацентры призваны решать другие задачи и поэтому не оцениваются критерями HPC-систем.
BugM
Да прямо на этом сайте есть про обычные облака https://www.top500.org/news/fugaku-holds-top-spot-exascale-remains-elusive/
Это сделал не Амазон, а их клиент. Без доступа к dom0, всей сети, всему железу и прочим хакам возможным на железе.
Нет никакого специфично железа. По крайней мере массово. У всех x86/arm и видеокарты. И датацентры строят все одинаково. 10Гбит сеть с простроенная по принципам крупных датацентров это лучшее что сейчас возможно. Сейчас потихоньку 100Гбит в мир идет. И тоже в обычных датацентрах.
Все остальное уже просто хуже. По любой характеристике. (кроме распила бабла, вот тут типовое решение гораздо хуже выходит)
Am0ralist
Суперкопмьютер от датацентра отличается тем же интерконнектом, с запредельной стоимостью, которая не имеет смысла во всех этих «облаках». Тот же Infiniband стоит чуть меньше 1k$ на каждую ноду, да ещё вам их просто так не продадут. А ещё там свои комутаторы.
Итого, есть задачи, которые требуют именно суперов.
Есть те, кому хватит и майнинговой фермы или облака.
Но считать, что последние равны суперам — это не понимать разницы.
BugM
Открываем обычную википедию https://en.wikipedia.org/wiki/InfiniBand И видим примерно те же скорости которые дает типовая 100Гбит оптика.
Разница есть, но не так чтобы принципиальная. С учетом что оптика это массовая продакшен технология и на ней можно недорого и маштабируемо строить все что угодно. Закидать типовым железом дешевле выходит.
Am0ralist
Примерно те же скорости между двумя узлами и примерно ту же скорость обмена информацией внутри супера — не одно и то же, если что.
а что, в оной оптика типа не используется?Вы на 100 GB сможете организовать сеть, в которой 50% узлов передают одновременно данным другим 50% узлов без задержек и падения скорости?
И да, Ethernet так же спокойно реализуют поверх оного.
Хотя я тоже не прав, оные вещи и в облачных датацентрах могут использовать, просто это дороже, насколько понимаю.
BugM
По поводу точных цифр не уверен, но примерно да. Вероятно все таки поменьше, но не настолько как выдумаете.
Там много одновременно передавать можно. Типовая архитектура сети в датацентре много чего позволяет. Вот тут, например, хорошее описание. Как сейчас сети строятся. https://habr.com/ru/company/yandex/blog/550298/
Что-то дешевле типового промышленного решения? И не хуже по характеристикам? Все строители ДЦ быстро переключатся на более выгодное решение. И оно тут же станет типовым промышленным решением.
Am0ralist
Ещё раз, я про InfiniBand — его использовать могут и в облаках. Оно просто дороже.
Ну вот в осбуждениях суперов как раз всегда и говорят, что именно шустрые интерконнекты между всеми нодами (типа InfiniBand) и есть признак супера.Поэтому в ДЦ чаще используют обычную сеть
То есть возможность структуру неблокирующего толстого дерева реализовать. Для оной это есть.
Если вам подобное для задач не нужно — это одно. Если нужно — то строят супер, по идее.
BugM
Мир так устроен что если на порядок дешевле можно получить чуть-чуть похуже характеристики, то выгодно делать похуже и купить побольше железа. Закидать дешевым типовым железом это работающая стратегия.
То что вы говорите было востребовано лет 10 назад. Во времена массовых гигабитных сетей. Сейчас во времена массовых 100 гигабитных сетей это все стало не нужно. Массмаркет достиг достаточного качества чтобы вытеснить все остальное.
Исторические проекты останутся на том на чем их построили. Вероятно даже обновляться будут на тех же технологиях. Но нет ни одной причины сейчас строить что-то новое на немассовой технологии. Денег уйдет больше, а результат будет меньше.
Am0ralist
То есть ответа нет, но вы считаете, что по любому сможете?
Скажите, я правильно понимаю, что вы и биток до сих пор майните на пуле домашних видиков?
Ну, чисто наглядно показать, что от всё таки вопрос решения задач зависит напрямую от выбора варианта на чём её делать.
BugM
У биткоина одновременно сошлись звезды. Абсолютная простота и неизменность алгоритма.
В реальном мире алгоритмы гораздо сложнее и изменчивее. Аналитики подумали, поменяли формулу ипопросили внести изменения. Такое раз в полгода-год везде бывает. Все асики выкидываем и заказываем новые? Ну так себе план.
Там где эти звезды сходятся, например декодирование/кодирование h.264, используют специфичные и очень массовые схемы. У компьютера общего назначения такое не пройдет.
Civil
Касательно места №27 - посмотрие что такое "NDv4" инстансы в Azure и чем они отличаются от "просто облака". TLDR (если не хотите сами искать) это специальные инстансы под HPC, задизайненные с учетом требований данной отрасли, это не на обычных Compute инстансах делается.
Касательно Amazon'а - история чуть другая, это уже чуть ближе, как минимум тем что это те же самы инстансы, но тут посмотрите на разницу 40-ого места где расположился HPC поверх Amazon EC2 с тем что в топ10, по производительности.
Надеюсь после этого, вопросы о том почему делать HPC поверх облаков это не очень хорошая идея - отпадут.
Не совсем, в топе - специфичное железо. Дальше от типичных датацентров это отличается как миниму интерконнектами. Вот Вы говорите про 100 гбит в секунду в обычных датацентрах, а посмотрите какие интерконнекты были в HPC в 18 году (подсказка: 200 Гбитные Infiniband'ы, а сейчас уже 400 гбитные предлагают). Посмотрите на latency по infiniband по сравнению с обычными сетями.
Принцип построения систем отличается, потому что в разных ситуациях важны разные вещи., толкьо и всего. У, как это модно называть, гиперконвергентных компаний требования где намного более выгодно (если ты крупный) взять что-то что можно легко заменить и что можно покупать в масштабах намного больших, чем у HPC, а заодно с меньшими требованиями и к задержке и к надежности всей системы. Для них - нормально когда у тебя что-то случилось и датацентр немного отключился на денек-другой, или когда у тебя компоненты выходят из строя каждый день (нормально пока поддерживается общая емкость системы). Для HPC - такое недопустимо, зато допустимо потратить больше денег и времени на строительство системы, которая на минимальной площади при минимальных энергозатратах способна в долгосрочном периоде гонять условную задачу по свертке белка с гарантией на получение результата. На это влияют прежде всего задачи которые там крутятся и люди, которые эти задачи там реализуют (не надо считать, что ученые - хорошие программисты или что в научных центрах много хороших и умных людей, которые смогут организовать адекватные по надежности системы вычислений поверх commodity hw со всеми его недостатками)
BugM
У вас ключевое в конце. Разница по лейтенси и в 4 раза по скорости это тьфу же. Написать софт чуть-чуть по другому и все хорошо будет. Это даже не порядок разницы.
А вот что людям проще отвалить кучу бабла за менее эффективную и более дорогую систему с которой проще обращаться это беда. Отдать контракт тому же Амазону. Их инженеры с радостью все поддержат и даже софт напишут по ТЗ от ученых, если надо. Выйдет дешевле в итоге.
Civil
Смотрите, вы заявляете что все отлично, я правильно Вас понял? Если да, то расскажите, почему разница между топ1 и hpc поверх амазона в 44 раза (по реальной производительности)?
Сравните показатель theoretical peak и наблюдаемое в linpack по top500. Посчитайте для топ1 и для амазона.
Потом посчитайте стоимость того кластера на амазоне. Посмотрите на стоимость сопоставимых по производительности HPC кластеров. Потом попробуйте получить допустим в 5 раз более производительный кластер от амазона.
Покажите пожалуйста, где такая услуга у Амазона и сколько она стоит?
BugM
Потому что так сделали. Кэп. Посмотрите начало ветки.
Это место доказывает что архитектура ДЦ Амазона подходит для гоняния этих тестов. Они (Амазон) не заняли там все места просто потому что не хотят. Серверов и ДЦ у них хватит.
Это не для обычного человека. И даже не для обычного юрлица. Прайс никто писать на такое не будет, потому что смысла нет. Объявляем тендер, приглашаем поучаствовать. Амазон, Оракл, МС и тому подобных. Они с радостью придут со своими инженерами серверами и предложениями. Тендеры обычно открытые, если их прилично будет то и средняя цена сформируется.
Прайс по итогу выйдет меньше чем строить что-то кастомное. Считаем первоначальную плату за запуск + плату на обслуживание за все годы работы. Срок службы закладываем около 10 лет. Дальше уже дешевле выкинуть и построить заново, чем поддерживать устаревшее.
Civil
Я так и не увидел доказательств того, что это возможно.
Жду сравнение цены типичного тендера на подобные услуги (допустим выигранное амазоном) с ценой на создание и поддержание кластера. Раз сказали что открытые - легко будет найти и показать.
BugM
Вот же сделали. Сделал не Амазон. Значит это был не bare metal и не весь ДЦ.
Это говорит нам что архитектура Амазона подходит для запуска этого теста. Это просто факт. Тест был запущен, отработал и показал разумные циферки. Дальше тупо накидываем ядра/видеокарты и вперед.
157 тысяч ядер. Допустим по сотне ядер на сервер (это вероятно заниженная, но реальная оценка) Это всего полторы тысячи серверов. Амазон х10 выдаст легко в любом своем ДЦ. Добавляем что на современных серверах скорее всего больше 100 ядер и получаем совсем топ результат.
За конкретикой идите к своему сенатору, или кто там деньги на такие стройки распределяет. Случайный человек в интернете вам покажет только общие соображения.
Массовое - всегда дешевле отдельной разработки.
Амазон понимает в содержании железа и проектировании ДЦ. И точно сделает это дешевле чем кто угодно другой. За исключением таких же монстров.
Гос и около заказы конторы вроде Амазона берут с радостью и активно торгуются друг с другом.
Итого нет ни одной причина почему у Амазона такое будет дороже чем кастомная разработка от людей которые понятия не имеют как дешево строить и обслуживать ДЦ.
Civil
Так а где доказательство, что это не предел возможного-то? Я пока все равно не вижу.
Для запуска теста подходит моя кофемашина (если там получить рута), чисто теореически. Или raspberry pi. Вопрос в том что ты будешь получать когда начнешь это все масштабировать, а потом вопрос в цене на решение.
Если вы немного покопаетесь по сайту амазона, вы без труда найдете точный ответ на то сколько у них ядер в серверах (а заодно какие частоты у них, кстати не забывайте, если будете смотреть по vCPU виртуальных, что надо чиселку там делить на 2, чтобы получить ядра, впрочем в тех местах где сказано сколько ядер на сервер об этом будет явно сказано под звездочкой). Это не сложно сделать, не надо будет спекулировать о том что у них есть, а чего нету. Проведите исследование, удивитесь немного.
То есть это все домыслы? А как же ваши слова тут: "Тендеры обычно открытые". Это буквально значит что цена на тендер и условия будут известны даже Вам, если Вы поищите. Так что будьте добры, давайте без домыслов, пройдемся по фактам. Сначала с Вас такой тендер с ценой от амазона, потом продложим.
BugM
Простите, какое доказательство вы хотите? Цифры говорят что было использовано заметно меньше полного ДЦ, я бы сказал что даже меньше 10% от полного ДЦ. Компьютерные системы такого уровня маштабируются только горизонтально. И иногда вертикально, наращивая этажи в ДЦ. Почему эту систему нельзя отмаштабировать совершенно непонятно. Все данные говорят что это можно сделать.
Вы же видели этот тест? С настройками для этого топа. Ну хотя бы чуть-чуть? Он опенсорс, можно смотреть. Вы его на кофемашине не запустите. И даже на малине не запустите.
Вы потеряли контекст. Перечитайте еще раз. Я процитирую сам себя:
Видите слово если?
Сейчас это довольно закрытая область где все держатся непонятно за что. За воздух. На этом можно осваивать огромные суммы. ТОП, круто, модно, свои сервера, науку двигаем. Ну как тут денег не выдать?
Нужно чтобы институты и ученые поняли что не надо за железки держаться, и начали давить на эффективность. Пусть ДЦ строят и обслуживают те кто это умеют. Это эфективнее. А институтам нанять разработчиков с уровнем кандидата наук в предметной области и уйти в типовые облака (сразу замечу что очередь разработчиков желающих поработать выстроится сразу, зарплату можно меньше чем в Гугле ставить. заметно меньше. науку продвигать люди хотят больше чем очередной джейсон перекладывать).
Эффективность всех рассчетов всего сразу возрастет. И денег меньше тратится будет, что тоже приятно. Есть и минус. Меряться больше нечем будет. У всех все одинаковое. Платим - получаем циферку.
Civil
А я прошу не среднюю цену, а пример одного такого. В общем все еще жду пример такого тендера.
На это тоже жду доказательства.
Без примера и цифр не вижу смысла дальше продолжать беседу, в рамках домыслов можно вывести что угодно и как угодно, реальным оно от этого не станет.
permeakra
> Разница по лейтенси и в 4 раза по скорости это тьфу же. Написать софт чуть-чуть по другому и все хорошо будет.
Если вкратце, там и так софт пишут так, чтобы по минимуму интерконнект задействовать. И все равно в него регулярно упираются. И нет, пишут не идиоты, это специальная область науки, в которую вкладываются серьезные усилия.
В качестве примера можете покопаться в scalapack, узнаете много нового.
permeakra
top500 - он не про мультимедиа, а про научные вычисления. Это, в основном, плавучка. Мультимедиа - это целочисленные вычисления. Серверные ускорители для этого самого есть у, например, Xilinx и Intel. Правда, это сочетанные DSP+FPGA решения, афаик.
Плюс есть много разных чудес, где требуется большая пропускная способность, типа высокопроизводительного Data Acquisition. Например, в церне еще в конце нулевых, афаик, речь шла о десяткаях терабайтов сырой информации с детекторов в секунду - и эти терабайты нужно прожевать и отфильтровать мусор еще до того, как их отправят в хранение и реальную обработку. Надо бы поискать, как там выходили из положения, емнип, там до ASICов дело доходило.
Civil
Вы определитесь, Вы про мультимедия или HPC. Если про HPC то top500 ровно про них.
Касательно мультимедия - на бытовом уровне ты найдешь DSP в некоторых бытовых устройствах (скорее всего разборав электропианино или купив полупроф звуковую карту). В остальном - какие-то совсем специализированные задачи. А что касается ускорителей мультимедия - популярные алгоритмы все таки предпочитают реализовывать в железе (у многих чипов есть те или иные ускорители видео кодирования и декодирования, например).
Опять же это не имеет отношения к HPC как к области. Это отдельный свой вид задач и своих систем для решения. CERN действительно делал свои железки для своих целей (у них там по презентациям сырых данных с датчиков только на LHC - сотни тысячи террабит в секунду и десятки миллионов датчиков, это требует своих особых подходов). Но судя по их докладам (это один пример где есть информация о железе, так у них доклады почти по каждой отдельной системе есть) уже в хранении и обработке (кроме первоначальной фильтрации) нет ничего выдающегося - обычные сервера на Xeon'ах, без доп ускорителей. Что в общем и понятно, потому что масштабы такие, что легкодоступное железо выиграет у специализированных решений по общей цене обслуживания.
permeakra
>Вы определитесь, Вы про мультимедия или HPC. Если про HPC то top500 ровно про них.
Я про HPC на целочисленных данных. Куда, в том числе, входят различные методы обработки картинок.
> В остальном - какие-то совсем специализированные задачи.
В каждом мобильном телефоне есть как минимум один DSP. Хотя если речь о современных, то скорее несколько, под разные задачи. В датацентрах - зависит от датацентра.
> А что касается ускорителей мультимедия - популярные алгоритмы все таки предпочитают реализовывать в железе
Железные реализации очень негибкие. Сейчас везде стараются засунуть если не процессор, то хотя бы FPGA.
Civil
Давайте вы будете говорить в общепринятых терминах, а то обсуждать что то очень сложно, когда терминология собеседника отличается от общепринятой и к тому же не публичная.
Картинки скорее будут на видеокартах или процессорах общего назначения гонять сейчас.
Есть, я выше написал об этом.
А в ДЦ найти их будет крайне сложно.
Для частых задач - в самый раз.
Для более редких - процессоры, да, или ускорители конкретных частых операций (см все ускорители для нейронок).
permeakra
HPC, согласно общепринятым терминам, про вычислительные системы, намного превосходящие по мощности обычный ПК. Я специально поискал, прежде чем писать. Системы из top500 - это лишь один из вариантов, научная разновидность. Это не единственно возможный вариант.
Смотря в каком. Посмотрите на линейку серверных продуктов Xilinx, для начала.
Civil
Читая Википедию, читайте дальше первого предложения пожалуйста.
Как я сказал - в типичном.
permeakra
Я не имею привычки пользоваться википедией в поиске определений.
В типичном датацентре DSP и прочая экзотика может быть в сетевом оборудовании. Там много любопытных гитик.
Civil
В таком случаи в Вашем источнике читайте его целиком. А если то что Вы процитировали иесть полное - найдите более адекватный источник.
В сетевом оборудовании специализированный ASIC и процессор общего назначения для всего что не реализовано в железе.
permeakra
Имею привычку пользоваться адекватными источниками и читать целиком. Серьезно, не надо меня учить, что такое HPC, уж в этом я разбираюсь точно не хуже вас.
https://docs.broadcom.com/doc/87842-PB
Civil
Раз разбираетесь, то зачем продолжаете натягивать сову на глобус?
А, так вы решили на ходу переобуться и решили вместо программируемой логики взять что попало, работающее с сигналами?
permeakra
Вот из-за того, что разбираюсь, и пользуюсь термином так, как пользуюсь.
*тяжелый вздох* Там стоит честный программируемый DSP. То, что у него программа задается на стадии сборки устройства, не меняет ситуации.
Судя по вашему тексту, надежды на дальнейшей продуктивный разговор я не имею, поэтому разговор сворачиваю.
Civil
Потому что разбираетесь, поэтому пользуетесь термином не так как это принято в IT среде? Ну что поделать.
Я не уверен что Вы вообще хотели продуктивный разговор изначально, так как с самого начала занимались подменой понятий по ходу обсуждения, как только Вам указывали на проблемы в аргументации. Я на всякий случай Вас же напомню с чего все началось (заметьте, ваше же сообщение) - с обсуждения мультимедии и VLIW DSP. Сейчас Вы дошли до того что начали приводить пример чипов, осуществляющих обработку сигналов как пример, притом что архитектура данных чипов немножечко не публична и к изначальному обсуждению VLIW DSP отношения не имеет (чтобы имела нужно доказательство что там программируемый VLIW DSP).
У меня эта ситуация вызывает только непонимание зачем так вообще делать в обсуждении. Ну и про HPC - использование своей собственной терминологии это тоже отличный прием, помогает вести диалог конструктивно (нет, это сарказм естественно, не помогает).
Но соглашусь с Вами в том, что продуктивный разговор в такой ситуации не возможен.
permeakra
HPC в понимании "массо-параллельные вычисления на плавучке 64+ бит с широким интерконнектом" - это вообще не из массового IT, потому что там это практически не нужно. Это из околонаучных и инженерных применений и за их пределами встречается крайне редко, навскидку разве что в GIS и то не факт. Я вообще плохо понимаю, как в x86 попал высокопроизводительный тракт широкой плавучки, потому что в 90+ применениях из 100 он глубоко избыточен.
Именно поэтому top500 не про IT в целом и тащить его терминологию в IT неразумно, железячные компании типа оракла и гугла трактуют HPC в расширенном смысле, а для суперкомпьютерных вычислений нужно использовать какие-то уточнения.
Чип я привел как опровержение конкретного утверждения что в сетевом оборудование все, что не в железе, делается на процессоре общего назначения. Это не так. Бывает там и DSP и железячное ускорение look-up tables, и интегрированные FPGA и много всякого.
Adva
Судя по последним статьям и веяниям в разработке процессоров для России, на мой взгляд, можно выделить три варианта развития:
Упрощение и специализация архитектуры e2k для DSP и других подходящих областей применения, а также для военных заказчиков.
Разработка процессоров Elbrus ARM для коммерческого использования.
Разработка нового процессора на базе RISC-V общего назначения.
Вариант 1 желательно развивать с точки зрения независимости от других архитектур и политических решений, но не замахиваться на что-то большее и рекламировать несбыточное "нанотехнологичное" будущее. Необходимо также оценить перспективы вариантов 2 и 3, и возможно выбрать из этих вариантов единственный. Важно иметь одну открытую архитектуру для использования всего многообразия open-source софта и иметь минимум два направления для обеспечения конкуренции центров разработки.
Armmaster Автор
П. 2 - это процессор Байкал. П.3 - Syntacore (теперь Yadro).
А вот что делать с п.1 - вопрос дискуссионный. DSP у нас делается другими разработчиками и тащить туда e2k смысла нет как по мне.
abondarev
Ну мне кажется Вы сужаете проблематику. В РФ есть не только Эльбрус. Есть еще НИИСИ с Комдивами (вполне себе собственное MIPS64 ядро), Есть Модуль (тоже с собственнsv MIPS32ядром) для космоса делают. У них есть и решения на базе покупных ARM ядер. Есть еще Элвис (https://habr.com/ru/company/embox/blog/329170/) тоже с ARM ядрами. Есть Байкал-Электроникс (https://habr.com/ru/company/embox/blog/567782/) я уже не говорю об DSP решениях например multiclet (https://habr.com/ru/company/embox/blog/265059/) и решениях с микроконтроллерами. Поэтому на мой взгляд не нужно выбирать между вариантами 2 и 3, а еще больше развивать экосистему. С необходимостью развития Эльбрусов полностью согласен, только на мой взгляд нужно определиться с их нишей и развивать полезные качества и развивать экосистему. Кстати у МЦСТ есть собственные RISC ядра (SPARC) вполне себе хорошие для своего класса задач (даже в таблице он присуствует Эльбрус-R2000) Зачем спрашивается Elbrus ARM.
Adva
Согласен, выпускаются варианты процессоров, в основном для специализированного применения. Однако отсутствуют внятные (пускай даже с учетом дотаций) предложения по технике общего назначения. Если была бы возможность заменить при желании например, часть офисных ПК и занять пускай 0,1% рынка, то это было бы настоящим успехом. Почему для данного сценария выглядят перспективно ARM ядра - из-за их широкой поддержки (большей, чем у остальных упомянутых архитектур) и ARM64EC (для Windows).
abondarev
Ой ну вот приехали, вбухиваем миллиарды в развитие собственных процессоров, для того чтобы запускать на них закрытый проприетарный не свой код и платить за это деньги? По вашему китайцы тоже для своих ПК рассматривали Windows? Или Вы считаете что для 0.1% рынка жизнено важна поддержка Windows, в которую прийдется самим вкладываться, Майкрософт такие объемы не заинтерисуют.
И это я уже не говорю, о проблеме развития экосистемы для решения предназначеных для него задач, ведь только создание процессора, это пусть большая и сложная часть работы, но далеко не единственная.
Praktik
Прошу прощения, что врываюсь в дискуссию. Но по каким признакам multiclet это DSP?
abondarev
Во первых, они себя сами так позиционировали. Исторически это была технология для слуховых аппаратов с низким потреблением. А потом уже появились какие то идеи по применению.
Я же имел в виду что это не процессор общего назначения, но имеет право на существование в определенных сегментах. Например подход когда обсчитывают параллельно много ядер сейчас во всю применяется в GPU
ifap
ИМХО вариантов всего 2:
1. Продолжаем изобретать колесо и впаривать его по госзаказу, потому что по доброй воле никто не купит.
2. Готовимся к новой «холодной войне», изоляции и идем в разнос, т.е.
повторяем подвиг AMDфрезеруем условный Ryzen 5xxx под электронным микроскопом, делаем «красный» клон на каком-нибудь 200нм техпроцессе и показываемкузькину матьфак Западу вообще икопирастамправообладателям в частности.amartology
Am0ralist
Поэтому реальнее закупка у китайцев в обмен на газ. В этом плане, как понимаю, наши не особо и спешат обгонять техпроцессы, доступные и в Китае…
Civil
Скорее России никто оборудование такого же уровня (не говоря про лучше) не продаст, а если и продадут, то можно посмотреть сколько времени взлетал (хотя, кстати, взлетел ли?) 65нм техпроцесс в РФ.
Am0ralist
Имеется ввиду, что заказываемы процы на старых техпроцессах, которые, если что, можно будет перенести (не без проблем, естественно), на производства в Китае, если прижмёт.
Про оборудование вопрос не стоит, да.
PS. Хотя, если Китай осилит свою литографию, то вариант, что он будет продавать её тем, кому не продал запад хотя бы ради тех же политико-экономических ништяков привязки к себе — вполне существует. Всё ж подобные станки привязаны к изготовителю, считай…
Civil
Я не был бы так уверен, что на это закладываются. На старых техпроцессах заказывают потому что на них очередь ожидания из крупняка уже постепенно заканчивается и там можно получить готовое изделие за разумное время, а не когда-нибудь года через 3-4.
И я бы не был так уверен, что в ситуации полного прекращения отношений с западом, Китай предложит решение. Но тут я в целом не понимаю почему люди считают что Китай за Россию и прям будет помогать.
Am0ralist
А так как стратегия Китая — подмять под себя кучу прочих стран экономически, то ему это будет выгодно.
Civil
И все равно Вы преувеличиваете значимость и ценность России в данном контексте. Надо понимать что в ситуации если Россия решит поссорится с Европой и США, то и сотрудничество с Россией для Китая обернется кучей санкций. Как рынок сбыта США и Европа куда более ценны для Китая, чем Россия (Россия по сути маленькая страна, притом беднее чем та же условная Германия, а значит и покупательная способность ниже).
И Вы забываете, что если допустим будет такой сценарий что России будет закрыт доступ к TSMC cовсем, то у нее и выбора особо не будет кроме как продолжать сотрудничество с Китаем, а значит тому какие-то поблажки делать и смысла нет, все равно у партнера не будет другого выбора.
ifap
Меня-то зачем агитировать?
qw1
ifap
Ядерная зима близко.
RedCatX
Возможно и есть смысл начать разрабатывать свой х86-совместимый процессор. Лет через 5, глядишь, что-нибудь и выйдет пригодное для широкого использования...
amartology
А лицензии где брать?
ifap
А где китайцы взяли? Что-то купили, что-то подсмотрели, что-то скоммуниздили, в результате уже имеют более-менее свой процессор. Не удивлюсь, если лет через 5 начнут конкурировать за low-сегмент SoHo.
amartology
У китайцев как раз лицензии на х86 честно купленные, ни один юридический комар носа не подточит.
ifap
Вы вряд ли погружались в проверку юридической чистоты китайского процессора, так что можете лишь предполагать, как и я. Впрочем, речь о другом: если партия скажет надо — что китайцы, что мы сделаем, как — уже второй вопрос. В тех же условиях изоляции вопросы лицензионной чистоты будут не 33-ми, а просто никакими.
qw1
Китайцы купили фирму VIA, у который в 1990-х была честная лицензция на x86.
Civil
Они не покупали VIA, а по контракту сделали с ними совместное предпоятие.
VIA в 99-ом купила Cyrix (то что от них осталось) у National Semiconductor, который купил Cyrix как компанию несколькими годами ранее, и лицнезию на x86 и на еще пачку патентов и технологий VIA получила именно от них (там по сути была покупка IP, так как инженеры в оснвном разбежались уже к тому моменту). Вообще история x86 до середины 2000-х была похожа местами на санта-барбару, ее довольно интересно почитать.
amartology
Civil
У китайцев есть 2 x86-совместимых процессора:
Zhaoxin - это совместное предпрятие с VIA, у которой есть лицензия с правой помощи разработки другим (еще со времен как они купили Cyrix, который очень щедрую лицензию получил, кажется, в 80х от интела, как и AMD впрочем)
Hygon - это совместное предприятие с AMD, про него уже были упоминания в этом треде.
Оба - лицензионно чистые.
И я скажу еще и в этом треде - не надо переоценивать китайцев в плане того на что они готовы пойти. Также как не надо недооценивать последствия шага "партия сказала сделать нелецензионный клон x86" для них и их взаимоотношения с другими странами.
ifap
Да что ж на меня так все набросились за китайцев? ;) Ну честно купили — так купили, возможно, как возможно, что-то и не вполне купили. Я ж их не осуждаю, а хвалю. И не надо тыкать в меня лицензией из 90-х, они выпустили не 8088, а вполне себе актуальный процессор. Для внутреннего потребления — сойдет, если партия сказала «импортозамещение» — НИОКР ответит: сделаем! А насколько их волную «последствия» мы уже видели на примере 5G: если это вопрос принципиальный, китайцы упрутся рогом.
Al1955lo
30 примерно лет назад участвовал в решении задачи по геометрическому преобразованию картинки. Делать это надо было быстро и мы взяли VLIW приставку к компу Электроника 60, предназначенную для БПФ, заменили ПЗУ с микрокодом на быстрое ОЗУ и... работало это быстрее БЭСМ-6. Вывод по VLIW процессорам следующий - для специфических задач их реальное быстродейстродействие может быть прекрасно (если необходимую математику загружать, как микрокод), ну а для серверной ОС и стандартных задач не подойдет.
SergeyMax
30 лет назад даже "спектрум" работал быстрее БЭСМ-6)
VlK
Понимаю, что вы больше словца красного ради спектрум приплели, но все же оригинальный спектрум использовал крайне примитивный z80, который был медленней бэсм-6, по крайней мере по рабочей частоте. :-))
DrPass
Вообще, сравнивать БЭСМ-6 со Спектрумом — дело неблагодарное, но если брать 1991-й год, тогда уже были прокачанные клоны спектрумов с процессором на частоте 7МГц. Простые операции (пересылка данных, сравнение, арифметика регистр-регистр) z80 выполнял за четыре такта, т.е. быстродействие его на них составляло 1.75 млн операций/с. Если верить Вики, быстродействие БЭСМ-6 составляло 1 млн операций/с, правда, не указано, каких.
Так что формально может быть и быстрее. С другой стороны, у z80 это 8-битные операции, а БЭСМ-6 имела 48-битное слово, и нативно умела в вещественную арифметику.
qw1
Я думаю, там в память упрётся. Разные источники пишут, что считывание из ОЗУ на ферритовых кольцах занимает от 10 до 25мкс.
VlK
Согласен, сравнение телеприставки с большой машиной смешно.
Но сравнивать модификации начала 90-х с машиной середины 60-х не менее странно. Давайте для приличия возьмем оригинальный процессор Z80 конца 70-х, имевший частоту в 2-3 МГц.