Здравствуйте, Sinclair, Вы писали:
S>Ну всё таки нет. у SIMD есть офигенное преимущество — single instruction. То есть тайминг всей команды одинаковый.
Тайминг всей одной команды одинаков? ))
VLIW способен на это же by design через явный параллелизм на уровне команд (EPIC), для этого достаточно задать одну и ту же команду разным операндам в широком слове и получишь "одинаковый тайминг всей команды".
Основная особенность линейки отечественных процессоров «Эльбрус» — заложенный в архитектуру принцип явного параллелизма операций, он даёт возможность выполнять на каждом ядре за один машинный такт до 25 операций неупакованных 32- и 64-разрядных данных и до 41 операции в векторном режиме (упакованные 32-разрядные данные)[8], что обеспечивает высокую производительность при умеренной тактовой частоте;
Вот тебе за такт 41 векторная операция (упакованные данные — это которые идут последовательно в памяти).
Одна такая операция равна одной SIMD-операции привычной тебе архитектуры, а тут их 41.
25 неупакованных за такт — тоже неплохо, позволяет вести эффективные вычисления в регистрах без обмена с RAM.
Для сравнения с SIMD раздели на 4, получишь 6 аналогов SIMD-инструкций за такт в регистрах (с произвольной их адресацией).
Но аналогично лишь условно, бо VLIW/EPIC оставляют больше простора для реализации всевозможной комбинаторики сценариев.
Впрочем, я уже пытался обратить на этот важный факт внимание, не зря ведь когда-то суперкомпьютеры делались по такой технологии.
Насчёт задержек — компилятор обладает информацией о таймингах операций.
Далее.
Со своей стороны железо использует несколько спекулятивных конвейеров, где по итогу ветвления ненужные ветки (и результаты их вычислений) отбрасываются.
Примерно то же самое происходит и в суперскалярах, т.к. ОО — это лишь один из трюков, без спекулятивности никак.
=====================
Чтобы два раза не вставать и не возвращаться к этой скучной теме:
SIMD выручает там, где вычисления дороги, например, из-за планирования OO и спекулятивности.
Именно это и есть "его офигенное преимущество" (С), оно же единственное, т.к. вычисления в суперскалярных процах слишком дороги — до половины всей энергии и транзисторов на кристалле заняты обслуживанием потока команд, а не целевыми вычислениями. В архитектурах EPIC больше ресурсов заняты полезными вычислениями.
По-сути, суперскаляры являются компроммисом между быстрыми вычислительными ядрами и ужасного медленного IO, в т.ч. RAM.
И если обратишь внимание на относительный рост характеристик компонент вычислителных систем, то станет видно, что все 90-е и примерно до 2004-го резко отрывались в быстродействии ЦП, а IO безбожно отставало. Сейчас кривая роста эффективности ЦП давно в насыщении, зато IO продолжает стабильно улучшать свою эффективность.
По мере увеличения эффективности обмена с RAM значимость EPIC-вычислений будет расти. Но в данный исторический период, когда RAM с т.з. ЦП работает чудовищно медленно, суперскаляры рулят, ес-но.
Ну а я просто вижу, что кеши в процах тоже непрерывно растут, а там статическая быстрая память, сегодня уже есть по 64 метра.
Рано или поздно внутренняя память процов вырастет до размера "достаточности" и OO-исполнение потеряет свою остроту. ))
Здравствуйте, Sinclair, Вы писали:
V>>Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат: V>>https://habr.com/ru/company/icl_services/blog/558564/ S>Это значит, что в кодеген компилятора встроили автовекторизацию простых циклов.
Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
Забудь само слово "автовекторизация" когда речь про VLIW.
V>>В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца. S>Ну, так я понял, что идея к тому и сводится, чтобы недостатки технологии обойти достоинствами архитектуры.
V>>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров"). S>Чего там высокоуровневого?
Это как вызов подпрограммы над определёнными структурами данных.
V>>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW. S>Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось.
"Простая компиляция под Эльбрус" — это и есть твоя "автовекторизация".
Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
V>>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения. S>Взамен давая серъёзные преимущества.
Это в теории.
На деле всё плохо:
— у железа ограничено время принятия решения, в отличие от компилятора;
— величина окна просмотра логики ограничена;
— кол-во меток для кеширования ветвлений ограничено, т.е. в достаточно большом цикле никаких верных предсказаний ветвлений может и не быть (даже если цикл мал в исходнике, но вызывает, допустим, достаточно большие подпрограммы).
В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
Они выдают старое за новое.
Комбинируют новые подсистемы графики, контроллеров RAM, слабые ядра с сильными и т.д.
Т.е. делают вид, что что-то делают.
Но не делают ни-че-го.
Зеро.
Тупик происходит уже 10-й год.
V>>Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях. S>Это если вручную.
Это даже компиляторами, потому что набор ср-в узок и соблюдённые требования по упакованности данных не так просто автоматически распознать.
Это почему до сих пор (позорище!) инстинстики над SIMD более чем популярны для ручного анонирования — из-за тупости компиляторов.
S>Но вручную и VLIW выписывать не шибко удобнее.
Вручную для VLIW и не требуется.
V>>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. )) S>Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.
Любая техническая экосистема — это система с обратной положительной связью.
V>>Будет удобно — будут пользоваться. S>Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности:
Например, новая память Samsung LPDDR5 6400 может отправлять 51,2 гигабайта данных или примерно 14 видеофайлов в формате Full HD (3,7 ГБ каждый) за секунду.
Планируемые характеристики микропроцессора «Эльбрус-32С»:
производительность — до 3 / 1,5 Тфлоп/с;
количество ядер — 32;
Тактовая частота — 2,5 ГГц;
объем кэш-памяти (L2+L3) — 64 МБ;
ОЗУ — тип DDR5, 170 ГБайт/с, не менее 6 каналов, не менее 2 Тбайт;
интерфейсы: 64 линии PCIe 5.0, Ethernet 10/25/40/50/100 Гбит/с, USB 3.1;
возможность объединения до четырех микропроцессоров на общей памяти;
технология — 7 нм.
S>Но желания, как видим, никакого нет.
Нет железа.
Имеющиеся 8с, как ни крути, морально устарели.
Нужно было давать пинка разработке 16с, но чего-то телились почти 5 лет еле-еле.
Банальное недофинансирование.
Разворачивать инфраструктуру на 16с можно было бы уже смело давно, будь они в достаточном кол-ве, а там бы поспел и топчик 32с.
V>>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы. V>>А простое редактирование программы толком не занимает вовсе. S>Редактирование программы нужно делать в нормальной IDE.
Любой ноут справляется с любой "нормальной IDE", если это не солюшен на 50+ проектов.
Один-два средних размера проекта в солюшене — ни о чём.
S>Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.
Эльбрусу пофик, это ж Linux.
Например, сетевой диск монтируется локально как родной, IDE может исполняться локально, а компиляться и отлаживать код может удалённо и еще сверху миллион комбинаторных комбинаций конфигурирования.
Например, особой разницы локальной и удалённой отладки в линухах нет, в обоих случаях идёт общение с отладчиком-серисом одинаковым образом.
V>>Речь о принципиальной возможности доступа к железу для целей экспериментов. S>Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Программисты зато нуждаются.
У нас же нет аппарата принуждения инженеров.
Мы можем только сделать людям любопытно и смотреть, что из этого выйдет.
S>Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.
На реальном железе лучше, конечно.
V>>О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему. S>Очень малая у неё инерция.
Хотелось бы примеров.
Потому что история показывает ровно обратное.
S>Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
Наоборот, линуховоды чуть ли не десяток лет паравиртуализацию в KVM разрабатывали.
И как только допилили до работоспособности — ррраз, и уехало.
Десяток лет, Карл!
А на деле всё-равно не справились.
Первый вменяемый гипервизор с паравиртуализацией Xen для линухов был разработан той самой академкой, а не традиционным программистским сообществом.
Аспирантура психанула, не иначе! ))
Самое забавное, что в Windows аналогичные технологии были готовы лет на ~8 раньше, но жадность фраера сгубила.
Все облака давно могли бы крутиться на виндах еще до середины нулевых... но тогда был слишком триумф Windows, поэтому они гордо просрали все полимеры.
Вот тебе вокруг только одних облаков чудовищная инерция:
— долгая неспособность оперативно разработать вменяемые технологии виртуализации для Linux;
— долгое игнорирование отраслью качественных имеющихся решений на основе операционок MS из-за ценовой политики.
Время... деньги...
S>Или там — вот у нас суперновый чип A1
Архитектура ARM зато не суперновая.
Apple Newton или просто Newton — одна из первых серий карманных персональных компьютеров, которая разрабатывалась, производилась и продавалась фирмой Apple Computer. Apple начала разработку платформы в 1987 году и выпустила первые устройства в августе 1993 года.
...
Большинство компьютеров Newton работали на RISC-процессоре ARM 610.
S>экзотический язык программирования и среда разработки
Objective-C экзотический? Ты с какой Луны к нам свалился, что ты делаешь на этом сайте? ))
На моей памяти — весьма популярный язык, т.к. C++ еще не был вменяемым в те годы.
Под маками на Objective-C написано чуть более чем всё с 80-х, когда Джобс основал NeXT, а потом принёс эти наработки в 90-х в Apple.
Оболочка Mac OS X — это переименованная NeXTSTEP.
Cocoa — это перелицованная GUI-среда оттуда же.
Для справки — многие игры под DOS (взять тот же Doom) разрабатывались в среде NeXT.
S>и хооп!
Да не было никакого хооп, что за буйные фантазии? ))
Был iPod + iTunes с 2001-го, потом Apple TV.
В общем, инфраструктура платного распространения ПО и контента не взялась с потолка, а долго рожалась и отлаживалась.
S>сотни тысяч программ в аппсторе, миллиарды оборота.
Ты подумал, что это написано с 0-ля или как понимать этот тон?
Под маками, в отличие от бесконечного зоопарка GUI виндов и линухов, альтернативных вариантов GUI нет.
С одной стороны, никак не сделать шаг вправо-влево.
С другой стороны, твой код не протухает десятилетиями.
Я допускаю, что это всё было экзотикой для тебя лично, т.к. ты в мак-экосистеме не вращался до покупки айфона/айпода или чего там...
Но какой смысл выдавать свои даже не наблюдения, а сугубо эмоциональные ощущения за "аргмент"? ))
Мне приходилось упражняться на Objective-C всю дорогу в 90-х.
Да и не только мне.
Просто вы, дельфийы, джависты, 1С-ники и прочие дотнетчики с точки зрения нормального разработчика были как пришельцы, наши "миры" ранее особо не пересекались.
Нам были неинтересны ваши наработки, а вы принципиально были не способны выполнять нашу работу.
Вы даже плохо представляли, в чём она заключается, какие задачи решаются.
V>>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д. V>>Т.е. вопрос заведомо затратный, но неизбежный. S>Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.
Спасибо, прореагировал в голос.
И отчего же Интел была вынуждена похоронить многомиллиардный Itanium?
Какая-то блоха AMD, которая изначально стырила прям в бинаре архитектуру чипа 8080, спустя 20 лет помножила на ноль ВСЕ вложения Интел в Itanium.
Плохие маркетологи были в Intel? — не думаю.
Думаю, что рынок не всегда делает лучший выбор.
Думаю, что люди предпочитают меньше платить здесь и сейчас, и пофик, что за это они расплатятся лишней платой и завтра, и послезавтра, и всегда.
Не помню точных цифр, не хочу врать... Но как-то попадалось на глаза исследования, утверждалось, что из-за неудачных принятых когда-то решений (которые уже не переиграть) отрасль IT потребляет лишние десятки миллиардов ежегодно. Т.е. IT могло бы обходиться человечеству дешевле и эффективней.
V>>Пользователями современного топового железа в основном выступают облака. S>Облака тоже не являются никакой самоценностью. Облака — всего лишь инструмент. Они востребованы настолько, насколько востребован софт, крутящийся в облаках.
Ключевое было про топовость.
Эльбрус имеет архитектуру суперкомпьютера, таки.
Так-то есть начальные процы, типа К1891ВМ068.
V>>Но будут платить за хостинг сервисов. S>Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Надёжность подойдёт?
S>Например — более быстрый рендер графики, или более быстрый тренинг НС.
Или больше безопасности.
S>Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике.
Т.е., наблюдается забавная тенденция — новички валят на облака ажура или aws, а потом, поняв, что к чему, потихоньку валят на альтернативы.
В Азии, к примеру, растут десятки своих крупных игроков и цены там приятней.
Сравнивать доли облачных вычислений надо не в долларах, а в объёмах вычислений.
S>Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.
Странные у тебя фрмулировки насчёт "надеемся".
По факту сложности с оплатой там давно, сложности с железом нам достоверно обещали.
Никакие компромиссные варианты (а они будут, ес-но, на каком-то этапе) не интересуют в стратегическом плане.
От ненадёжных контрагентов придётся уходить.
S>В итоге мы опять упираемся в академические исследования и фундаментальные разработки.
И это прекрасно.
V>>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом. S>Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями".
Это смотря какими пользователями, какой план/тарифы.
S>Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Я говорил про поточный параллелизм, который не в пересчёте на ядро.
С ядрами в разрабатываемых Эльбрусах всё складывается неплохо — в этой архитектуре делить общую память могут 4 кристалла.
S>Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле.
Такой вариант, что норма прибыли оператора будет заложена в разы меньшая, ты не рассматривал?
V>>Ес-но, если дороже. V>>А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро. S>Расскажите про это тем, кто обучает НС.
Я рассказываю это тем, кто всю свою карьеру далёк от эффективных вычислений.
V>>Дотации от гос-ва еще никто не отменял. S>Но и никто не видел
Эльбрусы делают за счёт минторга, если что.
V>>IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно. S>Жаль, что кроме нас с вами, это мало кто понимает.
Ну еще пара министерств, а так никто.
V>>Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных. V>>Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё. V>>Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить". S>Повторюсь: чтобы он выстрелил, нужны некоторые предварительные шаги. Прямо сейчас, как и в последние 10 лет, я этих шагов не наблюдаю.
Так ты и Objective-C не наблюдал, для тебя это "экзотика", хотя по-факту — обычная экосистема маков.
V>>Это задача компилятора. S>Повторю вопрос: кто напишет компилятор?
Почему в будущем времени?
Компилятор давно написан и постоянно обновляется.
На сегодня есть полная поддержка стандарта С++14, идёт дальнейшее развитие компилятора.
V>>Ниоткуда, компиляция пойдёт по дефолтной ветке. S> Тогда и производительность будет дефолтная.
Это на Интеле будет дефолтная, т.е. с проседанием.
Потому что SIMD — это костыль для убогих технологий прошлой эпохи.
V>>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы. S>Спасибо, я в курсе, как работают макросы в С
Тогда бы ты не писал то, что писал.
V>>Зачем? S>Эмм, чтобы обойти тупость компилятора.
Компилятор под amd_x64 тупой не просто так, а потому что автовекторизация в условиях ограничений на лейаут данных — задача не тривиальная.
В отсутствии таких ограничений проблема не существует.
Проблема автовекторизации в С/С++ происходит от того, что данные, которые хранятся в памяти, вынуждены сохранять свой лейаут.
Связано это с независимой компиляцией единиц трансляции, т.е. различные единицы трансляции должны одинаково интерпретировать один и тот же тип в памяти.
Это отрубает целый класс оптимизаций, связанных с переупорядочиванием представления данных в памяти.
Частично с этой проблемой неплохо борются архитектуры с большим файлом регистров и компиляторы, качественно проводящие escape-анализ, т.к. при обнаружении локальности данных (в регистрах или на стеке), руки у компилятора становятся развязаны.
Особенность компилятора под Эльбрус в том, что он лучше оригинального gcc умеет выполнять полную оптимизацию, т.е. использовать технику LTO, т.е. в том числе "замыкать" на уровне бинарного модуля видимость данных и преобразовывать их для достижения лучшей производительности. С включённой техникой LTO одни и те же тесты порой выполняются до 5 раз быстрее — инлайн для VLIW рулит. Неплохие результаты показывается так же PGO. Неплохие в сравнении с традиционными архитектурами.
V>>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь. S>Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Что лишь демонстрирует тупиковость этого подхода для классических архитектур.
S>Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено.
Верно. Проблема в ограничениях SIMD-расширений.
V>>А у Эльбруса весь код, считай, SIMD. S>В том-то и дело.
Дело в меньших ограничениях.
Вернее, в полном отсутствии ограничений.
S>Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
... коды одной платформы попадают в динамический оптимизатор другой платформы для обеспечения полной программной совместимости. Этот
подход лучше всего реализуется на архитектурах с явным параллелизмом команд и с аппаратной поддержкой процесса двоичной трансляции. Дополнительным преимуществом динамической трансляции является возможность легко преодолевать межпроцедурные и межмодульные границы, выполняя тем самым мощный класс межпроцедурных оптимизаций. В ОДТЭ благодаря адаптивной оптимизации и достаточно хорошей аппаратной поддержке удается выполнять программы, исполняющиеся существенно быстрее, нежели на исходной платформе при той же тактовой частоте.
И в списке литературы тоже не скучно.
Сорри, но ты здесь вещаешь истины из разряда "не стоит клеить щит из сырой древесины".
V>>Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты. S> Для этого нужно знать, какие байты корректны, а какие — нет.
Спецификации доступны уже пару лет как, технику тоже давно можно купить.
Разработка джит-компилятора — это несколько слоёв иерархии ТЗ-решение, где для 99% работы целевая архитектура не требуется вовсе.
Курить принципы работы оптимизирующих компиляторов.
V>>Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд. S>Он практически бесполезен для обсуждаемой задачи.
Наоборот, стоит задача генерить эффективный VLIW-код и динамический джит с x86/x64 показывает, что такие задачи мы умеем решать на самом что ни на есть мировом уровне.
Ты ведь должен понимать, что это край современного прогресса. ))
Сколько там лет и лярдов потрачено на джит-компиляторы подо всякие байт-коды дотнета, джавы или v8-JS?
Эти задачи выполняются мировыми лидерами.
А тут страна-бензоколонка на удивление легко и непринуждённо справляется с задачами такого рода.
V>>Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми. S>Я вот этого вот "сейчас зашевелятся" жду с 2008.
А я жду с 2014-го.
До этого так, просто пошипели малость...
S>Продолжаем принимать новости из будущего.
Ну... ты просто малость в другой реальности всю карьеру обитаешь.
V>>Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD. V>>Ну вот сейчас зашевелятся. S> Ждём с нетерпением.
Де-факто уже в процессе.
Происходит перенос на фабрики Китая.
Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии.
Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.
Здравствуйте, Grizzli, Вы писали:
G>В предыдущую историю сзади не стоял товарищ майор с револьвером. Сейчас видимо будет. Не смогут — соответствующая ответственность, вплоть до уголовной.
А что, вариант. Я думаю, надо выдвинуть тебя первым принудительным добровольцем на разработку.
Здравствуйте, vdimas, Вы писали:
V>Де-факто уже в процессе. V>Происходит перенос на фабрики Китая. V>Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии.
прикольно, что все дифирамбы отечественному процессору свелись к тому что надо лечь под Китай V>Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.
ну, Хуавей, конечно, кто же еще
напоминает Раппальский мирный договор 1922 года, когда две страны-изгоя решили сотрудничать
но тогда немцы хотя бы поставляли в СССР современные технологии
сейчас речь об этом вообще не идет
Здравствуйте, vdimas, Вы писали:
V>И эта прболема никуда не делась — все последние поколения процов Интел — фейк. V>Они выдают старое за новое. V>Комбинируют новые подсистемы графики, контроллеров RAM, слабые ядра с сильными и т.д. V>Т.е. делают вид, что что-то делают. V>Но не делают ни-че-го. V>Зеро. V>Тупик происходит уже 10-й год.
Раз речь зашла про 10 лет, давайте "в лоб" сравним производительность какого-нибудь процессора Ivy Bridge (2012) с Alder Lake (2022):
Частота в boost-е подросла на 1 Ггц, при этом производительность одного (полноценного) ядра почти в 2 раза. Да и самих ядер стало в 2-3 раза больше.
В общем на мой взгляд это всё достаточно далеко от "зеро и ни-че-го".
[...]
V>Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности: V>
V>Например, новая память Samsung LPDDR5 6400 может отправлять 51,2 гигабайта данных или примерно 14 видеофайлов в формате Full HD (3,7 ГБ каждый) за секунду.
V>
V>Планируемые характеристики микропроцессора «Эльбрус-32С»:
V>производительность — до 3 / 1,5 Тфлоп/с;
V>количество ядер — 32;
V>Тактовая частота — 2,5 ГГц;
V>объем кэш-памяти (L2+L3) — 64 МБ;
V>ОЗУ — тип DDR5, 170 ГБайт/с, не менее 6 каналов, не менее 2 Тбайт;
V>интерфейсы: 64 линии PCIe 5.0, Ethernet 10/25/40/50/100 Гбит/с, USB 3.1;
V>возможность объединения до четырех микропроцессоров на общей памяти;
V>технология — 7 нм.
Получение инженерных образцов планировалось в 2025 году. Должен был производиться на фабрике TSMC в Синьчжу, Тайвань.
Т.е. всё-таки это новости из очень далекого и туманного "завтра".
Лично мне импонирует, что в Эльбрусах осознанно частоты не задирают, ибо изначально они планировались для бесперебойного использования в "неблагоприятных" условиях. В остальном тяжело уже как-то в 20х годах 21-го века обсуждать достоинства и недостатки VLIW.
P.S. Отдельно удивляет импортозамещенческая активность только вокруг CPU, хотя нужна еще как минимум своя оперативка и накопители.
Здравствуйте, alpha21264, Вы писали: A>Что "статистика реального выполнения"? A>Как ты думаешь, что такое "статистика реального выполнения",
Например, паттерны срабатывания условных переходов. A>и как она может повлиять на работу процессора и распараллеливание команд?
Она напрямую влияет на наполнение конвеера. Распараллеливание команд в суперскаляре напрямую зависит от конвеера — последовательные независимые команды скармливаются независимым исполняющим блокам и исполняются параллельно. A>Ты что думаешь, что необходимые действия для вычислений как-то со временем меняются?
Меняется статистика вычислений. Даже одна и та же команда с одими и теми же аргументами потребует различного времени исполнения в зависимости от того, в каком из кэшей лежит нужное ей значение.
В суперскаляре это не проблема — ну просто конкретно этот блок будет занят на этот раз чуть дольше. На следующем проходе цикла раскладка команд по таймингам и блокам поменяется.
А уж если у нас есть какие-то ветвления, то всё бывает очень по-разному. Вложенные циклы по "узкой и высокой" матрице ведут себя не так, как по "широкой и низкой".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области. V>Забудь само слово "автовекторизация" когда речь про VLIW.
С чего бы вдруг? V>В том числе. V>Причём, обойти в чувствительной к быстродействию вычислений области — обработке больших массивов данных в режиме жесткого реалтайм. V>Например: V>http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
Ну, это же не общегражданская микросхема, а попытка сделать специализированную железку для конкретных надобностей.
V>Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC: V>http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
Эмм, какое отношение ПЛК имеют к бизнес-вычислениям? Или, скажем, к Эльбрусам и VLIW?
Не отвлекайтесь от темы.
V>Это как вызов подпрограммы над определёнными структурами данных.
Ну, так-то и CMPXCHG — это вызов подпрограммы над определёнными структурами данных.
Вся "высокоуровневость" SIMD по сравнению со скаляром — это трёхаргументные команды вроде той, что я привёл.
V>"Простая компиляция под Эльбрус" — это и есть твоя "автовекторизация".
Не совсем. Ну, то есть, наверное, автовекторизацию как таковую можно "обойти" путём банальной развёртки циклов, и реализации упаковки независимых команд в блок.
Но опять-таки: вот ровно эта тема весьма слабо разработана в академической тусовке, по причине отсутствия поля применения. То есть в тех местах, где классический компилятор детектирует совершенно конкретные паттерны для автовекторизации, а если не смог — то развёртывает цикл и полагается на CPU, эльбрусовский должен не просто развернуть цикл, но и суметь раскидать результат развёртки по VLIW-инструкциям. Это прямо сразу больше работы; и от качества этой работы результат зависит весьма сильно. V>Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными. Не "можно", а "нужно". Это не так просто сделать, как трепаться на форуме.
V>На деле всё плохо: V>- у железа ограничено время принятия решения, в отличие от компилятора; V>- величина окна просмотра логики ограничена; V>- кол-во меток для кеширования ветвлений ограничено, т.е. в достаточно большом цикле никаких верных предсказаний ветвлений может и не быть (даже если цикл мал в исходнике, но вызывает, допустим, достаточно большие подпрограммы).
У компилятора всё ещё хуже: данных для предсказания ветвлений у него просто нет.
V>В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
И перестали потому, что не смогли в компилятор, способный принимать решения лучше железки.
V>И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
О, пошла знаменитая аналитика от Вдимас. Да, я помню, что Билл Гейтс — неудачник. А Интел — сплошной фейк. Вот то ли дело МЦСТ!
V>Тупик происходит уже 10-й год. Нам до того тупика — ещё сорок вёрст с поворотами.
V>Это даже компиляторами, потому что набор ср-в узок и соблюдённые требования по упакованности данных не так просто автоматически распознать. V>Это почему до сих пор (позорище!) инстинстики над SIMD более чем популярны для ручного анонирования — из-за тупости компиляторов.
Ну, а я вам о чём толкую? Даже поверх SIMD написать умный компилятор уже трудно.
Скажем, порвать современный С/С++ компилятор на скалярных операциях (то есть написать более эффективный asm код) — нетривиальная задача даже для опытного разработчика.
А вот обыграть его с использованием SIMD — вполне реально (примеры приводились на этом же сайте ).
Но интринсики нужны даже не только и не столько для таких простых вещей, как ручная векторизация циклов.
На них пишут специфический код типа разбора JSON или декомпрессии JPEG, который нереалистично автоматически преобразовать из скаляра в вектор. Просто потому, что применяется другой алгоритм, чем в скалярном случае.
V>Вручную для VLIW и не требуется. Вы думаете, что компилятор для Эльбруса как-то магически превратит парсер JSON в его векторизованную версию, которая будет эффективнее ручного AVX-варианта?
Я вот не вижу предпосылок для такого оптимизма.
Точнее, так: я не считаю это принципиально невозможным; но сходу задача выглядит, как расположенная где-то между NP-полнотой и невычислимостью.
На практике, это означает, что получение подобного результата требует огромного объёма научно-исследовательской работы. И мы возвращаемся к вопросу о том, как привлечь академическое сообщество к этой работе.
V>Любая техническая экосистема — это система с обратной положительной связью.
V>Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности:
Ну, то есть опять — новости из будущего. А точнее — попытки подбора обоснований отсутствия прогресса.
Что мешает запустить облако на 8C и постепенно заменять его на 32C по мере выхода? Правильно: отсутствие желания и понимание, что это — целевой распилочный проект для того заказчика, которому неважна ни цена, ни качество.
V>Имеющиеся 8с, как ни крути, морально устарели. V>Нужно было давать пинка разработке 16с, но чего-то телились почти 5 лет еле-еле. V>Банальное недофинансирование.
Недофинансирование — это следствие неверного целеполагания. V>Разворачивать инфраструктуру на 16с можно было бы уже смело давно, будь они в достаточном кол-ве, а там бы поспел и топчик 32с.
Люди вроде вас регулярно выступают против оппозиции, которая критикует наших олигархов и приближённых Светлейшего за воровство миллиардами.
Вот вам и простой пример: вместо дач Медведева можно было поднять облако на Эльбрусах 8c, или хотя бы заказать достаточный объём 16с.
Но у ребят, которые у руля, нет такой задачи. Все разговоры об импортозамещении в последние 20 лет — они не про достижение цифрового суверенитета, а про то, чтобы нужные люди заработали себе лишнюю копеечку.
Впрочем, имеем опять 25 — ссылки на деньги там, где не делается даже бесплатного.
V>Любой ноут справляется с любой "нормальной IDE", если это не солюшен на 50+ проектов.
Совершенно верно. И все эти ноуты — на x86. Ну, или на M1, если студент помоложе
V>Эльбрусу пофик, это ж Linux. V>Например, сетевой диск монтируется локально как родной, IDE может исполняться локально, а компиляться и отлаживать код может удалённо и еще сверху миллион комбинаторных комбинаций конфигурирования.
Ну, удалённая компиляция — это рудимент парадигмы "где гоняю, там и компиляю". Ведь совершенно необязательно запускать компилятор на ARM для построения приложения под ARM .
А удалённая отладка — да, отчего нет. Нормальный вариант. То есть нужно какое-то облако, публичное либо приватное, к которому имеет доступ академическая общественность. V>Мы можем только сделать людям любопытно и смотреть, что из этого выйдет.
Кто такие "мы"? Лично я ничего сделать не могу — я к руководству МЦСТ отношения не имею. Всё, что я могу — трепаться на форумах, в надежде, что кто-то из инженеров МЦСТ сюда заходит, и сможет донести до руководства мысль о взаимодействии с Open Source и привлечении академической среды.
V>Хотелось бы примеров.
Я привёл. V>Потому что история показывает ровно обратное.
Напрмер, где?
S>>Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
V>И как только допилили до работоспособности — ррраз, и уехало. V>Десяток лет, Карл!
Вы не туда смотрите. Разработка — это одно. Она и тридцать лет может вестись. Инерция — это когда готовое решение игнорируют.
Тем временем, вы сами пишете: "как только допилили до работоспособности — ррраз, и уехало."
Точно так же и тут — если у Эльбруса будут какие-то преимущества, то он захватит рынок в считанные годы.
V>Самое забавное, что в Windows аналогичные технологии были готовы лет на ~8 раньше, но жадность фраера сгубила.
Даже интересно, что за технологии, готовые в 1995 году. V>Все облака давно могли бы крутиться на виндах еще до середины нулевых... но тогда был слишком триумф Windows, поэтому они гордо просрали все полимеры. S>>Или там — вот у нас суперновый чип A1
V>Архитектура ARM зато не суперновая. V>
V>Apple Newton или просто Newton — одна из первых серий карманных персональных компьютеров, которая разрабатывалась, производилась и продавалась фирмой Apple Computer. Apple начала разработку платформы в 1987 году и выпустила первые устройства в августе 1993 года.
V>...
V>Большинство компьютеров Newton работали на RISC-процессоре ARM 610.
S>>экзотический язык программирования и среда разработки
V>Objective-C экзотический? Ты с какой Луны к нам свалился, что ты делаешь на этом сайте? )) V>На моей памяти — весьма популярный язык, т.к. C++ еще не был вменяемым в те годы.
V>Под маками на Objective-C написано чуть более чем всё с 80-х, когда Джобс основал NeXT, а потом принёс эти наработки в 90-х в Apple.
Под маками
V>Для справки — многие игры под DOS (взять тот же Doom) разрабатывались в среде NeXT.
S>>и хооп!
V>Да не было никакого хооп, что за буйные фантазии? )) V>Был iPod + iTunes с 2001-го, потом Apple TV.
В 2001 iPod был обычным mp3-плеером, безо всякой экосистемы приложений.
Первая возможность засунуть в него что-то помимо прошивки появилась в 2006 году. SDK для него вообще так и не был опубликован.
AppStore с его возможностями заретрофиттили в айподы уже после выхода iPhone. RTFM.
V>В общем, инфраструктура платного распространения ПО и контента не взялась с потолка, а долго рожалась и отлаживалась.
AppStore появился в 2007 году и практически мгновенно, по историческим меркам, произвёл бум.
S>>сотни тысяч программ в аппсторе, миллиарды оборота.
V>Ты подумал, что это написано с 0-ля или как понимать этот тон?
Конечно с нуля. V>С другой стороны, твой код не протухает десятилетиями.
Ну, расскажите мне, какое из iOS приложений было взято из "непротухающего десятилетиями" кода в каком-нибудь, скажем, 2010 году?
V>Вы даже плохо представляли, в чём она заключается, какие задачи решаются.
Вот опять пошли оскорбления. Я крайне сочувствую вашей недооценённости по основному месту работы, а также детским психологическим травмам и всему такому.
Но на публичный-то форум это всё зачем тащить?
V>И отчего же Интел была вынуждена похоронить многомиллиардный Itanium?
Повторюсь: оттого, что не потянула компилятор, способный обеспечить итаниуму преимущества.
Ровно то, что вы считаете для эльбруса само собой разумеющимся.
V>Ключевое было про топовость.
И? V>Надёжность подойдёт?
Вряд ли. Для неё придётся как-то обосновать ненадёжность конкурентов. Ну, то есть идиотам можно попытаться рассказать про Spectre и Meltdown. Но взрослые-то люди понимают, что на стороне Интела и АМД как раз десятилетия работы и активного поиска таких дыр. А на стороне Эльбруса будет только "мамой клянус, у нас meltdown невозможен".
V>Или больше безопасности.
Та безопасность, которая интересует коммерческого пользователя, у конкурентов уже есть. А все рассуждения про "зато у нас точно нет закладок от АНБ" разбиваются о три вопроса:
1. А вы уверены, что в Интеле они есть?
2. А вы уверены, что у вас нет закладок от ФСБ?
3. А вы уверены, что у вас нет закладок от китайцев, которые собственно печатают ваши чипы?
V>Т.е., наблюдается забавная тенденция — новички валят на облака ажура или aws, а потом, поняв, что к чему, потихоньку валят на альтернативы.
А где конкретно можно эту тенденцию посмотреть? А то вот, к примеру, наша маленькая конторка с сорокамиллиардными оборотами живёт в Azure. V>В Азии, к примеру, растут десятки своих крупных игроков и цены там приятней. V>Сравнивать доли облачных вычислений надо не в долларах, а в объёмах вычислений.
Я не против. Не вижу этой картинки, но поверю вам на слово. Тем более, что вы подтверждаете то, о чём я говорю ниже.
V>Да и, учитывая современные ср-ва разворачивания и управления облаками, нет более никаких причин держатся за единицы монополистов: V>https://www.cnews.ru/reviews/oblachnye_servisy_2022/interviews/mihail_solovev
Пеар — штука хорошая. Но полагаться на него в анализе долей рынка не стоит V>https://e.huawei.com/ru/solutions/industries/isp/full-stack-cloud-services
Ну так я об этом и говорю — клиенты уйдут от ненадёжных заказчиков, но не к Эльбрусу, а к Хуавей и прочим парням, которые могут обеспечить эффект масштаба.
V>И это прекрасно.
Это было бы прекрасно при наличии хоть какого-то понимания этого упора со стороны ответственных лиц и принятия соответствующих мер.
Запросто может так оказаться, что в 2032 году мы на этом же форуме будем обсуждать то, каких высот можно было бы достичь Эльбрусом, если бы в 2022 была выделена хотя бы пара миллиардов рублей МЦСТ.
V>Это смотря какими пользователями, какой план/тарифы.
Дело не в тарифах, а в архитектуре.
V>Я говорил про поточный параллелизм, который не в пересчёте на ядро. V>С ядрами в разрабатываемых Эльбрусах всё складывается неплохо — в этой архитектуре делить общую память могут 4 кристалла.
И? V>Такой вариант, что норма прибыли оператора будет заложена в разы меньшая, ты не рассматривал?
Нет, потому что этот вариант доступен любому оператору. Если вы намекаете на то, что будет государственно-субсидированное облако — то шансов примерно ноль. Денег на это не дадут.
V>Я рассказываю это тем, кто всю свою карьеру далёк от эффективных вычислений.
V>Эльбрусы делают за счёт минторга, если что.
Откуда дровишки?
В 2021 году Минпромторг отклонил несколько десятков проектов, претендующих на выдачу госсубсидий, которые поступили от «Микрона», МЦСТ, НПЦ «Элвис», ПК «Авариус», Концерна «Созвездие», НПП «Пульсар», «Русатом Автоматизированные Системы Управления», НПП «Элар», ЦНИИ «Электрон» и т.д
V>Ну еще пара министерств, а так никто.
Это в теории. Практика где?
V>Так ты и Objective-C не наблюдал, для тебя это "экзотика", хотя по-факту — обычная экосистема маков.
Вы же сами признали, что нужен доступ к эльбрусам для ВУЗов. На практике я работаю в одном из топ-10 вузов по IT в РФ; у нас нет ни железки, ни эмуляторов.
По словам самих МЦСТ у них есть там где-то в Москве пара кафедр с машинками. Ну, то есть в академических кругах эльбрусами занимается полтора инвалида.
У вас есть какие-то факты, опровергающие эти наблюдения? Или вы опять вошли в режим "я думаю, что так лучше — значит так и есть"?
V>Компилятор давно написан и постоянно обновляется. V>На сегодня есть полная поддержка стандарта С++14, идёт дальнейшее развитие компилятора.
Кто напишет JIT? Вы тут в соседней ветке предлагали взять исходники CoreCLR и скомпилировать их под Эльбрус )
Я надеюсь, вы не думаете, что от этого RyuJIT внезапно научится порождать эльбрусовские команды?
V>Потому что SIMD — это костыль для убогих технологий прошлой эпохи. Убедительно. Но хотелось бы каких-то более конкретных аргументов.
V>Тогда бы ты не писал то, что писал.
Нет.
V>Особенность компилятора под Эльбрус в том, что он лучше оригинального gcc умеет выполнять полную оптимизацию, т.е. использовать технику LTO, т.е. в том числе "замыкать" на уровне бинарного модуля видимость данных и преобразовывать их для достижения лучшей производительности. С включённой техникой LTO одни и те же тесты порой выполняются до 5 раз быстрее — инлайн для VLIW рулит. Неплохие результаты показывается так же PGO. Неплохие в сравнении с традиционными архитектурами.
S>>Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
V>Эхх... V>Потрать как-нить пол-часа: V>http://www.mathnet.ru/links/338dc4eb1150dfc71b46111cd7cb9410/itvs662.pdf V>
V>... коды одной платформы попадают в динамический оптимизатор другой платформы для обеспечения полной программной совместимости. Этот
V>подход лучше всего реализуется на архитектурах с явным параллелизмом команд и с аппаратной поддержкой процесса двоичной трансляции. Дополнительным преимуществом динамической трансляции является возможность легко преодолевать межпроцедурные и межмодульные границы, выполняя тем самым мощный класс межпроцедурных оптимизаций. В ОДТЭ благодаря адаптивной оптимизации и достаточно хорошей аппаратной поддержке удается выполнять программы, исполняющиеся существенно быстрее, нежели на исходной платформе при той же тактовой частоте.
Спасибо, очень интересно.
V>Происходит перенос на фабрики Китая. V>Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии. V>Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.
Боюсь, это не последнее неверное решение на этом пути.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alpha21264, Вы писали: A>>Что "статистика реального выполнения"? A>>Как ты думаешь, что такое "статистика реального выполнения", S>Например, паттерны срабатывания условных переходов.
К VLIW-у не имеет никакого отношения. VLIW имеет точно такой же кэш переходов как CISC и RISC.
A>>и как она может повлиять на работу процессора и распараллеливание команд? S>Она напрямую влияет на наполнение конвеера. Распараллеливание команд в суперскаляре напрямую зависит от конвеера — последовательные независимые команды скармливаются независимым исполняющим блокам и исполняются параллельно.
И тут VLIW имеет явное преимущество. Для него всё сделал компилятор и он не тратит на это время.
A>>Ты что думаешь, что необходимые действия для вычислений как-то со временем меняются? S>Меняется статистика вычислений. Даже одна и та же команда с одими и теми же аргументами потребует различного времени исполнения в зависимости от того, в каком из кэшей лежит нужное ей значение.
Это может сказаться только на команде LOAD. Остальные команды берут данные из регистров.
Наверное Out of Order может сколько-то команд (не зависящих от этих данных) протолкнуть в конвейер.
Только во VLIW они уже протолкнуты на этапе компиляции.
S>В суперскаляре это не проблема — ну просто конкретно этот блок будет занят на этот раз чуть дольше. На следующем проходе цикла раскладка команд по таймингам и блокам поменяется. S>А уж если у нас есть какие-то ветвления, то всё бывает очень по-разному. Вложенные циклы по "узкой и высокой" матрице ведут себя не так, как по "широкой и низкой".
Ещё раз повторю, что с точки зрения предсказания переходов VLIW не отличается от CISC и RISC.
Здравствуйте, alpha21264, Вы писали:
A>И тут VLIW имеет явное преимущество. Для него всё сделал компилятор и он не тратит на это время.
А компилятор знал заранее латентности загрузки? A>Это может сказаться только на команде LOAD. Остальные команды берут данные из регистров.
Хм. То есть на эльбрусе нет команд регистр-память? Ну, это конешно здорово, но не меняет общей проблемы, когда задержка в одном из LOAD тормозит выполнение всего "конвеера", который уже упихан в VLIW слово.
A>Наверное Out of Order может сколько-то команд (не зависящих от этих данных) протолкнуть в конвейер.
Может и проталкивает. A>Только во VLIW они уже протолкнуты на этапе компиляции.
Вопрос, лучше это или хуже.
A>Ещё раз повторю, что с точки зрения предсказания переходов VLIW не отличается от CISC и RISC.
Ну, хорошо, коли так.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mDmitriy, Вы писали:
V>>Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии. D>прикольно, что все дифирамбы отечественному процессору свелись к тому что надо лечь под Китай
Apple, AMD, NVidia лежат под Китаем и не жалуются.
V>>Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус. D>ну, Хуавей, конечно, кто же еще
Один из лидеров китайского IT.
Насчёт "изгой" — это ты хорошо подлизнул. ))
Здравствуйте, 4058, Вы писали:
4>Раз речь зашла про 10 лет, давайте "в лоб" сравним производительность какого-нибудь процессора Ivy Bridge (2012) с Alder Lake (2022):
Давай лучше сравним архитектуру.
4>Частота в boost-е подросла на 1 Ггц
Т.е. за 10 лет частота выросла на 25% всего?
4>при этом производительность одного (полноценного) ядра почти в 2 раза.
Т.е. производительность ядра на той же частоте выросла всего на 60%, верно?
На самом деле верно, средняя производительность на ядро при той же частоте как раз выросла примерно на 60%, при этом часть добавочной производительности вовсе не заслуга ядра, а обновлённого IO, в т.ч. общения с RAM.
4>Да и самих ядер стало в 2-3 раза больше.
Только ядра всё те же.
Развитие с 2012-го шло, скажем так, экстенсивно/количественно, а не качественно:
— другой контроллер памяти;
— появились процы с большим кол-вом портов PCIe более новых стандартов;
— увеличили размеры внутренней кеш-памяти, расширили окно анализатора ОО- и спекулятивного исполнения, увеличили кеш меток предсказателя переходов;
— соответственно добавили вычислительных блоков, но только в топовые процы;
— улучшали встроенную графику.
Но про смену кучи поколений — фейк.
Для примера, у Эльбруса, действительно, происходила честная смена поколений при каждой разработке новой версии.
Как и у Интела когда-то.
4>Согласно той-же статье из вики: 4>[b]Получение инженерных образцов планировалось в 2025 году.
В 2022-м.
В вики уже обновлённые данные, когда уже подзадержались с Эльбрусом 16с в 2019-м.
Надо было принимать предложение Хуавея, Тайвань динамит всю дорогу.
4>Т.е. всё-таки это новости из очень далекого и туманного "завтра".
Это из-за переноса сроков.
Срок выпуска 16с перенесён примерно на полтора года, сейчас заметные ресурсы компании, увы, заняты его адаптацией под другой техпроцесс.
32с в модели готов, отлаживается, но до железа теперь ему дальше, чем планировалось.
Потому что в "импортозамещение" надо было играть или по-взрослому, или никак.
4>Лично мне импонирует, что в Эльбрусах осознанно частоты не задирают, ибо изначально они планировались для бесперебойного использования в "неблагоприятных" условиях. В остальном тяжело уже как-то в 20х годах 21-го века обсуждать достоинства и недостатки VLIW.
Правильенй будет EPIC.
И почему тяжело-то?
Предел развития суперскаляров был виден самой же Intel еще в конце 90-х, когда они разрабатывали 4-й пень, который работал на многих задачах хуже 3-го пня в пересчёте на частоту на ядро. Отсюда Itanium, который был похерен AMD через продление агонии x86-й архитектуры. ))
4>P.S. Отдельно удивляет импортозамещенческая активность только вокруг CPU, хотя нужна еще как минимум своя оперативка и накопители.
Потому что x86 и ARM-ы могут в любой момент быть закрыты западными санкциями и мы можем остаться без процов.
Поэтому и продолжают у нас развивать MIPS, SPARC и Эльбрус.
Первый для контроллеров, второй для чего-то некритичного к вычислениям, последний — серьёзная числомолотилка.
Оперативку-накопители делают где угодно сегодня, т.е. Запад этот краник не перекроет при всём своём желании.
Здравствуйте, vdimas, Вы писали:
V>И мой многолетний, хотя одному из сыновей я дал год назад совет продолжать работать в МЦСТ (разрабатывает этот проц), т.к. достойная реализация этой темы просто неизбежна, у РФ нет другого выхода.
Это довольно спорное заявление. Эльбрус совсем не безальтернативен. Есть тот же RISC-V, у которого, как минимум, уже есть несколько альтернативных реализаций и вполне нормальная публичная спека.
Здравствуйте, Sinclair, Вы писали:
S>Дело не в том, сколько миллиардов. Даже если прямо сейчас правительство России единомоментно выделит Бабаяну триллион долларов в рублёвом эквиваленте, это не приведёт по мановению волшебной палочки к появлению 3nm-чипов.
Чтобы получить чипы, нужно строить фабрику. Это к Бабаяну не имеет никакого отношения.
Бабаян делает логику процессора. И хорошо, что он закрывает этот участок работ.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Эльбрус совсем не безальтернативен. Есть тот же RISC-V, у которого, как минимум, уже есть несколько альтернативных реализаций и вполне нормальная публичная спека.
Да, у нас этой архитектурой тоже кто-то занимался (лень искать).
Но это уровень SPARC или MIPS64, т.е. дополнение к парку камней, а не замена их на всех задачах.
Еще архитектура RISC-V относительно новая, а SPARC у нас достаточно проработан и развит до новых поколений (развит только в РФ).
Если последить за тендерами, последние годы идут заказы на радиолокационные системы нового поколения от военных.
И почему-то предлагают в кач-ве решения однокристалку с парой ядер Эльбруса и дополнительными DPS-блоками на борту, а не SPARC или MIPS.
Там же фазированные решетки, сплошное БПФ и прочая корреляция в жёстком реалтайм.
Здравствуйте, vdimas, Вы писали:
V>Apple, AMD, NVidia лежат под Китаем и не жалуются.
похоже, вы не понимаете значения термина "лежат"
от слова совсем
во всяком случае, Китаю будет гораздо проще при необходимости закрыть у себя всю возню вокруг Эльбруса, чем Тайваню
V>Один из лидеров китайского IT.
вам рассказать в каких областях он изгой или сами найдете? V>Насчёт "изгой" — это ты хорошо подлизнул. ))
мне непонятно ваше возбуждение по поводу этого слова, придумал его для той ситуации не я
либо вы не знаете отечественной истории, либо вы не поняли контекста, либо и то, и другое
Здравствуйте, vdimas, Вы писали:
V>Т.е. за 10 лет частота выросла на 25% всего?
... V>Т.е. производительность ядра на той же частоте выросла всего на 60%, верно?
Немного больше, но не суть.
V>На самом деле верно, средняя производительность на ядро при той же частоте как раз выросла примерно на 60%, при этом часть добавочной производительности вовсе не заслуга ядра, а обновлённого IO, в т.ч. общения с RAM.
Если так рассматривать, то по сути до сих пор ничего не изменилось с момента появления Sandy Bridge.
V>Предел развития суперскаляров был виден самой же Intel еще в конце 90-х, когда они разрабатывали 4-й пень, который работал на многих задачах хуже 3-го пня в пересчёте на частоту на ядро. Отсюда Itanium, который был похерен AMD через продление агонии x86-й архитектуры. ))
Убогоархитектурный P4 позволял по быстрому прощупать пределы тактовых частот, которые потом долгое время придётся использовать.
IA-64 уступал по производительности AMD64, поэтому смысла в его существовании дальше не было.
V>Потому что x86 и ARM-ы могут в любой момент быть закрыты западными санкциями и мы можем остаться без процов.
Ничего особо не мешает штамповать клоны x86 и ARM по устаревшим ТП на маленьких заводиках в Китае, да и наличие т.н. "параллельного импорта" исключает возможность совсем остаться без процов, поставки только сократятся, и ценник будет выше, но всё-равно это дешевле, чем делать свою архитектуру и так-же её производить на маленьких заводиках в Китае.
V>Поэтому и продолжают у нас развивать MIPS, SPARC и Эльбрус. V>Первый для контроллеров, второй для чего-то некритичного к вычислениям, последний — серьёзная числомолотилка.
По поводу серьёзных числомолотилок был показательный перформанс от IBM в 2006+, когда на рынок вышли XBox 360 и PS3, у первого был проц на базе PowerPC с 3-мя полноценными ядрами (PPE — 2 потока на ядро на частоте 3.2), у другого был проц с 1-м полноценным ядром (тоже PPE), и 6+ числодробильных ядер SPE на частоте 3.2, примечательно что:
... первоначально инженеры из IBM пытались при создании SPE следовать канонам VLIW, однако столкнулись с серьезными проблемами и вернулись к уже хорошо обкатанной архитектуре SIMD-сопроцессора Altivec/VMX.
Так вот, почти весь жизненный цикл этих консолей (7 лет) разработчики под PS3 пытались раскрыть тот самый потенциал SPE, но удавалось это только в единичных случаях (и при активном участии со стороны Sony/IBM), а основной ширпотреб (кроссплатформа) была в пользу XBox 360, в основном за счёт сложностей связанных с использованием SPE.
Здравствуйте, mDmitriy, Вы писали:
V>>Apple, AMD, NVidia лежат под Китаем и не жалуются. D>похоже, вы не понимаете значения термина "лежат"
Улыбнуло.
Ликбез:
Джобс объяснял Обаме примерно 4 часа, почему невозможно перенести производство Айфона из Китая в США.
D>во всяком случае, Китаю будет гораздо проще при необходимости закрыть у себя всю возню вокруг Эльбруса, чем Тайваню
Ликбез:
Китай класть хотел на США.
Т.е. оружием особо не бряцает, но и на угрозы в свой адрес демонстративно кладёт.
Ты этого не понимаешь от слова совсем. (С)
V>>Один из лидеров китайского IT. D>вам рассказать в каких областях он изгой или сами найдете?
Ты можешь рассказать только свои эротические фантазии.
А вот как обстоят дела в реальности:
По данным аналитической компании Canalys, в четвёртом квартале прошедшего года компания Huawei сохранила свои лидирующие позиции на китайском рынке с долей в 22%.
...
Замыкают пятёрку лидеров китайского рынка компания Apple с 15.3 млн проданных смартфонов и долей 18% и компания Xiaomi с 12.2 млн проданных устройств и долей 15%.
Samsung уступила лидерство Huawei. Доля корейского гиганта на китайском рынке премиальных телевизоров упала вдвое за два года.
Насчёт санкций по 5G — были введены антисанкции, теперь там не будет американского 5G.
США потеряли намного больше, бо рынки США и Китая несравнимы, бгг...
Теперь на самом большом рынке планеты изгоем выступают США.
V>>Насчёт "изгой" — это ты хорошо подлизнул. )) D>мне непонятно ваше возбуждение по поводу этого слова, придумал его для той ситуации не я
Возбуждение разве что смехом над убогими, анонирующими на прошлое величие англосаксов.
D>либо вы не знаете отечественной истории, либо вы не поняли контекста, либо и то, и другое
У меня другая версия — такие как ты могут только ползать и лизать.
Понимать тут нечего, бо эти позывы всегда иррациональны, бгг...
Тогда и производительность будет дефолтная. 
)
