=AlexD= (19.06.2023 10:16, просмотров: 141) ответил Evgeny_CD на Реквием по ЭльбрусуЭто моё личное предвзятое мнение. Любое совпадение с реальностью является случайным и непреднамеренным.
-
- Как и всякий VLIW, Эльбрус является тупиком. Это не страшно само по
себе, если вовремя осознать и принять меры. Но вместо этого МЦСТ
накрылся одеялом и пилит миллиарды на этом тупике. - Evgeny_CD(19.06.2023 11:12)
- Процессор сделан, так значит надо его использовать. По-хозяйски
отнестись к делу. Оставить небольшую группу для сопровождения и
баги отлавливать. Копирование/производство относительно дёшего,
когда уже есть готовый образец и даже серия рабочая. - Costic(19.06.2023 15:46)
- Почти верно. Но TSMC по приказу фашингтона решила, что нет у нас
Эльбруса. И все. Таки и вправду нет :( - Evgeny_CD(19.06.2023 15:50)
- Байкал делался на том же TSMC. - _volkanaft_(20.06.2023 10:32)
- Почти верно. Но TSMC по приказу фашингтона решила, что нет у нас
Эльбруса. И все. Таки и вправду нет :( - Evgeny_CD(19.06.2023 15:50)
- В чём этот тупик состоит? почему динамический "предсказатель"
тупиком не является, а статический (на этапе компиляции) является?!
... на определённом круге задач это, само по себе, не плюс и не
минус. А кристалл при этом делает "легче"! - _volkanaft_(19.06.2023 12:07)
- Многозадачка плюс обвязка чипа (всякие там кэши, канальность
памяти, прерывания какие-то). Это невозможно обсчитать при
компиляции, но возможно статистически учесть в рантайме. - LightElf(19.06.2023 12:25)
- Ну так не надо пихать VLIW направо и налево! В машины общего
назначения. А на большом классе задач VLIW себя хорошо показывает.
... В частности шлю вам эти горестные строки с помощью процессора
VLIW! ( Qualcomm Hexagon ). :-) - _volkanaft_(19.06.2023 13:01)
- Нет. Пишешь ты на ARM под Android, а кто там сопроцессор - это
вторично. - Evgeny_CD(19.06.2023 13:17)
- Так я и написал : "шлю".:-) _volkanaft_(62 знак., 19.06.2023 13:53)
- Нет. Пишешь ты на ARM под Android, а кто там сопроцессор - это
вторично. - Evgeny_CD(19.06.2023 13:17)
- Ну так не надо пихать VLIW направо и налево! В машины общего
назначения. А на большом классе задач VLIW себя хорошо показывает.
... В частности шлю вам эти горестные строки с помощью процессора
VLIW! ( Qualcomm Hexagon ). :-) - _volkanaft_(19.06.2023 13:01)
- Многозадачка плюс обвязка чипа (всякие там кэши, канальность
памяти, прерывания какие-то). Это невозможно обсчитать при
компиляции, но возможно статистически учесть в рантайме. - LightElf(19.06.2023 12:25)
- сама по себе парадигма VLIW не тупик, просто такая архитектура
заточена под определённые задачи. На специализированных алгроитмац
ЦОС VLIW "сильно спереди" :) Где-то даже впубликовали тесты, ну и
говорили что на так :) В ощем-то всякие AVX в интелах не спешать
искоренять. Нужно просто делать это расширением, а саму
архитектуру, кмк, брать а-ля RISC с высокими тактовыми частотами
ихорошей оптимизацией конвейеров. - Adept(19.06.2023 11:42)
- VLIW не может стать "просто расширением" RISC из за принципиально
иной требуемой архитектуры шин. - my504(19.06.2023 11:58 - 12:10)
- Cadense Xtensa - в базе - простенький RISC, а сделанный из него
HiFi4 DSP - VLIW. Каг жыдь? - LightElf(19.06.2023 12:23)
- Сделать "из него" можно что угодно. VLIW уже не RISC. Может я чего
то не понимаю, но идеология RISC противоречит длинным инструкциям. - my504(19.06.2023 12:29)
- Современный RISC != RISC из учебника. Aarch64: 2500+ команд. Нихера себе reduced command set. - Evgeny_CD(19.06.2023 15:48)
- x86 тоже совсем не RISC снаружи. но внутри, грят, всё как раз очень на RISC позхоже. Ничто не мешает сделать на кристалле либо второй CPU/FPU специально для VLIW или сделать частично реконфигурируемую архитектуру под VLIW команды (навряд ли можно сделать динамически меняющуюся эффективную архитертуру, на гигагерцовых частотах уже за каждый блок битва будет, и как известно универсальные инструменты завсегда хуже специализированных) - Adept(19.06.2023 12:40)
- Почему? Простая RISC-инструкция может быть префиксом "дальше 100500
байт VLIW команды". А может не быть. - LightElf(19.06.2023 12:32)
- Дело ведь не только в длине команды. Нужен многоканальный доступ к
ОЗУ. Под VLIW нужно писать на АСМе. Компилятор ничего не знает про
многоэтажную конструкцию длинных команд. Поэтому от RISC там ничего
не остается. Во VLIW-процессорах ведь не все команды длинные. - my504(19.06.2023 12:42)
- Почему это "компилятор ничего не знает"? Надо ему разъяснить
политику партии, йащетаю! А без шуток - есть пример
Tensilica/Cadense. Где к RISC ядру прикручивается черта лысого и
VLIW впридачу. И компилятор под это безобразие - тоже есть. - LightElf(19.06.2023 12:45)
- Всегда было интересно как компилятор отличит алгоритм "бабочки" от
простого умножения и суммы. В каком месте Си есть инструменты
предвыборки. В смысле как указать компилятору о чем вообще идет
речь. До сих пор я видел только библиотеки написанные на АСМе или
на встроенных функциях, что одно и тоже. - my504(19.06.2023 12:50)
- __builtin_prefetch() это нужно? aнтинoвocти2(1 знак., 19.06.2023 13:01, ссылка)
- Это как с HAL. Вместо того, чтобы писать на АСМе, нужно будет
разбираться в куче встроенных функций с их опциями, аргументами и
прочей хренью. То есть менять шило на мыло. Нет уж, свят, свят.
свят... Изыди, сОтона... )))) - my504(19.06.2023 13:06)
- А на АСМе не нужо знать про работу КЭШей, памяти, механизмов
синхронизации между ядрами? Вопрос: будет ли отличаться
"производительность" (в циклах) двух и более потоков, выполняющихся
на разных ядрах CPU, пишущих (пусть мусор) в одну и туже ячейку
пямяти, или в разные, находящиеся в разных КЭШ линиях? - aнтинoвocти3(19.06.2023 13:17,
)
- Какое отношение это имеет к VLIW? - my504(19.06.2023 13:56)
- Думаю, будут. В первом случае будет коллизия, на ее разруливание
уйдут такты. - Evgeny_CD(19.06.2023 13:26)
- Вот и получается, у каждой архитектуры/платформы есть ньюансы, и
если хочется выжать максимум, их надо учитывать aнтинoвocти3(1 знак., 19.06.2023 13:40,
, ссылка)
- Вот и получается, у каждой архитектуры/платформы есть ньюансы, и
если хочется выжать максимум, их надо учитывать aнтинoвocти3(1 знак., 19.06.2023 13:40,
- А на АСМе не нужо знать про работу КЭШей, памяти, механизмов
синхронизации между ядрами? Вопрос: будет ли отличаться
"производительность" (в циклах) двух и более потоков, выполняющихся
на разных ядрах CPU, пишущих (пусть мусор) в одну и туже ячейку
пямяти, или в разные, находящиеся в разных КЭШ линиях? - aнтинoвocти3(19.06.2023 13:17,
- Это как с HAL. Вместо того, чтобы писать на АСМе, нужно будет
разбираться в куче встроенных функций с их опциями, аргументами и
прочей хренью. То есть менять шило на мыло. Нет уж, свят, свят.
свят... Изыди, сОтона... )))) - my504(19.06.2023 13:06)
- __builtin_prefetch() это нужно? aнтинoвocти2(1 знак., 19.06.2023 13:01, ссылка)
- Всегда было интересно как компилятор отличит алгоритм "бабочки" от
простого умножения и суммы. В каком месте Си есть инструменты
предвыборки. В смысле как указать компилятору о чем вообще идет
речь. До сих пор я видел только библиотеки написанные на АСМе или
на встроенных функциях, что одно и тоже. - my504(19.06.2023 12:50)
- Почему это "компилятор ничего не знает"? Надо ему разъяснить
политику партии, йащетаю! А без шуток - есть пример
Tensilica/Cadense. Где к RISC ядру прикручивается черта лысого и
VLIW впридачу. И компилятор под это безобразие - тоже есть. - LightElf(19.06.2023 12:45)
- Дело ведь не только в длине команды. Нужен многоканальный доступ к
ОЗУ. Под VLIW нужно писать на АСМе. Компилятор ничего не знает про
многоэтажную конструкцию длинных команд. Поэтому от RISC там ничего
не остается. Во VLIW-процессорах ведь не все команды длинные. - my504(19.06.2023 12:42)
- Сделать "из него" можно что угодно. VLIW уже не RISC. Может я чего
то не понимаю, но идеология RISC противоречит длинным инструкциям. - my504(19.06.2023 12:29)
- Были более здравые идеи. Часть ядер RISC, часть VLIW. Но победила
религия Эльбруса. - Evgeny_CD(19.06.2023 12:02)
- Насколько я знаю, НТЦ "Модуль" именно так и делает. Отдельно ARM
ядра, отдельно Neuro. Ситуация сходная. - my504(19.06.2023 12:09)
- NeuroMatrix - это отдельная история. Крутая штука, но есть ли
компилятор? Evgeny_CD(1 знак., 19.06.2023 12:57, ссылка)
- Полагаю, что как и в случае с DSP VLIW это будет НЕ Си. Главное -
создать эффективные интерфейсы подключения к традиционным
программам, я так понимаю. Просто из-за маргинальности таких
компиляторов они будут стоить невменяемых денег. - my504(19.06.2023 13:03)
- Мы получили шикарную ПОС. VLIW эффективен для ограниченного круга
задач. Компилятор для него либо кривой и косой, либо стоит
неадекватных денег, что приводит к схлопыванию даже его родных ниш. - Evgeny_CD(19.06.2023 13:15)
- Есть выход для ограниченного круга задач. Писать критические
участки кода на АСМе. Выигрыш столь велик, что никакой RISC за ним
не угонится. Кратно выше скорость. - my504(19.06.2023 13:58)
- И мы получаем RISC + SIMD, эта связка и побеждает в нашем мире IRL. - Evgeny_CD(19.06.2023 14:14)
- VLIW - это Xtensa Hi-Fi, Qualcomm Hexagon и TI C66x/C7000. Все живы
и здравствуют. Но никто не пытается запускать прикладное/серверное
ПО. Они используются только как ускорители вычислений. - lloyd(19.06.2023 14:12)
- Тут проблема курицы и яйца. Нет высокопроизводительных VLIW процов,
потому никто под них не точит прикладной софт. А в отсутствии
VLIW-оптимизированного софта никто не хочет делать VLIW-процы
высокой производительности. Т.е. Эльбрусу бы взять какой SQL-сервер
и не просто портировать, а заточить под свой камень до блеска. Хоть
на асме. Шоб он всех рвал как тузик грелку. И собрать сие в
монобинарь с кусками линуксячего ядра (такое существует - не помню
как проект называется). И LightElf(47 знак., 19.06.2023 16:00)
- Бочка дерьма в ложку меда. Хранимые процедуры. На пытоне или жабаскрыпте. И писец, приплыли. Нужна не просто БД, а JS JIT под Эльбрус, и оптимизированный питонячий стек. Наша шарашка начинает напоминать небольшой город типа Долгопрудного. - Evgeny_CD(19.06.2023 16:16)
- Шарашки. Шарашки нужны. Без них не получится. Толковые спецы по БД стоят взрослых денег, и их почти нет на рынке. Все устроены. А так план прекрасен! - Evgeny_CD(19.06.2023 16:12)
- +1. TI OMAP - классика архитектуры ARM + DSP как ускоритель. - Evgeny_CD(19.06.2023 15:56)
- Вооот! И я о том. Такие процессоры сильно дешевле FPGA реализующего тот же функционал. - my504(19.06.2023 14:20)
- Тут проблема курицы и яйца. Нет высокопроизводительных VLIW процов,
потому никто под них не точит прикладной софт. А в отсутствии
VLIW-оптимизированного софта никто не хочет делать VLIW-процы
высокой производительности. Т.е. Эльбрусу бы взять какой SQL-сервер
и не просто портировать, а заточить под свой камень до блеска. Хоть
на асме. Шоб он всех рвал как тузик грелку. И собрать сие в
монобинарь с кусками линуксячего ядра (такое существует - не помню
как проект называется). И LightElf(47 знак., 19.06.2023 16:00)
- Есть выход для ограниченного круга задач. Писать критические
участки кода на АСМе. Выигрыш столь велик, что никакой RISC за ним
не угонится. Кратно выше скорость. - my504(19.06.2023 13:58)
- Мы получили шикарную ПОС. VLIW эффективен для ограниченного круга
задач. Компилятор для него либо кривой и косой, либо стоит
неадекватных денег, что приводит к схлопыванию даже его родных ниш. - Evgeny_CD(19.06.2023 13:15)
- Полагаю, что как и в случае с DSP VLIW это будет НЕ Си. Главное -
создать эффективные интерфейсы подключения к традиционным
программам, я так понимаю. Просто из-за маргинальности таких
компиляторов они будут стоить невменяемых денег. - my504(19.06.2023 13:03)
- NeuroMatrix - это отдельная история. Крутая штука, но есть ли
компилятор? Evgeny_CD(1 знак., 19.06.2023 12:57, ссылка)
- Насколько я знаю, НТЦ "Модуль" именно так и делает. Отдельно ARM
ядра, отдельно Neuro. Ситуация сходная. - my504(19.06.2023 12:09)
- Cadense Xtensa - в базе - простенький RISC, а сделанный из него
HiFi4 DSP - VLIW. Каг жыдь? - LightElf(19.06.2023 12:23)
- VLIW не может стать "просто расширением" RISC из за принципиально
иной требуемой архитектуры шин. - my504(19.06.2023 11:58 - 12:10)
- Еще раз. Байкал-С против Эльбруса 16С. Одинаковый техпроцесс
(16нм), почти одинаковая площадь кристалла. На Linpack Байкал
быстрее в 2.5 раза. Т.е. даже в сфере числомолотилок он качественно
сливает современным процессорам. - Evgeny_CD(19.06.2023 11:15)
- Помнится, был такой процессор Cyrix MII, тоже показывал много
"попугаев". ;-) - Costic(19.06.2023 15:51)
- Я уже забыл историю. Там было какое-то наипалово... - Evgeny_CD(19.06.2023 15:58)
- А МЦСТ до сих пор компилятор на LLVM не перевела? Все так же с LCC
страдает? - LightElf(19.06.2023 12:00)
- У МЦСТ очень мало людей сейчас. Ядро высосало всех толковых. Все, кто остался - кадровый отстой :( - Evgeny_CD(19.06.2023 15:52)
- А вот тут пышуть, что не все так однозначно. Врут поди. max(1 знак., 19.06.2023 11:21, ссылка)
- Читаем каменты. Они подобрали задохлика Intel и методику тестирования. Мухляж. - Evgeny_CD(19.06.2023 11:31)
- Помнится, был такой процессор Cyrix MII, тоже показывал много
"попугаев". ;-) - Costic(19.06.2023 15:51)
- Процессор сделан, так значит надо его использовать. По-хозяйски
отнестись к делу. Оставить небольшую группу для сопровождения и
баги отлавливать. Копирование/производство относительно дёшего,
когда уже есть готовый образец и даже серия рабочая. - Costic(19.06.2023 15:46)
- Как и всякий VLIW, Эльбрус является тупиком. Это не страшно само по
себе, если вовремя осознать и принять меры. Но вместо этого МЦСТ
накрылся одеялом и пилит миллиарды на этом тупике. - Evgeny_CD(19.06.2023 11:12)