Здравствуйте, 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-м, когда Хуавей предлагал свои мощности под Эльбрус.
Боюсь, это не последнее неверное решение на этом пути.