Здравствуйте, 4058, Вы писали:
V>>На самом деле верно, средняя производительность на ядро при той же частоте как раз выросла примерно на 60%, при этом часть добавочной производительности вовсе не заслуга ядра, а обновлённого IO, в т.ч. общения с RAM. 4>Если так рассматривать, то по сути до сих пор ничего не изменилось с момента появления Sandy Bridge.
Та да, тогда добавили кеш инструкций 0-го уровня.
С тех пор в поколениях изменения навроде таких:
Improvements
— Larger L2 caches (1.25 MB per core from 512 KB per core)
— Larger L3 caches (3 MB per core from 2 MB per core)
— A new AVX-512 instruction: Vector Pair Intersection to a Pair of Mask Registers, VP2INTERSECT[5][6]
— Control Flow Enforcement Technology to prevent return-oriented programming and jump-oriented programming exploitation techniques[7]
— Full memory (RAM) encryption[8]
— Indirect branch tracking and shadow stack
— Intel Key Locker[9][10]
— AVX/AVX2 instructions support for Pentium Gold and Celeron processors has been unlocked[6]
Заметных именно архитектурных изменений с 2012-го не было, с тех пор мы наблюдаем смерть десктопной x86/x64-архитектуры.
В последнем поколении они вообще оборзели — за новизну выдали сочетание жирных и тонких ядер на одном кристалле, нагло поменяв номер поколения, не изменив в другом вообще ничего.
Это уже всё, финита ля комедия.
V>>Предел развития суперскаляров был виден самой же Intel еще в конце 90-х, когда они разрабатывали 4-й пень, который работал на многих задачах хуже 3-го пня в пересчёте на частоту на ядро. Отсюда Itanium, который был похерен AMD через продление агонии x86-й архитектуры. )) 4>Убогоархитектурный P4 позволял по быстрому прощупать пределы тактовых частот, которые потом долгое время придётся использовать.
Мда... ))
P4 — это гипертрединг, это было серьезное отличие от предыдущих поколений.
Ничего убогого в этом нет, это был способ повысить эффективность использования ресурсов и это работает.
Правда, два потока на ядро ни о чём, некоторые процы-современники тогда показывали 4-8 потоков на ядро, ну да ладно...
В общем, последующие пни — по-сути эволюционное развитие именно того самого первого варианта 4-го пня (не берём линейку Atom).
Параллельно вернулись к ядрам от 3-го пня и сделали на их основе линейку Core, вернулись к гипертредингу позже.
4>IA-64 уступал по производительности AMD64, поэтому смысла в его существовании дальше не было.
Дудки, на момент выхода не уступал, а на многих задачах (на мультимедии, ИИ, шифровании и т.д.) — заметно превосходил.
Уступать стал позже, когда на него забили, по причине примерно нулевых продаж.
V>>Потому что x86 и ARM-ы могут в любой момент быть закрыты западными санкциями и мы можем остаться без процов. 4>Ничего особо не мешает штамповать клоны x86 и ARM по устаревшим ТП на маленьких заводиках в Китае
Устаревшие не нужны.
У нас MIPS и SPARC на уровне, они кратно лучше устаревших тех.
4>да и наличие т.н. "параллельного импорта" исключает возможность совсем остаться без процов, поставки только сократятся, и ценник будет выше, но всё-равно это дешевле, чем делать свою архитектуру и так-же её производить на маленьких заводиках в Китае.
На маленьких заводиках, говоришь? ))
V>>Поэтому и продолжают у нас развивать MIPS, SPARC и Эльбрус. V>>Первый для контроллеров, второй для чего-то некритичного к вычислениям, последний — серьёзная числомолотилка.
4>
4>... первоначально инженеры из IBM пытались при создании SPE следовать канонам VLIW, однако столкнулись с серьезными проблемами и вернулись к уже хорошо обкатанной архитектуре SIMD-сопроцессора Altivec/VMX.
Да всем похрен, что конкретно IBM ниасилили.
IBM никогда не отличалась в эффективных вычислениях, всю свою историю она клепала машинки "для бизнеса".
С бюджетом в десятки раз меньшем когда-то Cray их нагнул как маленьких детей в нише числодробилок.
Мне было бы стыдно...
4>Так вот, почти весь жизненный цикл этих консолей (7 лет) разработчики под PS3 пытались раскрыть тот самый потенциал SPE, но удавалось это только в единичных случаях (и при активном участии со стороны Sony/IBM), а основной ширпотреб (кроссплатформа) была в пользу XBox 360, в основном за счёт сложностей связанных с использованием SPE.
Потому что гибридный код для двух архитектур одновременно — это хуже гири на ногах.
Представь, у тебя на обычном С++ только main, а потом на покалеченном языке, навроде самых первых версий языков для шейдеров, ты пишешь остальную программу?
Причём, со всеми прелестями шейдеров, когда у тебя нет доступа к объектам/данным из обычной памяти.
Ты должен сначала эти данные куда-то загнать (размер буфера всего 256 КБ), дождаться готовности данных, выполнить вычисления шейдерным ядром, в конце выгрузить результаты.
Это даже не гиря на ногах, это кандалы. ))
Здравствуйте, vdimas, Вы писали: V>Улыбнуло. V>Ликбез: V>Джобс объяснял Обаме примерно 4 часа, почему невозможно перенести производство Айфона из Китая в США.
ликбез1: не пытайтесь аргументировать информацией с потолка, чаще всего не прокатывает
ликбез2: раз уж вы не можете в метафоры, попробую объяснить на пальцах:
— Китай зависит от Apple
— Китай не зависит от РФ
так доступнее?
V>Ликбез: V>Китай класть хотел на США.
ликбез: не пытаейтесь в телепатию, особенно в международной политике, чаще всего не прокатывает V>Т.е. оружием особо не бряцает, но и на угрозы в свой адрес демонстративно кладёт.
ликбез: не пытайтесь примитивизировать то в чем ничего не понимаете, особенно в международной политике, чаще всего не прокатывает V>Ты этого не понимаешь от слова совсем. (С)
я так понимаю, что вы зачем-то уперлись в противостояние Китая и США, которое пытатаетесь продать как полезное для РФ
простая мысль, что Китай может послать всю российскую возню с Эльбрусом по собственным соображениям вас почему-то не посетила
притом что уже был послан совместный проект среднемагистрального самолета, автомобили, at cetera
не надо так зацикливаться на США, в мире иногда что-то происходит вполне себе независимо от них
V>Ты можешь рассказать только свои эротические фантазии.
вас волнуют мои эротические фантазии? точно туда пишете? V>А вот как обстоят дела в реальности:
придется вам таки рассказать, раз сами не умеете: Huawei по многим позициям выкинули с западных рынков
V>Насчёт санкций по 5G — были введены антисанкции, теперь там не будет американского 5G. V>США потеряли намного больше, бо рынки США и Китая несравнимы, бгг...
уже 6G пошло потихоньку, не переживайте за них так
V>Теперь на самом большом рынке планеты изгоем выступают США.
ох уж эти влажные мечты неофитов
V>Возбуждение разве что смехом над убогими, анонирующими на прошлое величие англосаксов.
как я и предполагал, вы не поняли контекста, видимо он оказался недоступным дял вашего IQ
не могу сказать чтобы меня это сильно расстроило
отечественные патриоты в принципе тупы, других телевизор просто не делает
V>У меня другая версия — такие как ты могут только ползать и лизать.
когда отечественные дрочеры светлого будущего начинают про "ползать и лизать" — воистину смешно
ползать по устаревшим западным технологиям и облизывать теперь уже контрафактное западное оборудование
вера — она такая, когда в n-й раз очередные деньги на Эльбрус разворуют, это никак не посмешает вам его надрачивать дальше и рассказывать как это все когда-нибудь будет круто
Здравствуйте, mDmitriy, Вы писали:
D>ликбез2: раз уж вы не можете в метафоры, попробую объяснить на пальцах:
Я могу в цифры.
Товарооборот Китая с США порядка $750 млрд в год.
Товарооборот Китая с РФ в этом году ожидается порядка $200 млрд в год.
Куда интересней динамика — последняя цифра растёт примерно на 30% в год.
D>- Китай зависит от Apple
Это пока Apple жив.
Сдохнет — и освободит свои доли рынка тоже в основном китайским смартфонам, т.е. для Китая эта игра выигрышная в любом случае.
А вот американскую Apple китайцы натурально держат за орешки.
Попались! ))
D>- Китай не зависит от РФ D>так доступнее?
Эротические фантазии мне доступны, ес-но.
Продолжай.
V>>Китай класть хотел на США. D>ликбез: не пытаейтесь в телепатию, особенно в международной политике, чаще всего не прокатывает
Бесполезно общаться со мной общими словами.
Ты уже пытался и уже облажался.
США, 18 июля
США совместно с десятками союзников "взыщут" с Китая "высокую цену", если официальный Пекин начнет поставлять России оружие или будет помогать обходить санкции. С соответствующим заявлением выступил пресс-секретарь Госдепартамента Нед Прайс.
ПЕКИН, 19 июля.
Китайские власти считают неприемлемыми угрозы Соединенных Штатов по поводу возможного обхода КНР антироссийских санкций Запада. Об этом заявил во вторник официальный представитель МИД Китая Чжао Лицзянь.
Обтекайте.
D>я так понимаю, что вы зачем-то уперлись в противостояние Китая и США, которое пытатаетесь продать как полезное для РФ
Разумеется.
Обратное (тут еще 2 обратных варианта) тоже верно.
D>простая мысль, что Китай может послать всю российскую возню с Эльбрусом по собственным соображениям вас почему-то не посетила
Ну вот как будут такие соображения, так и обсудим.
А пока что ты продолжаешь прилюдно насасывать из пальца фантазии, цепляясь за комфортные тебе мироощущения.
По-сути, ты совершил тут каминаут, поздравляю, чо! ))
D>притом что уже был послан совместный проект среднемагистрального самолета
Послан в эротическом направлении, надо понимать?
Видишь, опять эротика и опять фантазии, да что ж такое! ))
Кто не в курсе — РФ поставила китайской стороне ультиматум насчёт западных комплектующих.
Если бы не договорились — проект был бы послан нами, а не китайцами.
Ультиматум сработал:
Sina.com Китай
29 июня 2022
Китай подтвердил поставку авиадеталей в Россию
Чжугэ Сяочэ (诸葛小彻)
США и Европа очень удивились, когда Россия объявила, что собирается переоборудовать большой пассажирский самолет CR929 совместного производства с Китаем, не используя при этом в новой конструкции какие-либо западные детали. Москва даже заявила, что она не будет нуждаться ни в каких западных комплектующих. Китай также подтвердил намерение поставлять России новые запчасти. Очевидно, что сотрудничество между КНР и РФ в области высокоточных технологий достигло нового уровня.
...
западные страны во главе с Великобританией и США будут готовы поставлять различные детали и комплектующие для пассажирского самолета CR929 только тогда, когда это не будет противоречить их собственным интересам. Если Китай и Россия станут эксклюзивно разрабатывать этот самолет, то он получит преимущество в конкурентной борьбе с Boeing 787 или Airbus A330. Западные страны не смогут угрожать Москве и Пекину дальнейшими санкциями и прекращением поставок основных деталей и комплектующих для CR929, а значит, Запад не сможет повлиять на его производство и продажу.
D>не надо так зацикливаться на США, в мире иногда что-то происходит вполне себе независимо от них
Верно, я ж даже согласен, когда ты не фантазируешь.
Сейчас просто идёт расширение области независимости, бгг.
D>придется вам таки рассказать, раз сами не умеете: Huawei по многим позициям выкинули с западных рынков
Ткну тебя носом в твоё же — нарвавшись на встречные ограничения.
Хуавею подложили свинью в гугловском андроидном магазине? — OK.
В итоге у Хуавея появился свой магазин приложений, где, допустим, россиянину можно найти что угодно:
На сегодняшний день AppGallery входит в тройку самых распространённых глобальных магазинов приложений с охватом более 170 стран
У многих моих знакомых Хуавей/Хонор, проблем не испытывают.
Сравнимые с топовыми Самсунгами аппараты заметно дешевле.
Т.е., для клиента это противостояние даже в профит.
V>>Насчёт санкций по 5G — были введены антисанкции, теперь там не будет американского 5G. V>>США потеряли намного больше, бо рынки США и Китая несравнимы, бгг... D>уже 6G пошло потихоньку, не переживайте за них так
Да пофик.
Интернет-инфраструктура в США уступает даже украинской.
Вся эта мышиная возня — обычная паника лузеров.
Могли бы Штаты выиграть эту конкуренцию честно — не было бы мышиной возни.
Они ведь любят выигрывать конкуренцию честно и гордиться этим, хосподя.
Просто не всегда могут.
V>>Возбуждение разве что смехом над убогими, анонирующими на прошлое величие англосаксов. D>как я и предполагал, вы не поняли контекста, видимо он оказался недоступным дял вашего IQ
Как много общих слов...
Но ты в этой дисциплине даже не младенец, а зародыш, с непонятными шансами на рождение.
Тягаться в этом деле с тобой мне будет неспортивно, сорри.
Тут часто пробегают натуральные монстры этого же, с ними в такие игры потягаться всяко интересней. ))
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали: V>>Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области. V>>Забудь само слово "автовекторизация" когда речь про VLIW. S>С чего бы вдруг?
Потому что, в отличие от инструкций SIMD, работающих над упакованными данными, у VLIW развязаны руки.
Допустим, у тебя не 4*4 упакованных числа, а 6*6.
В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
Основная операция в БПФ, корреляции, фильтрации, ИИ — это одинаковые вычисления вида x=a0*b0+a1*b1+...+aN*bN.
Для современной радиолокации на фазированных решетках выполняются эти же операции.
Для любых алгоритмов автоподстройки чего-то там, слежения за текущим курсом и его коррекции ракет космических или крылатых (эти алгоритмы на основе корреляции/фильтрации) — аналогично.
Собсно, поэтому я уверен, что Эльбрус никуда не денется.
Он нам нужен хотя бы для военки и космоса.
Даже если взять облака и HPC (высокопроизводительные вычисления) — именно на этих вычислениях операции Эльбрус рвёт любые x64 как тузик грелку.
Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
Да, но задача эта отродясь была противоречивой.
Традиционные DSP-процы имели простую архитектуру: два индексных регистра, умножитель и сумматор.
За один такт выполнялось:
— умножение двух чисел по индексным регистрам
— прибавление результата умножения к сумматору
— приращение индексных регистров.
(см формулу выше)
Ну и плюс команды ветвления по флагам (обычно по флагу скипается следующая команда, которая безусловный jump).
Развитие DSP шло по пути VLIW — наборов умножитель+сумматор могло быть более одного, в одной команде параллельно можно было производить более одной такой ветки вычислений.
Одно было плохо — "бизнес логика" на таких процах выполнялась паршиво.
Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д.
Дальнейшие поколения Cray и Эльбрусов развивали этот подход.
Еще пример.
В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
Здесь уже SIMD сливает.
Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Как обычно, наиболее общее решение плохо работает для конкретного случая.
Эта тема более общая — отечественные камни как таковые.
Ввиду наличия некоторого инсайда и регулярно удовлетворяемого любопытства, я просто делюсь инфой.
V>>Это как вызов подпрограммы над определёнными структурами данных. S>Ну, так-то и CMPXCHG — это вызов подпрограммы над определёнными структурами данных.
Аргументом этой команды является указатель на число в памяти и два аргумента в регистрах.
Я бы не назвал простой указатель на число указателем на "определённую структуру данных".
Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
S>Вся "высокоуровневость" SIMD по сравнению со скаляром — это трёхаргументные команды вроде той, что я привёл.
Дело не в трёхаргументности.
Дело в требованиях к лейауту данных в памяти.
Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Часто это влечёт за собой лишние телодвижения.
Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием. С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
В нынешнем 16с содержится 16 таких монструозных ядер, в разрабатываемом 32с — 32.
S>Но опять-таки: вот ровно эта тема весьма слабо разработана в академической тусовке, по причине отсутствия поля применения. То есть в тех местах, где классический компилятор детектирует совершенно конкретные паттерны для автовекторизации, а если не смог — то развёртывает цикл и полагается на CPU, эльбрусовский должен не просто развернуть цикл, но и суметь раскидать результат развёртки по VLIW-инструкциям.
Всё так.
Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
Есть еще специфическая фишка Эльбрусов — это буфер подкачки данных.
В чём там суть?
На классических камнях есть кеши инструкций и данных, на Эльбрусе тоже есть.
Однако, мультимедиа-операции плохо ложатся на кеш данных, т.к. данные эти требуются лишь однократно.
На этих операция вычисление над большими массивами данных делает кеш инвалидным, вытесняя необходимые данные из некоей логики, к которым (данным) требуется периодическое повторное обращение.
Более того, этих данных заведомо в кеше не было, т.е. кеш не ускоряет доступ к таким данным.
Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно.
Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно предварительной подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Если говорить о случайной нагрузке небольшими блоками, то:
с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.
...
А вот в последовательной нагрузке большими блоками картина прямо противоположная:
оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.
V>>Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными. S>Не "можно", а "нужно". Это не так просто сделать, как трепаться на форуме.
"7.4.2. Умножение матриц"
Время выполнения программы умножения матриц
Интел | Эльбрус | Эльбрус + eml
------------------------------------
316.82 | 1206.92 | 14.69
Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
S>У компилятора всё ещё хуже: данных для предсказания ветвлений у него просто нет.
Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
V>>В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления. S>И перестали потому, что не смогли в компилятор, способный принимать решения лучше железки.
Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
EPIC не означает отмены OoO, спекулятивности и предсказания ветвлений.
Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
V>>И эта прболема никуда не делась — все последние поколения процов Интел — фейк. S>О, пошла знаменитая аналитика от Вдимас. Да, я помню, что Билл Гейтс — неудачник.
Наоборот, один из удачников.
Похоже, ты оперируешь сугубо эмоциональным восприятием материала. ))
Найди то обсуждение и пройдись внимательней, что было сказано.
V>>Тупик происходит уже 10-й год. S> Нам до того тупика — ещё сорок вёрст с поворотами.
Это смотря по какой причине тупик.
Если по причине объективного достижения некоей точки насыщения современных технологий — то отнюдь.
Например, 32с разводят под 6 нм техпроцесс.
Бо насыщение-с... большая разница на оси X (время) начинает слабо влиять на ось Y (результат).
В итоге через единицы лет это отставание станет непринципиальным.
И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
А пока что будущее ближайших единиц лет более чем прозрачно.
V>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
Это показывает, что Intel выполняет этот тест в ~4 раза быстрее Эльбрус, при этом уступает в 20-ть раз тесту с использованием eml.
Это такая-же нелепость как сравнивать перемножение матриц с использованием SIMD и без него.
В данном случае было бы интересно сравнить результаты с использованием упомянутого в статье MKL от Intel.
Здравствуйте, vdimas, Вы писали: V>Я могу в цифры. V>Товарооборот Китая с США порядка $750 млрд в год. V>Товарооборот Китая с РФ в этом году ожидается порядка $200 млрд в год.
в цифры вы тоже не умеете к сожалению и обращаетесь с ними у неуклюжестью начинающего пропагандона
США — 755
РФ — 149
это за 2021 год
что там у вас ожидается — те же новости будущего времени, вид сбоку
V>Куда интересней динамика — последняя цифра растёт примерно на 30% в год.
эта цифра вообще ниачом, не надо пытаться продать нужду за добродетель:
— у США тоже возрос объем торговли с Китаем примерно на столько же
— не надо считать с низкой ковидной базы
— сильно возросли расходы на логистику
V>Это пока Apple жив. V>Сдохнет — и освободит свои доли рынка тоже в основном китайским смартфонам, т.е. для Китая эта игра выигрышная в любом случае.
здесь и сейчас
V>А вот американскую Apple китайцы натурально держат за орешки. V>Попались! ))
убеждайте себя, убеждайте
без самовнушения оно как-то у вас не работает
V>Эротические фантазии мне доступны, ес-но.
не стесняйтесь тогда, тут все свои вы точно туда пишете?
D>>ликбез: не пытаейтесь в телепатию, особенно в международной политике, чаще всего не прокатывает V>Бесполезно общаться со мной общими словами.
хотите польстить себе тем что умеете в конкретику? ну, польстите V>Ты уже пытался и уже облажался.
мои педагогические способности очень ограничены, это правда
ваша вера не нуждается в фактах
V>Обтекайте.
Китай поставляет оружие и помогает РФ обходить санкции???
нет, так что обтекайте с размахом
вы как сорока, кидаетесь на блестючки, вместо того чтобы выяснить положение реальное дел
V>Разумеется. V>Обратное (тут еще 2 обратных варианта) тоже верно.
что говорит лишь об отсутствии у вас масштабного мышления, не более того
V>Ну вот как будут такие соображения, так и обсудим.
так изложил же ниже, флаг вам в руки V>А пока что ты продолжаешь прилюдно насасывать из пальца фантазии, цепляясь за комфортные тебе мироощущения. V>По-сути, ты совершил тут каминаут, поздравляю, чо! ))
по сути, у вас вполне себе альтернативная реальность между ушей, поздравьте себя еще раз
V>Послан в эротическом направлении, надо понимать? V>Видишь, опять эротика и опять фантазии, да что ж такое! ))
вот видите, вам в любой фразе мерещатся эротические подходы
доктор вам чего сказал, есть надежда?
V>Кто не в курсе — РФ поставила китайской стороне ультиматум насчёт западных комплектующих.
да вроде как никто не в курсе, кроме вас
V>США и Европа очень удивились,
вот после этой фразы можно дальше не читать
вам с легкостью гравируют на подкорку любую херню
V>Верно, я ж даже согласен, когда ты не фантазируешь. V>Сейчас просто идёт расширение области независимости, бгг.
у РФ? кто вам рассказал такую глупость?
РФ меняет былую взаимовыгодность на зависимость
V>Ткну тебя носом в твоё же — нарвавшись на встречные ограничения.
Моська ограничила слона? ню-ню V>Т.е., для клиента это противостояние даже в профит.
я рад за их клиентов
V>Да пофик. V>Интернет-инфраструктура в США уступает даже украинской.
кто вам рассказал такую глупость?
V>Вся эта мышиная возня — обычная паника лузеров.
ну да, убийцы айфонов — они такие
V>Как много общих слов... V>Но ты в этой дисциплине даже не младенец, а зародыш, с непонятными шансами на рождение. V>Тягаться в этом деле с тобой мне будет неспортивно, сорри. V>Тут часто пробегают натуральные монстры этого же, с ними в такие игры потягаться всяко интересней. ))
ну вот видите, как быстро с уровня местного продавана ничего вы скатились до уровня местного же коверного
не-е, продавать пустышки — это не ваше, а вот развлечь хоть как-то можете
тем, видимо, и ценны
Здравствуйте, 4058, Вы писали:
4>Это показывает, что Intel выполняет этот тест в ~4 раза быстрее Эльбрус
Этот тест показывает, что авторы статьи не потрудились поискать наилучшую стратегию обхода памяти.
Вот наивная реализация умножения матриц:
for(i = 0 i < n; i++ )
for(j = 0; j < n; j++ )
for(k = 0; k < n; k++ )
C[j * n + i] += A[j * n + k] * B[k * n + i];
Это схема ijk.
По классике наилучший результат из наивных даёт схема kji.
У авторов схема kij, которая, увы, является наихудшей.
Не наивной является схема прохода по транспонированной матрице.
Т.е одну из матриц сначала транспонируют, а потом в цикле нижнего уровня итерация проходит у всех трех матриц по 1-му элементу, а не прыгает как кенгуру по памяти.
Далее, операции j*n, i*n (для транспонированной) надо выносить наверх, и вот тут-то пресловутая автовекторизация SIMD и срабатывает, т.к. за один такт можно вычислить 4 ячейки, т.е. 4 оборота цикла.
Далее, обрати внимание на +=.
Надо заводить локальную переменную и накапливать результат в ней, а затем писать лишь однажды.
Ты дочитай до конца, автор там поиграл еще и получил на вручную написанной реализации результат примерно вдвое быстрее, чем с помощью EML, т.е. в 200 раз быстрее от исходного варианта.
А для Интел как ни крути — ничего уже особо не накрутишь.
4>при этом уступает в 20-ть раз тесту с использованием eml.
При этом eml ускорила наихудший вариант вычислений в 100 раз.
4>Это такая-же нелепость как сравнивать перемножение матриц с использованием SIMD и без него.
С чего ты решил, что SIMD не используется?
Компилятор компиллирует с SIMD инструкциями в любом случае.
Особенно хорошо для матриц.
Просто SIMD бывает очень разный.
Просто надо правильно обходить память и раскручивать циклы, чтобы какие надо SIMD инструкции подставлялись.
4>В данном случае было бы интересно сравнить результаты с использованием упомянутого в статье MKL от Intel.
MKL даёт прирост от наихудшей наивной реализации в ~10 раз.
Сравни с ускорением в 200 раз на Эльбрусе.
В общем, у этой архитектуры есть характеристика — флопсы на такт.
Необходимо в реализации софта поднимать эту характеристику на максимум (т.е. загружать максимальное кол-во исполнительных блоков в каждом такте), чтобы Эльбрус показывал себя во всей красе.
Капризная штука, да? ))
Компилятор надо развивать нон-стоп, ес-но, на него вся надежда.
Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо.
Здравствуйте, mDmitriy, Вы писали:
D>что там у вас ожидается — те же новости будущего времени, вид сбоку
Пошла болтология.
Сколько готов поставить?
Я так думаю, что нисколько, бо уже есть результаты за полугодие, там +30% от прошлого года.
V>>Куда интересней динамика — последняя цифра растёт примерно на 30% в год. D>эта цифра вообще ниачом, не надо пытаться продать нужду за добродетель: D>- у США тоже возрос объем торговли с Китаем примерно на столько же
Примерно на 12%, т.е. рост медленнее.
D>- не надо считать с низкой ковидной базы
Надо-надо.
Ковидные США стали больше закупать из Китая.
А РФ в чём-то большем импортном сугубо из-за ковида не нуждается.
V>>Это пока Apple жив. V>>Сдохнет — и освободит свои доли рынка тоже в основном китайским смартфонам, т.е. для Китая эта игра выигрышная в любом случае. D>здесь и сейчас
Ты не понял — китайцам глубоко похрен.
ВЕСЬ айфон делается в Китае.
Т.е. вообще весь.
Т.е. им насрать.
Уйдёт айфон — будут точно так же клепать свои марки на тех же мощностях.
Айфон популярен в Китае? — дык, это китайский телефон в Китае же и популярен.
А вы лузеры, бо у вас дефицит сальдо внешторга ~40%, т.е. вы только везете к себе, но нифига толком не вывозите от себя, потому что ничего толком не делаете.
Потому что не умеете.
Потому что только языком бла-бла-бла и щёки надувать, как ты сейчас пытаешься.
V>>А вот американскую Apple китайцы натурально держат за орешки. V>>Попались! )) D>убеждайте себя, убеждайте D>без самовнушения оно как-то у вас не работает
Да похрен.
Позволять себе оценочные суждения эмоционального плана стоит только если у тебя козыри в рукаве, т.е. владение инфой, т.е. если ты покажешь основания своему пустобрёхству.
А иначе ты просто Петрушка на базаре.
V>>Эротические фантазии мне доступны, ес-но. D>не стесняйтесь тогда, тут все свои
Не теряй контекст — доступны для понимания.
D>вы точно туда пишете?
Я пишу бесполезному балаболу, поэтому не парюсь.
Чувак на серьезных щах вышел на форум делиться эмоциями и мироощущением...
Чего бы не поизгаляться?
Если это был личный вопрос — конечно я могу продуцировать эротические фантазии.
Но в отличие от балаболов не делюсь ими на форумах.
Это же дело интимное, таки...
D>>>ликбез: не пытаейтесь в телепатию, особенно в международной политике, чаще всего не прокатывает V>>Бесполезно общаться со мной общими словами. D>хотите польстить себе тем что умеете в конкретику?
Пфф...
Хинт: когда изгаляются над оппонентом, то с вероятностью 99.999% указывают на существующие недостатки его навыков ведения спора.
Хотя бы потому, что если указывать несуществующие, то это нифига не обидно, а просто тупо.
Но если до оппонента не доходит, то что поделаешь?
Бывают такие люди, что их даже невозможно задеть — они просто не понимают, что их только что нехило припечатали.
Я ХЗ что подобные люди порой делают на сайтах, вроде этого, но бывает, бывает...
Неинтересны, чо...
Здравствуйте, vdimas, Вы писали: V>Пошла болтология.
вы только счас заметили? уж не один десяток каментов в нее накатали V>Сколько готов поставить?
тыщу баксов
а на что?
V>Я так думаю, что нисколько, бо уже есть результаты за полугодие, там +30% от прошлого года. V>Примерно на 12%, т.е. рост медленнее.
вероятно, вы хотели выразить этими цифрами какую-то гениальную мысль?
попробуйте ее сформулировать
сравнивать торговлю с Китаем РФ и США как-то вообще глупо — 1.5% мировой экономики никогда не сравняются с 20
другое интересно — российское положительное сальдо в долларах или таки в неконвертируемых юанях
V>А РФ в чём-то большем импортном сугубо из-за ковида не нуждается.
в чем нуждается РФ вряд ли кого-то интересует — покупает то что продадут или по-серому
V>Ты не понял — китайцам глубоко похрен. V>ВЕСЬ айфон делается в Китае. V>Т.е. вообще весь. V>Т.е. им насрать. V>Уйдёт айфон — будут точно так же клепать свои марки на тех же мощностях.
вы не поняли — Китаю похрен на ваши представления о нем и его будущем
и айфону тоже
но ненужные потери точно никому из них не нужны
V>Айфон популярен в Китае? — дык, это китайский телефон в Китае же и популярен.
похрен где он популярен, он прибыль приносит V>А вы лузеры, бо у вас дефицит сальдо внешторга ~40%, т.е. вы только везете к себе, но нифига толком не вывозите от себя, потому что ничего толком не делаете. V>Потому что не умеете. V>Потому что только языком бла-бла-бла и щёки надувать, как ты сейчас пытаешься.
это вы счас про кого?
как я понимаю, вы, поднатужившись, попытались обосрать внешнюю торговлю славного города Санкт-Петербурга, но традиционно обделались по-жидкому ма-асквич чтоле?
лошара, у нас порт забит по самые фаберже готовым к вывозу сырьем
V>Да похрен. V>Позволять себе оценочные суждения эмоционального плана стоит только если у тебя козыри в рукаве, т.е. владение инфой, т.е. если ты покажешь основания своему пустобрёхству.
вы тут брешете как-то не утруждаясь обоснованиями
видимо, ваш поток сознания этого не требует V>А иначе ты просто Петрушка на базаре.
это вы про себя как-то мягко
ну пусть будет Петрушка
V>Не теряй контекст — доступны для понимания.
странное место вы нашли для их понимания точно туда пишете?
V>Я пишу бесполезному балаболу, поэтому не парюсь. V>Чувак на серьезных щах вышел на форум делиться эмоциями и мироощущением... V>Чего бы не поизгаляться?
интересные у вас иллюзии
если бы вы писали лично мне, я бы давно послал вас нах и заблочил со спокойной совестью
ибо ничего из себя не представляете и толку от вас ноль
таких клоунов в интернете вагон и маленькая тележка
но вы работаете на публику, и подаете реплики, как и подобает исправно работающему коверному
грех лишать народ такого удовольствия
V>Если это был личный вопрос — конечно я могу продуцировать эротические фантазии. V>Но в отличие от балаболов не делюсь ими на форумах. V>Это же дело интимное, таки...
вы это "интимное" дело уже который комментарий размазываете
профессиональная деформация — она такая
V>Пфф... V>Хинт: когда изгаляются над оппонентом, то с вероятностью 99.999% указывают на существующие недостатки его навыков ведения спора. V>Хотя бы потому, что если указывать несуществующие, то это нифига не обидно, а просто тупо.
красиво вы себя убеждаете сам себя не убедишь — никто ведь не поверит
перед зеркалом не пробовали?
V>Но если до оппонента не доходит, то что поделаешь? V>Бывают такие люди, что их даже невозможно задеть — они просто не понимают, что их только что нехило припечатали.
бывают, конечно
вас повозили вашей мордой вашего лица по вами же наваленному дерьму — вам все божья роса
V>Я ХЗ что подобные люди порой делают на сайтах, вроде этого, но бывает, бывает... V>Неинтересны, чо...
до вас так и не дошло, что мне совершенно похрен ваши интересы
работайте дальше, продолжайте подавать реплики
в любом случае, коверные — это расходный материал
Здравствуйте, vdimas, Вы писали:
V>Этот тест показывает, что авторы статьи не потрудились поискать наилучшую стратегию обхода памяти.
Cкорее демонстрация, как можно изначально т.с. "неоптимальный" код с минимальными изменениями оптимизировать. То, что EML (в данном случае) с этим прекрасно справляется, сомнений не вызывает. Вещь безусловно полезная и интересная.
4>>Это такая-же нелепость как сравнивать перемножение матриц с использованием SIMD и без него.
V>С чего ты решил, что SIMD не используется?
В статье не приведены ключи GCC под Intel, упоминается только:
Самое простое перемножение без eml. Компилируем пример с оптимизацией -O3
-O3 включает автовекторизацию в GCC, но для дефолтового профиля x86-64 заиспользует что-то по мелочи из SSE2 (дальше надо ключи указывать), и для данного примера все-равно ничего путного само по себе не получится. Следовательно сравнивать eml_Algebra_GEMM_64F с этой мурой не стоит, тем более удивляться разнице в 20+ раз.
V>MKL даёт прирост от наихудшей наивной реализации в ~10 раз.
Это имеет смысл обсуждать при наличии соответствующего теста.
V>В общем, у этой архитектуры есть характеристика — флопсы на такт. V>Необходимо в реализации софта поднимать эту характеристику на максимум (т.е. загружать максимальное кол-во исполнительных блоков в каждом такте), чтобы Эльбрус показывал себя во всей красе.
V>Компилятор надо развивать нон-стоп, ес-но, на него вся надежда.
V>Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо.
Я не просто чуть ранее упомянул Cell, ибо там тоже делалась ставка на компилятор и SDK, которые постоянно будут улучшать, тем самым постепенно раскрывая потенциал SPE (все уши тогда этим прожужали), в результате следующее поколение консолей PS4/X1 тупо получили AMD64 (причем с в 2 раза меньшей тактовой частотой).
Здравствуйте, vdimas, Вы писали:
V>Этот тест показывает, что авторы статьи не потрудились поискать наилучшую стратегию обхода памяти.
Они показали, что наивная ручная оптимизация позволяет разогнать Эльбрус до примерно 2х от того, что даёт интел для неоптимизированного кода.
V>По классике наилучший результат из наивных даёт схема kji. V>У авторов схема kij, которая, увы, является наихудшей.
Что такое "kji"? Это вы перечисляете переменные итерирования изнутри наружу? Тогда в статье приведён код для kji.
V>Далее, обрати внимание на +=. V>Надо заводить локальную переменную и накапливать результат в ней, а затем писать лишь однажды.
Ровно это делается в статье.
V>Ты дочитай до конца, автор там поиграл еще и получил на вручную написанной реализации результат примерно вдвое быстрее, чем с помощью EML, т.е. в 200 раз быстрее от исходного варианта.
Не вижу, где там вдвое быстрее, чем на EML.
Вижу, что вначале он пишет, что "всё это уже применено в EML".
После второго этапа оптимизации он получил времена
real 167.63
user 167.52
sys 0.01
Это всё ещё примерно в 10 раз хуже, чем EML.
V>А для Интел как ни крути — ничего уже особо не накрутишь.
Ну зачем же так сразу. На интеле гонялся наивный код с оптимизацией компилятором. Немножко покрутив его, можно ускорить эту реализацию примерно в 60 раз.
4>>при этом уступает в 20-ть раз тесту с использованием eml. V>При этом eml ускорила наихудший вариант вычислений в 100 раз.
Ну, он при этом был всё ещё хуже интела.
V>С чего ты решил, что SIMD не используется? V>Компилятор компиллирует с SIMD инструкциями в любом случае.
У компилятора довольно вялые возможности по автовекторизации. И это видно что для случая x86, что для e8c. V>Особенно хорошо для матриц.
Особенно плохо компилятор справляется для матриц. Для векторов ещё куда ни шло — посмотрите на первую половину статьи. V>Просто SIMD бывает очень разный. V>Просто надо правильно обходить память и раскручивать циклы, чтобы какие надо SIMD инструкции подставлялись.
А то. Вы же не думаете, что в EML написана наивная реализация без оптимизации обхода и раскрутки циклов.
4>>В данном случае было бы интересно сравнить результаты с использованием упомянутого в статье MKL от Intel.
V>MKL даёт прирост от наихудшей наивной реализации в ~10 раз.
Думаю, должно быть не меньше, чем в хабрастатье.
V>Компилятор надо развивать нон-стоп, ес-но, на него вся надежда.
Надо. Но для этого надо расширять штат развиваторов. В микрософте ничего не шло вперёд, пока не отдали в опенсорс. V>Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо.
Это да, тут вопросов нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Допустим, у тебя не 4*4 упакованных числа, а 6*6. V>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
К примеру, AVX-512 может обработать 8 упакованных double за одну операцию. И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным.
Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.
V>Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
Это было бы интересно, если бы у нас был доступ для пощупать руками.
V>Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д. V>Дальнейшие поколения Cray и Эльбрусов развивали этот подход.
V>Еще пример. V>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа). V>Здесь уже SIMD сливает.
Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.
V>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.
V>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
V>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
В SIMD ветвления делаются не так V>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Надо щупать руками.
V>Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
Ну, пусть будет так.
V>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Это везде так. Чудес-то не бывает. V>Часто это влечёт за собой лишние телодвижения.
V>Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием.
Чего? V>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера. V>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.
V>Всё так. V>Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Воот. А всего один пост назад интринсики SIMD были позорищем V>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов.
Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.
V>Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно. V>Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно предварительной подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Где можно про этот буфер почитать? Каков его размер?
V>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим:
Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.
V>Неужели у тебя претензии лично ко мне? ))
Нет, отчего же. Вы же к МЦСТ отношения не имеете.
V>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?
V>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
Ну, если у них конвеер коротки — то почему нет. Но у меня не хватает квалификации для выполнения профилирования в уме, да ещё и под неизвестную архитектуру. Была бы железка — было бы о чём говорить.
V>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой.
Не было у итаниумов никакого решающего преимущества на практике.
V>Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
Это смелые утверждения
V>Наоборот, один из удачников. V>Похоже, ты оперируешь сугубо эмоциональным восприятием материала. )) V>Найди то обсуждение и пройдись внимательней, что было сказано.
Ну, наверное я вас неверно понял. Не могу найти тот топик, увы.
V>И это неотвратимо, если насыщение технологий объективно, а не исскуственно. V>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
У них основной козырь — это отлаженный конвеер разработки.
Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Эльбрус, достигни он своих целей, мог бы стать тем самым лесником из анекдота.
Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia. Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги. V>А пока что будущее ближайших единиц лет более чем прозрачно.
У вас в слове "призрачно" опечатка.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 4058, Вы писали:
4>-O3 включает автовекторизацию в GCC, но для дефолтового профиля x86-64 заиспользует что-то по мелочи из SSE2 (дальше надо ключи указывать)
Я тоже за ключи и автовекторизацию, бо если использовать некие расширения через интристики явно, то мы отрубаем возможность автовекторизации на будущих стандартах SIMD.
V>>MKL даёт прирост от наихудшей наивной реализации в ~10 раз. 4>Это имеет смысл обсуждать при наличии соответствующего теста.
Их есть в сети, разница примерно в 10 раз, как я и звучил.
V>>Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо. 4>Я не просто чуть ранее упомянул Cell, ибо там тоже делалась ставка на компилятор и SDK
Я на это уже отвечал — сама архитектура Cell не позволяет проектировать код в привычной манере.
А Эльбрус позволяет, поддерживаемый стандарт на сегодня C++14.
Причём, те же трюки, которые могут повысить производительность в amd_x64 (например, удачная стратегия прохода памяти, уменьшение кол-ва записей в нелокальные переменные и т.д.) точно так же даёт профит и для Эльбруса. В этом смысле можно позволять себе работать в привычной манере, вылизывая только по-настоящему горячие числодробительные циклы через профилировщик. Кстате, PGO на Эльбрусе даёт неплохой профит, по слухам. Увы, лично еще не играл.
4>которые постоянно будут улучшать, тем самым постепенно раскрывая потенциал SPE (все уши тогда этим прожужали), в результате следующее поколение консолей PS4/X1 тупо получили AMD64 (причем с в 2 раза меньшей тактовой частотой).
К следующему поколению консолей подоспели уже произвольные вычисления в графических ускорителях и весь тулчейн для этого, в отличие от ограниченного инструмента шейдеров в жестком данном сверху алгоритме рендеринга, как оно было ранее. Т.е. на новых поколениях графики задачи для Cell стало можно решать и без Cell.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали: V>>Допустим, у тебя не 4*4 упакованных числа, а 6*6. V>>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными. S>А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
Потому что нет смысла.
На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
S>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию.
Это и есть 4*4.
Т.е. ситуация такова — по мере расширения возможностей суперскаляра в деле распараллеливания вычислений и добавления вычислительных блоков, становится возможным утилизировать новые вычислительные мощности в том числе через явные SIMD команды большей размерности.
S>И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным. S>Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.
Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
V>>Еще пример. V>>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа). V>>Здесь уже SIMD сливает. S>Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.
Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме. Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
V>>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW. S>И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.
Нельзя одним тактом выполнить квадратичную интерполяцию.
V>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д. S>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
Минимум 6 за такт.
Но могу и ошибаться, тогда 18-24.
V>>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления? S>В SIMD ветвления делаются не так
В Эльбрусе ветвления бывают разные еще с той самой первой изначальной архитектуры на дискретных элементах.
Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:.
В современных GPU используется такой же подход.
V>>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть. S>Надо щупать руками.
Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел.
Разница во многие разы всегда.
V>>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом. S>Это везде так. Чудес-то не бывает.
Угу, бывает формулировка ТЗ и его исполнение инженерами в железе.
V>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера. V>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. )) S>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
S>Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.
Та не...
Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий.
Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений.
VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
V>>Но этому компилятору можно много чего подсказывать в прагмах и через интристики. S>Воот. А всего один пост назад интринсики SIMD были позорищем
Реализация через инстистики — зло, т.к. компилятор не заменит автоматом вручную указанные инструкции в следующих стандартах SIMD.
Речь шла о подсказках компилятору, которые работают даже для традиционных архитектур.
Подсказки навроде таких: https://docs.microsoft.com/en-us/cpp/preprocessor/loop?view=msvc-170
Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
V>>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML. S>Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Либы дают быстрый старт, разумеется.
Но не всегда библиотечное решение наилучшее для конкретного сценария, тут всё по классике.
S>Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов. S>Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.
В деле вычислений давно устоялся стандарт BLAS.
Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
S>Где можно про этот буфер почитать? Каков его размер?
V>>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим: S>Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.
Ну мы же не знаем, как драйвер диска и файловой подсистемы написан.
Вероятнее всего, активно использует технологию предварительной подкачки данных.
Потому что чудес же не бывает, а выглядит как чудо.
V>>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк... S>Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?
Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Библиотека EML дала прирост в 100 раз.
Обе цифры показывают как наличие фактора капризности, так и наличие путей решения этих капризов. ))
V>>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо. S>Ну, если у них конвеер коротки — то почему нет.
Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения.
Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO + предсказание ветвлений, просто заход к проблеме с другой стороны.
V>>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. )) S>Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
Что значит "только выкатила"?
Архитектуре ARM 30 лет уже.
Планшеты, ноуты и т.д. на ARM-е заполонили давно.
Даже MS выпустила свои Windows-планшеты на ARM-ах фиг его знает когда.
Т.е. экосистема там давно натоптана, тем более у Apple.
S>В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой. S>Не было у итаниумов никакого решающего преимущества на практике.
В первых версиях Итаниумы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках.
Но они были дороже топовых Зионов, в этом была ошибка.
Из-за большего спроса на AMD64-архитектуру Интел была вынуждена тратить ресурсы на эту линейку процов, что Итаниумы стали постепенно отставать.
На них тупо забили, так это выглядело.
Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
V>>И это неотвратимо, если насыщение технологий объективно, а не исскуственно. V>>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть. S>У них основной козырь — это отлаженный конвеер разработки.
Который буксует уже 10-й год?
Два супердорогих провальных проекта — P4 и Itanium.
Текущую ветку Core разработала израильская небольшая команда на основе ядра 3-го пня.
И вот вся большая Интел была вынуждена переключиться на небольшой проект израильской команды, которые разрабатывали энергически менее прожорливые процы на основе старого ядра...
И теперь это их мейнстримовая линейка.
Ребят, это приплызд, на самом-то деле.
S>Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Да тоже не ахти.
У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
Просто чуть позже, чем Интел.
S>Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia.
Там угрёбищная модель вычислений, много приседаний и отвлечения внимания не на то.
Нужна привычная модель вычислений, но чтобы результат при этом получался "сам по себе". ))
Но так-то да, GPU давно и уверенно шагают к тому моменту, когда перестанут нуждаться в центральном процессоре.
Выглядит так, что они с Эльбрусом забираются на вершину одной и той же горы, просто разными тропами.
Но на вершине встретятся обязательно.
S>Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
Нужно, просто страшно поддерживать.
Например мы не поддерживаем.
Ситуация простая — из-за попадания десктопной и серверной ниши в область насыщения, сегодняшнее железо живёт слишком долго.
Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
S>А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги.
Любые обращения к облакам всё более зашифрованы.
Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
V>>А пока что будущее ближайших единиц лет более чем прозрачно. S>У вас в слове "призрачно" опечатка.
Готов поставить?
Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже.
За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25.
Скучно... ))
Здравствуйте, Sinclair, Вы писали:
V>>По классике наилучший результат из наивных даёт схема kji. V>>У авторов схема kij, которая, увы, является наихудшей. S>Что такое "kji"?
Порядок вложения циклов обхода для приведённого мною алгоритма.
S>Это вы перечисляете переменные итерирования изнутри наружу? Тогда в статье приведён код для kji.
В статье другие идентификаторы, т.е. ijk не те, что я привёл.
Произведи подстановку имён переменных.
V>>А для Интел как ни крути — ничего уже особо не накрутишь. S>Ну зачем же так сразу. На интеле гонялся наивный код с оптимизацией компилятором. Немножко покрутив его, можно ускорить эту реализацию примерно в 60 раз.
Но почему-то интелловская либа ускоряет только в 10 раз.
Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке?
Ведь характер задачи заранее неизвестен.
Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше.
Как бы не хуже.
Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный.
4>>>при этом уступает в 20-ть раз тесту с использованием eml. V>>При этом eml ускорила наихудший вариант вычислений в 100 раз. S>Ну, он при этом был всё ещё хуже интела.
В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой.
V>>С чего ты решил, что SIMD не используется? V>>Компилятор компиллирует с SIMD инструкциями в любом случае. S>У компилятора довольно вялые возможности по автовекторизации.
Нормальные там возможности у обоих процов, если память правильно обходить.
Обрати внимание, что код под Эльбрус всё еще не использовал интистики и не использовал подкачку данных.
S>Особенно плохо компилятор справляется для матриц. Для векторов ещё куда ни шло — посмотрите на первую половину статьи.
Дык, вектора обходятся в памяти линейно, а при умножении матриц у одной из матриц нужно ходить поперёк памяти.
V>>Просто SIMD бывает очень разный. V>>Просто надо правильно обходить память и раскручивать циклы, чтобы какие надо SIMD инструкции подставлялись. S>А то. Вы же не думаете, что в EML написана наивная реализация без оптимизации обхода и раскрутки циклов.
Попахивает манипуляциями.
Ты привёл пример, где вовсю используются SIMD-интистики напрямую.
Т.е. чуть ли не на ассемблере код написан.
В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры.
Это не то же самое, что писать на асме.
V>>MKL даёт прирост от наихудшей наивной реализации в ~10 раз. S>Думаю, должно быть не меньше, чем в хабрастатье.
Подумай еще.
V>>Компилятор надо развивать нон-стоп, ес-но, на него вся надежда. S>Надо. Но для этого надо расширять штат развиваторов. В микрософте ничего не шло вперёд, пока не отдали в опенсорс.
Ты про дотнет?
С этим фруктом всё было понятно изначально.
И заметь — оно пошло вперёд, как только дотнет повернулся к нейтиву лицом, потому что заинтересовал более широкие слои населения.
Не те, коорые просто потребители технологий.
Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO.
И не отдадут в обозримом будущем.
Компилятор Эльбруса тоже показывает себя неплохо именно в деле LTO.
V>>Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо. S>Это да, тут вопросов нет.
Зато к коду по твоей ссылке эти вопросы есть.
И это то, чего хотелось бы избегать.
Здравствуйте, vdimas, Вы писали:
V>Порядок вложения циклов обхода для приведённого мною алгоритма. V>В статье другие идентификаторы, т.е. ijk не те, что я привёл.
В статье — ровно те же i, j, k. V>Произведи подстановку имён переменных.
Поясните. Лучше всего — приведите пример "наивного" кода, который является наиболее оптимальным.
V>Но почему-то интелловская либа ускоряет только в 10 раз.
У вас есть ссылка, подтверждающая эту оценку? V>Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке?
Конечно же доступны. V>Ведь характер задачи заранее неизвестен.
Известен: умножение матриц. V>Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше. V>Как бы не хуже.
Очень вряд ли там будет хуже. Дружелюбность к кэшу очень редко ухудшает работу в случае, когда выигрыша за счёт кэша нет. V>Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный.
Конкретно тот код зависит только от кратности размеров. Для того, чтобы он работал для произвольных матриц, там надо к каждому циклу прикрутить "голову" и "хвост" для выравнивания данных. Объём кода будет больше, но быстродействие будет сильно отличаться только для вырожденных случаев.
А эти случаи, в свою очередь, нетрудно отловить, и обработать более простым алгоритмом.
Впрочем, это всё несущественные подробности. Только что вы писали, что под интел как ни крути — а больше не накрутишь. Когда оказалось, что накрутишь — вы начинаете вилять.
V>В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой.
У есть ссылка, подтверждающая эту оценку? Я не нашёл ни одного теста, где бы совместно гонялись MKL и EML.
V>Нормальные там возможности у обоих процов, если память правильно обходить. V>Обрати внимание, что код под Эльбрус всё еще не использовал интистики и не использовал подкачку данных.
Это в примере из статьи, который всё ещё на порядок хуже EML.
V>Т.е. чуть ли не на ассемблере код написан.
И именно это и есть продуктивный способ писать эффективный код в 2022 году. V>В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры. V>Это не то же самое, что писать на асме.
Подсказки насчёт раскрутки циклов мало что дают. В статье про эльбрус автор не пользовался интринсиками, зато пользовался знанием таймингов команд. Это ещё хуже — то есть вместо того, чтобы напрямую написать компилятору, какой код ты от него хочешь, приходится шаманить при помощи подбора параметров. Цитирую уместный фрагмент:
При оптимизации гнезда циклов важно не упираться в ресурсы аппаратуры: количество вещественных операций, которое мы можем выполнять в одной ШК, количество доступных регистров. Поэтому для архитектуры e8c было бы правильным подобрать параметры следующим образом:
Подбор параметров unroll&fuse по i на 8 и по j на 6...
То есть при смене процессора придётся заново подбирать эти параметры.
V>Ты про дотнет?
Ага. V>С этим фруктом всё было понятно изначально.
Неа. V>И заметь — оно пошло вперёд, как только дотнет повернулся к нейтиву лицом, потому что заинтересовал более широкие слои населения.
Оно пошло вперёд, как только дотнет повернулся лицом к опенсорсу.
И только после этого он повернулся к нейтиву — ровно потому, что контрибуции перестали быть предметом заседаний комитета, и перешли в руки более широкой общественности.
V>Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO. V>И не отдадут в обозримом будущем.
То, что один из — это точно. Лучший — вряд ли. Gcc — тоже один из лучших в мире. При этом за gcc не стоит компания с капитализацией Microsoft.
V>Зато к коду по твоей ссылке эти вопросы есть. V>И это то, чего хотелось бы избегать. В теории — да. На практике — не выйдет без DSL. Для DSL нужны ресурсы, которых у МЦСТ нет и не было. Зато ресурсы есть у комьюнити, если его поддерживать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Потому что нет смысла. V>На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
Нагрузит, отчего нет*
S>>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию. V>Это и есть 4*4.
Я не понимаю вашу формулу. Что вы тут и на что умножаете?
Серверные процессоры интел — это два FMA модуля на ядро. Каждый из них умеет делать по 1 FMA операции за такт. То есть мы берём 8 даблов, умножаем их на другие 8 даблов, и прибавляем к ним третьи 8 даблов.
Итого, с учётом автораспараллеливания, потенциально мы имеем эквивалент 16ти FMA операций за такт.
У эльбруса по 6 скалярных арифметических модулей на ядро. В новой v6 архитектуре эти модули 128разрядные. То есть, при удачных погодных условиях, одно ядро эльбруса может выполнить 12 FMA-операций над 8байтными даблами за такт. То есть, проигрывает интелу примерно 25%. Добавляем разницу в тактовой частоте, и получаем отставание.
Если у вас есть какие-то другие цифры — велком, приводите.
V>Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
Я не склонен называть везением результат целенаправленных действий. Хотя да, явное склеивание команд, наверное, помогло бы. Но примерно для этого у нас есть scatter/gather в AVX, что позволяет добиваться впечатляющих результатов даже в областях, далёких от линейной алгебры и "упакованных данных". Например, разбор XML/json/UTF8/http headers.
V>Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме.
Например? V>Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
Нужны. И в чём затруднение?
V>Нельзя одним тактом выполнить квадратичную интерполяцию.
Ну так и во VLIW нельзя.
V>>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д. S>>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
V>Минимум 6 за такт. V>Но могу и ошибаться, тогда 18-24.
Брр. Вы сейчас про скалярный fmax/fmin? Непонятно. В интеле будет три инструкции, но каждая из них вычисляет 8 fmax/fmin за три такта. При независимости по данным — можно сделать 16 за три такта. Это если я сходу не затупил — тогда за 2 такта.
V>Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:. V>В современных GPU используется такой же подход.
Я так понял, что это примерно то же самое, что и в интеле — то есть просто обе ветки вычисляются, но результат одной из них отбрасывается.
V>Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел. V>Разница во многие разы всегда. Ну, там, где на Эльбрусе применяют вручную оптимизированную библиотеку, а на интеле — наивный студенческий код, там да.
V>>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера. V>>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. )) S>>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
V>Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
Это не отвечает на мой вопрос. Каким волшебным образом VLIW сможет обогнать SIMD на невыровненных данных вроде разбора сетевых пакетов. Там же недостаточно просто зачитать кусочек данных в регистры — надо найти, скажем, длину заголовка, и прибавить её к текущему смещению. Пока это не сделано, мы не можем загружать следующий блок данных. А когда сделано — SIMD точно так же прекрасно прочтёт этот блок в регистр.
V>Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий. V>Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений. V>VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
Это всё понятно. Непонятно, за счёт чего VLIW объедет SIMD. Примеры статей про использование SIMD для невыровненных данных я приводил.
V>Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
Построение компилятора, который способен построить близкий к идеальному код, опираясь только на такие невнятные намёки, представляет собой плохо изученную и очень сложную область.
Её невозможно вскопать в узком кругу высококлассных единомышленников.
V>В деле вычислений давно устоялся стандарт BLAS. V>Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями. V>Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
Это для линейки. Её одной — недостаточно. Возвращаемся к вопросу коммерческой применимости — сколько (в % рынка) у нас занимают вычисления линейной алгебры?
А для простого бизнеса нужно быстрое исполнение java, js, C#. Нужны библиотеки/фреймворки с быстрым разбором и генерацией XML/json/HTML. Нужны всякие преобразования над картинками, в основном png и jpeg.
Нужна видеокомпрессия/декомпрессия.
V>Размер в процессоре Эльбрус 4с был 4 КБ на ядро, сейчас не в курсе.
Маловато по сравнению с интеловским L1.
V>Технология эта не является уникальной для Эльбруса, гуглить по "асинхронная подкачка данных". V>Например: V>https://vk.com/@kawaiipc-ustroistvo-obrascheniya-k-massivam
Ну, это интересно. Хотя по большому счёту, это всего лишь этакий кэш со специальной политикой вытеснения, оптимизированной для линейного сканирования; рукопашное асинхронное управление кэшем на интеле тоже есть в виде инструкции PREFETCH.
V>Ну мы же не знаем, как драйвер диска и файловой подсистемы написан. V>Вероятнее всего, активно использует технологию предварительной подкачки данных. V>Потому что чудес же не бывает, а выглядит как чудо.
То-то и странно. SSD всё ещё медленнее, чем даже обычная память.
V>Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
Хотелось бы каких-то подтверждений. V>У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Вы так и не указали, откуда 200 раз. Я увидел 1/10 от быстродействия EKL.
Можете процитировать фрагмент статьи с цифрами, на которые вы опираетесь?
V>Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения. V>Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO + предсказание ветвлений, просто заход к проблеме с другой стороны.
Вот это место не очень понятно. Вы хотите сказать, что у эльбруса есть какой-то большой запас вычислительных блоков, которые позволяют одновременно исполнять несколько веток спекулятивно, а потом отбрасывать результат всех, кроме истинной? Это было бы крайне удивительно.
V>В первых версиях Итаниумы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках. V>Но они были дороже топовых Зионов, в этом была ошибка.
Удивительно, что интел не исправил эту ошибку за долгие годы истории итаниума. V>Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
Ну, давайте применим этот аргумент к Эльбрусам. Пока что выглядит так, что МЦСТ тщательно копирует ошибки Интел, не копируя их удачные шаги.
V>Который буксует уже 10-й год? V>Два супердорогих провальных проекта — P4 и Itanium.
Итаниуму — 20 лет. Из которых примерно 15 понятно, что он мёртв. V>Ребят, это приплызд, на самом-то деле.
V>У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
Ну какое же там насыщение. V>Просто чуть позже, чем Интел.
Ни один из производителей не может расслабиться, иначе потеряет долю рынка.
V>Там угрёбищная модель вычислений, много приседаний и отвлечения внимания не на то.
Это всё обходится созданием удачной абстрактной прослойки.
V>Но на вершине встретятся обязательно.
Вопрос только — кто там с кем встретится. Эльбрус может и не успеть
V>Нужно, просто страшно поддерживать. V>Например мы не поддерживаем.
А чего не поддерживаете-то? Правильно: на ваших задачах AVX512 не даст ощутимого выигрыша.
Иначе — поддерживали бы. Риска ведь никакого нет — ваш код не станет хуже работать на avx2 после включения поддержки avx512.
V>Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
И что?
V>Любые обращения к облакам всё более зашифрованы. V>Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
Есть подозрение, что за оптимизацию шифрования нашими ГОСТами на интеле никто ещё толком и не брался.
V>Готов поставить? V>Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
Тут скорее есть бочка дёгтя в ложке мёда Эльбруса. Горстка хороших инженеров не вытащит команду некомпетентных управленцев, увы.
V>Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже. V>За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25. V>Скучно... ))
А также будут допиливаться всякие нишевые ништяки — дополнительные AVX команды для специальных случаев типа криптографии и видеокодирования.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Порядок вложения циклов обхода для приведённого мною алгоритма. V>>В статье другие идентификаторы, т.е. ijk не те, что я привёл. S>В статье — ровно те же i, j, k.
Есть матрица с горизонтальным обходом (пусть переменная цикла будет i), вертикальным обходом (j) и результирующая, где накапливаются суммы умножений (k).
Соответственно, есть 6 вариантов вложений циклов друг в друга.
S>Поясните. Лучше всего — приведите пример "наивного" кода, который является наиболее оптимальным.
Я уже озвучил:
По классике наилучший результат из наивных даёт схема kji.
Т.е. на внешнем цикле запись, на втором — пробегание по памяти "скачками", и на внутреннем цикле пробегание по памяти упорядоченно.
Немного забавно, что цепляемся за подобные "задачи", которые дают студентам-первокурсникам в кач-ве лабораторок (бенчмарки различных вариантов реализации умножения матриц).
ИМХО, в подобных вещах опытным спецам остаточно обратить внимание коллег на некую подробность и вопрос должен считаться исчерпанным.
V>>Но почему-то интелловская либа ускоряет только в 10 раз. S>У вас есть ссылка, подтверждающая эту оценку?
В гугле есть сразу несколько ссылок.
V>>Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке? S>Конечно же доступны.
Реализация по твоей ссылке диктует некий минимальный размер, плюс плохая оценка производительности снизу из-за избыточных операций для матриц не самого большого размера.
Но мне нравится твоя ссылка, бо она хорошо показывает, что библиотеки — не панацея.
V>>Ведь характер задачи заранее неизвестен. S>Известен: умножение матриц.
Матрицы матрицам рознь.
V>>Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше. V>>Как бы не хуже. S>Очень вряд ли там будет хуже. Дружелюбность к кэшу очень редко ухудшает работу в случае, когда выигрыша за счёт кэша нет.
Там для небольших матриц избыточность телодвижений.
Ну и плюс тот код банально не работает на матрицах размерности ниже ширины ручной раскрутки циклов.
V>>Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный. S>Конкретно тот код зависит только от кратности размеров. Для того, чтобы он работал для произвольных матриц, там надо к каждому циклу прикрутить "голову" и "хвост" для выравнивания данных.
В либах так и происходит — обязательно есть ветвления (чаще по switch).
Как в самом начале — по размерностям матриц, так и при обслуживании "хвостов" некратных размеров.
Для заведомо известных размеров кучу телодвижений можно нивелировать, ес-но.
S>А эти случаи, в свою очередь, нетрудно отловить, и обработать более простым алгоритмом.
Да всё можно сделать.
Мы тут переливаем из пустого в порожнее вокруг первого же моего утверждения:
— готовые библиотеки дают хороший старт;
— при надобности конкретные места можно уже вылизывать врукопашную.
Мне хотелось обратить внимание, что для Эльбруса как либы, так и рукопашное вылизывание дают, не побоюсь пафоса, чудовищный профит.
S>Впрочем, это всё несущественные подробности. Только что вы писали, что под интел как ни крути — а больше не накрутишь. Когда оказалось, что накрутишь — вы начинаете вилять.
Да без проблем — допили тот код до работы с произвольными размерами матриц и замерь.
Дай бог получить результаты как у интеловской либы, а замеров по ней в сети хватает.
V>>В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой. S>У есть ссылка, подтверждающая эту оценку? Я не нашёл ни одного теста, где бы совместно гонялись MKL и EML.
А как они могут гоняться совместно? ))
V>>В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры. V>>Это не то же самое, что писать на асме. S>Подсказки насчёт раскрутки циклов мало что дают.
В статье про Эльбрус они дали всё.
S>В статье про эльбрус автор не пользовался интринсиками, зато пользовался знанием таймингов команд.
Не таймингов, а архитектуры ядер.
Различные Эльбрусы различаются кол-вом и быстродействием ядер при устаканенной архитектуре.
S>Это ещё хуже — то есть вместо того, чтобы напрямую написать компилятору, какой код ты от него хочешь, приходится шаманить при помощи подбора параметров. Цитирую уместный фрагмент: S>
S>При оптимизации гнезда циклов важно не упираться в ресурсы аппаратуры: количество вещественных операций, которое мы можем выполнять в одной ШК, количество доступных регистров. Поэтому для архитектуры e8c было бы правильным подобрать параметры следующим образом:
S>Подбор параметров unroll&fuse по i на 8 и по j на 6...
Это верно и для регистров SSE.
Т.е. конкретные твои интриситки либо расчитаны на SSE1-SSE4 (8 регистров XMMx), либо на AVX+ (16 регистров YMMx)
Я лишь указал, что вместо того, чтобы руками писать на ассемблере-интистиках (как по твоей ссылке), для Эльбруса (по моей ссылке) был использован вариант, где код генерится компилятором, которому лишь подсказывают степень раскрутки цикла.
S>То есть при смене процессора придётся заново подбирать эти параметры.
При смене версии SSE/AVX в твоём случае придётся переписывать код. ))
V>>С этим фруктом всё было понятно изначально. S>Неа.
Это тебе нет, хотя конкретно тебе говорили, как оно будет, и оно так и было.
Зато ты фантазировал безудержно, помнится.
(не только ты, но ты громче всех)
V>>И заметь — оно пошло вперёд, как только дотнет повернулся к нейтиву лицом, потому что заинтересовал более широкие слои населения. S>Оно пошло вперёд, как только дотнет повернулся лицом к опенсорсу.
Этого недостаточно.
Джава давно повернулась лицом к опенсорсу, но огромного кол-ва ревьюверов джава-машинки я не наблюдаю.
Потому что простого поворачивания к опенсорсу мало, надо повернуться лицом к тем, для кого память и тики проца всё еще ресурс.
Если джава не повторит за дотнетом поворачивание лицом к таким людям — постепенно уйдёт примерно туда же, куда ушел популярный когда-то Perl.
На последних дотнетах я снижаю нагрузку на GC более чем на порядок.
Джава в нынешнем виде просто обречена...
S>И только после этого он повернулся к нейтиву — ровно потому, что контрибуции перестали быть предметом заседаний комитета, и перешли в руки более широкой общественности.
Это ты запутался в истории происходящего. ))
Сначала стали контрибутить нейтивные фишки, и только затем подтянулась широкая общественность.
Т.е. между тем, как открыли в опенсорс и тем, как подтянулось приличное кол-во людей, прошло прилично времени.
Лично я тоже обратил внимание на .Net Core только когда пошли нейтивные вкусняшки.
До этого пару лет было даже не любопытно.
V>>Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO. V>>И не отдадут в обозримом будущем. S>То, что один из — это точно. Лучший — вряд ли.
Не вряд ли.
Где-то, сугубо местами его бьёт и GCC и IC, но вот разве что местами.
А по всему остальному фронту огребают. ))
S>Gcc — тоже один из лучших в мире. При этом за gcc не стоит компания с капитализацией Microsoft.
Я уже рассказывал, что не так с GCC и как он умудрился догнать MS VC.
В общем, история похожа на развитие стандартов интернета.
Когда-то MS хотела и могла развивать стандарты интернета, но W3C запорол это дело на корню по банальной причине — альтернативные браузеры были не готовы.
Т.е. под новые стандарты мог быть готов только IE.
В итоге, скорость развития стандартов интернета стала в точности равна скорости развития WebKit/Chromium и кода Мозиллы.
Аналогично вышло с С++ — этот язык так долго находился в застое из-за невозможности альтернативных реализаций удовлетворять стандарт.
Поэтому, GCC не догнал сам по себе MS VC — он гнался за стоячим.
Собсно, эта история и побудила MS забить как на свой браузер, так и на своё нейтивное направление когда-то.
Плюс проигрыш в суде насчёт Джавы — там тоже MS не разрешили развивать стандарты Джавы, хотя Ораклу, почему-то, потом разрешили.
В общем, этот мир полон клинических идиотов, практически весь из них состоит.
Так появился дотнет.
И, в отличие от Джавы, он не был доступен на платформе хейтеров-красноглазиков, из-за которых, собсно, MS несправедливо трижды так нагнули.
Именно из-за этого случился зайстой в IT-области как таковой в течении всех нулевых, примерно до 2012-го, когда этот застой стал уже слишком бросаться в глаза.
Такой был мощный подъем на отрезке 95-2000, и такой обломс в течении 10-ти лет затем.
Разумеется, конкретно ты был не при чём, просто ты был тогда удобным мальчиком для битья, полезным сам знаешь кем, который безо-всякого принуждения озвучивал точку зрения именно тех людей, из-за ущербности мыслительного аппарата которых IT так обделалось, что аж на десятилетие. Пинать тебя было банально удобно. Жаль, ты не понимал и половины того, что тебе говорили, бо обитаешь в своём параллельном мире, связь с реальностью минимальная. ))
Здравствуйте, vdimas, Вы писали: V>Я уже озвучил: V>
V>По классике наилучший результат из наивных даёт схема kji.
V>Т.е. на внешнем цикле запись, на втором — пробегание по памяти "скачками", и на внутреннем цикле пробегание по памяти упорядоченно.
Что сдерживает вас от написания трёх строчек кода? Зачем все вот эти литературные упражнения?
for(k = 0; k < n; k++ )
for(j = 0; j < n; j++ )
for(i = 0 i < n; i++ )
C[j * n + i] += A[j * n + k] * B[k * n + i];
Вы имеете в виду вот этот порядок? V>В гугле есть сразу несколько ссылок.
Я не нашёл ни одной. Нашел пару ссылок про то, как можно улучшить MKL. Сравнения MKL c наивным кодом не нашёл.
V>Но мне нравится твоя ссылка, бо она хорошо показывает, что библиотеки — не панацея.
Она хорошо показывает ложность утверждения "А для Интел как ни крути — ничего уже особо не накрутишь."
V>Матрицы матрицам рознь.
V>Там для небольших матриц избыточность телодвижений.
Ну, если мы говорим про матрицы 4*4 — да, избыточно. На всякий случай напомню, что статья про Эльбрус гоняет тесты для матриц размером 1000*1000.
Может, надо запустить код автора на небольшой матрице, и посмотреть, что там с гигафлопсами? V>В либах так и происходит — обязательно есть ветвления (чаще по switch). V>Как в самом начале — по размерностям матриц, так и при обслуживании "хвостов" некратных размеров.
Всё верно. Вопрос-то в чём? V>Для заведомо известных размеров кучу телодвижений можно нивелировать, ес-но.
Тем более.
V>Да всё можно сделать. V>Мы тут переливаем из пустого в порожнее вокруг первого же моего утверждения: V>- готовые библиотеки дают хороший старт; V>- при надобности конкретные места можно уже вылизывать врукопашную.
V>Мне хотелось обратить внимание, что для Эльбруса как либы, так и рукопашное вылизывание дают, не побоюсь пафоса, чудовищный профит.
Вы всё ещё не показали цитату, где рукопашное вылизывание на Эльбрусе объехало библиотеку.
V>Да без проблем — допили тот код до работы с произвольными размерами матриц и замерь. V>Дай бог получить результаты как у интеловской либы, а замеров по ней в сети хватает.
Интеловская либа, судя по найденным мной статьям — ещё не предел.
V>А как они могут гоняться совместно? ))
Ну, вас же не смутила ссылка, где совместно гоняется EML и наивный код на Интеле. Вот надо точно так же, только вместо for(i=0....) — MKL.
V>В статье про Эльбрус они дали всё.
Где именно?
V>Не таймингов, а архитектуры ядер.
И таймингов и архитектуры.
V>Это верно и для регистров SSE. V>Т.е. конкретные твои интриситки либо расчитаны на SSE1-SSE4 (8 регистров XMMx), либо на AVX+ (16 регистров YMMx)
Либо на 32 регистра ZMMx
При этом, когда я пишу интринсики, они компилируются ровно в нужные мне векторные команды. А не случайно параллелятся компилятором в зависимости от фазы луны.
V>Я лишь указал, что вместо того, чтобы руками писать на ассемблере-интистиках (как по твоей ссылке), для Эльбруса (по моей ссылке) был использован вариант, где код генерится компилятором, которому лишь подсказывают степень раскрутки цикла.
Осталось показать, как код с подсказками догоняет код с интринсиками.
V>При смене версии SSE/AVX в твоём случае придётся переписывать код. ))
Для AVX у нас хотя бы есть гарантия, что код на следующем процессоре будет исполняться не хуже.
Я не уверен в том же для Эльбруса.
V>Это тебе нет, хотя конкретно тебе говорили, как оно будет, и оно так и было. V>Зато ты фантазировал безудержно, помнится. V>(не только ты, но ты громче всех)
И в итоге оказалось, что всё произошло так, как я говорил, хоть и не сразу
V>Джава давно повернулась лицом к опенсорсу, но огромного кол-ва ревьюверов джава-машинки я не наблюдаю.
А я — наблюдаю. Просто вы не вращаетесь в тех кругах, где принято пилить JVM. V>Если джава не повторит за дотнетом поворачивание лицом к таким людям — постепенно уйдёт примерно туда же, куда ушел популярный когда-то Perl.
Увы, не уйдёт. Но это оффтоп к данной дискуссии.
V>Сначала стали контрибутить нейтивные фишки, и только затем подтянулась широкая общественность. V>Т.е. между тем, как открыли в опенсорс и тем, как подтянулось приличное кол-во людей, прошло прилично времени.
Хм. А кто контрибутил нейтивные фишки?
V>Разумеется, конкретно ты был не при чём, просто ты был тогда удобным мальчиком для битья, полезным сам знаешь кем, который безо-всякого принуждения озвучивал точку зрения именно тех людей, из-за ущербности мыслительного аппарата которых IT так обделалось, что аж на десятилетие. Пинать тебя было банально удобно. Жаль, ты не понимал и половины того, что тебе говорили, бо обитаешь в своём параллельном мире, связь с реальностью минимальная. ))
Меньше пафоса, больше дела.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Что сдерживает вас от написания трёх строчек кода?
Публикуемый своей рукой код желательно сначала проверить лично.
Чтобы не запутаться, где какая переменная итерируется, берём матрицы разных размерностей (L, M и N как в вики):
Пусть даны две прямоугольные матрицы A и B размерности l х m и m х n соответственно.
Тогда матрица C размерностью l x n, в которой:
называется их произведением.
В переменных i, j, k это будет:
unsafe {
const int L = 2, M = 3, N = 4;
var a = stackalloc float[L * M] {
1, 2, 3,
4, 5, 6
};
var b = stackalloc float[M * N] {
1, 2, 3, 4,
5, 6, 7, 8,
9, 10, 11, 12
};
var c = stackalloc float[L * N];
for(var k = 0; k < L; k++)
for(var j = 0; j < N; j++)
for (var i = 0; i < M; i++)
c[k * N + j] += a[k * M + i] * b[i * N + j];
for(var i = 0; i < L; i++) {
if(i != 0)
Console.WriteLine();
for(var j = 0; j < N; j++) {
if(j != 0)
Console.Write(", ");
Console.Write(c[i * N + j]);
}
}
Console.WriteLine();
}
V>>Да без проблем — допили тот код до работы с произвольными размерами матриц и замерь. V>>Дай бог получить результаты как у интеловской либы, а замеров по ней в сети хватает. S>Интеловская либа, судя по найденным мной статьям — ещё не предел.
Боюсь, для того самого общего случая, т.е. стандарта BLAS — предел.
V>>А как они могут гоняться совместно? )) S>Ну, вас же не смутила ссылка, где совместно гоняется EML и наивный код на Интеле.
Потому что хватает ссылок, где наивный код сравнивается с EML.
Я просмотрел пару таких ссылок, везде ускорение примерно в 10 раз (плюс-минус проценты), позволил себе сделать соотв. прикидки от обсуждаемых цифр.
S>При этом, когда я пишу интринсики, они компилируются ровно в нужные мне векторные команды. А не случайно параллелятся компилятором в зависимости от фазы луны.
Или в зависимости от опции компилятора для целевой архитетуры.
В общем, зря тут упираешься.
V>>Это тебе нет, хотя конкретно тебе говорили, как оно будет, и оно так и было. V>>Зато ты фантазировал безудержно, помнится. V>>(не только ты, но ты громче всех) S>И в итоге оказалось, что всё произошло так, как я говорил, хоть и не сразу
Пока что мало чего произошло, оно только-только начинает происходить (заметные подвижки начались с 5-го и 6-го дотнета ) и это очень надолго.
Тебе сразу говорилось, что до твоей пенсии ты своё светлое будущее не застанешь.
Я приводил в пример чистые ФП-языки, которые дают намного больше простора для бета-редукций, но за ~15 лет активных телодвижения результаты были слишком скромные на середину нулевых.
Уже более 30-ти лет примерно с теми же результатами.
А жить надо было как-то здесь и сейчас, и ближайшие лет 10 (твои прогнозы) каким-то образом тоже.
Вот почему я считал ошибкой ту стратегию, что MS примерно на 8-10 лет натурально забило на нейтив.
Помнишь проект Avalon и фантазии, что всё GUI в будущих Windows будет managed?
В итоге в 8-х виндах они докрутили С++ компилятор до возможности оперировать расширенной метаинформацией (банально атрибутами и некоторыми типами, которые компилятор "знает в лицо") — и ву а ля, менее чем за год разработали подсистему GUI UWP, которую Avalon с нужной эффективностью так и не породил за ~6 лет.
А которые C# UWP-приложения — там лишь тонкая обёртка над нейтивной подсистемой, и оно пашет в разы шустрее, чем WPF, да еще в памяти чуть ли не на порядок меньше мусора.
Боюсь, что по этому вопросу "наша" точка зрения победила даже не до твоей пенсии, а до конца твоей жизни.
И что меня раздражало в оппонентах (не только в тебе) — я подробно разбирал низкоуровневую механику WPF и объяснял почему так — загвоздка в вызове пайплайна подсистемы GUI, в необходимости осуществлять тысячи вызовов низлежащего рендерера (а для последних версий DirectX вызовов еще больше, хотя сами вызовы легковесней).
И в этом месте дотнет сильно проседает из-за дороговизны вызова нейтивных ф-ий.
Как они выкрутились в WPF — со стороны C# идёт сериализация команд в некий байт-буфер, отправка сериализованных команд в специальный поток, обслуживаемый нейтивной библиотекой.
В этом потоке нейтивный код десериализует команды, пакеты вида { код_операции, операнды... } и по таблице кодов команд вызывает соотв. методы-адаптеры, которые, в свою очередь, вызывают ф-ии низлежащего GUI с поданными в сообщении аргументами.
И так вышло, что обход графа со стороны C# с сериализацией, что динамический расчёт лейаута, что применение стилей — всё на стороне C# почему-то тормозит и жрёт ресурсы.
Плюс задержки с сериализацией и передачей сцены нейтивной либе.
Как эти ограничения переплюнуть точному GC — лично я ума не приложу.
Плюс соображения интероперабельности с другими языками/технологиями — они все умеют взаимодействовать с нейтивом тем или иным образом изкаробки, бо все поверх нейтива пашут.
Но как взаимодействовать с АПИ дотнета — вопрос вопросов.
Поэтому, совершенно согласен с тем, что на сторону C# надо отдавать только биндинги к св-вам и событиям GUI-компонент и не более того.
И точно так же для любых других "высокоуровневых" технологий.
Здесь подход мало чем отличается от биндинга Питоновских либ к нейтивным BLAS-либам.
Так вот, подводя жирную черту под всеми этими фапаниями на несостоявшийся Avalon когда-то:
— технологии навроде дотнета/джавы важны и нужны, хотя бы по той причине, что работают лучше скриптовых языков/сред в их нишах, являясь зачастую более удобными/легкими в разработке;
— но такие технологии не должны были претендовать на исключительное своё положение, тем более в первые же годы своей жизни;
— архитектура компонент и низлежащие принципы работы WPF заведомо антиинженерные, такие решения могли быть приняты только через ангажированность/болтологию/веру в близкое светлое мега-будущее.
Я много и глубого исследовал Рефлектором дотнет когда-то, сейчас регулярно пасусь на гитхабе проекта, да и вообще не представляю себе работу без решарпера, который сам подгружает дебаг-информацию и дизассемблирует сборки.
Почти всегда мне понятны мотивы принятых тех или иных решений (хотя местами улыбали явно индусские мотивы, но это обычно был не самый критичный код).
Однако, рассматривая внутренности WPF я только за голову хватался...
Собсно, будучи сам поначалу интузиастом дотнета в этом месте я сильно к дотнету охладел. ))
Ну и, люди, навроде тебя (Влад, AVK и прочие) своими речами наглядно мне продемонстрировали, как и почему подобные грубейшие архитектурные ошибки проползают в ведущие технологии. А технология WPF на момент разработки пророчилась в кач-ве ведущей для GUI.
Всё вместе это болото, токсичность, невозможность поступления свежего воздуха, как грится, невозможность даже просто предметно дискутировать.
Секта.
И вот так оно в кач-ве секты с 98-го (год начала разработки) до 2017-го (т.е. почти 20 лет) и просуществовало.
А потом эту секту грубо разогнали нафик и подтянули простых работяг, не замутнённых никакими предрассудками.
Почитывал периодически блог руководителя дотнетного направления (уже забыл как его), был рад, что его турнули.
Он писал всё правильно, но всё не о том...
Какой-то разрыв первого рода м/у пониманием требований разработчиков разных складов и подходов к задачам, ограничений современных архитектур и возможностей своей команды.
Маниловщина в чистом виде...
Например, такого пошиба типчик не выжил бы в тех условиях, в которых работаю я, он довольно быстро зарекомендовал себя как болтун низкой полезности и почти нулевого выхлопа.
Боже, его эксперименты с кодом были до того идиотскими в своей наивности, что я порой был в шоке, как он вообще на эту должность попал и почему так долго продержался.
Даже если сам чел был не идиот, но взятый им тон был для идиотов.
А значит, вольно или невольно таковым было позиционирование результатов работы его команды.
Было всё это видно еще тогда? — конечно было.
Периодически об этом говорилось, вы в привычной манере язвительно (т.е. контрпродуктивно) огрызались.
Со стороны — секта, ноль практичности, игнор насущных требований разрабов.
V>>Джава давно повернулась лицом к опенсорсу, но огромного кол-ва ревьюверов джава-машинки я не наблюдаю. S>А я — наблюдаю. Просто вы не вращаетесь в тех кругах, где принято пилить JVM.
Э, нет, я одно время (пару лет назад) наблюдал весьма плотно, поплотнее, чем за дотнетом.
(у нас есть версия продукта и для Джавы)
В экосистеме Джавы в разработке высокоуровневого энтерпрайз г-на народу пасётся прилично и ротация имеется, но на низком уровне одни и те же лица чуть ли не десятилетиями, любопытство со стороны минимальное.
Это приплызд.
В дотнете постоянно сыплют предложениями случайные люди и поток этот неиссякаем.
(сам репортил как ошибки, так и предлагал исправления/улучшения)
V>>Если джава не повторит за дотнетом поворачивание лицом к таким людям — постепенно уйдёт примерно туда же, куда ушел популярный когда-то Perl. S>Увы, не уйдёт. Но это оффтоп к данной дискуссии.
Про Перл тоже так думали, бо вменяемых альтернатив не было полтора десятилетия.
Но чуть заматерел Питон, потом выстрелил сразу же мощно JS-node — и досвидан.
Я не утверждаю асболютно, я говорю "если".
Ввели же генерики в Джаве, подсуетились... ))
И почему оффтоп в теме ".Net на Эльбрусах"?
Конкурент номер один дотнету — Джава.
Судьба дотнета во многом будет зависеть от судьбы Джавы и наоборот.
V>>Сначала стали контрибутить нейтивные фишки, и только затем подтянулась широкая общественность. V>>Т.е. между тем, как открыли в опенсорс и тем, как подтянулось приличное кол-во людей, прошло прилично времени. S>Хм. А кто контрибутил нейтивные фишки?
Изначально программисты MS, у которых почему-то стоит C/C++ в профиле.
Т.е. подкинули в проект портирования дотнета на линуха плюсовиков, по понятной причине.
И вот тут всё заверте...
