Pull to refresh

Comments 86

Извините, закидывайте меня чем угодно, но на любой конференции/семинаре после фраз:

«Эльбрус — высокопроизводительная и… архитектура процессоров»
И
«Сейчас производительность нашей программы распознавания паспорта на Эльбрус 4.4 и на x86 отличается уже не на порядок»

Вам бы заявили, что тезисы и выводы вашего доклада не совпадают.
UFO just landed and posted this here
Смотрите, я прихожу и слушаю доклад, в результате которого я должен увидеть и осознать, что вот этот самый эльбрус это то что нам сейчас нужно и мы поимеем такой то профит при переходе на его архитектуру.

В качестве примера, могу привести вам ту же GPU и CUDA в частности. Только когда свет увидел работы, показывающие реальное ускорение в 50-100 раз (не в 2 и не в 3, а на порядки!) на конкретных прикладных задачах, тогда и начался постепенный переход на GPU.

Сейчас же, после прочтения статьи, я ничего подобного по отношению к эльбрусу не увидел. Вы тут все сыпете множеством непонятных мне терминов, вроде как бы в теории все замечательно, но на деле мне — обычному разработчику, которому нужна максимум производительности при адекватных усилиях, не видно каких-либо этих преимуществ. Покажите мне многократный прирост (на порядки), который бы подтолкнул меня переходить на другую архитектуру (как это было с CUDA в свое время).
UFO just landed and posted this here
UFO just landed and posted this here
Код clang или gcc, кстати говоря, вполне себе можно просто прочитать на предмет закладок. А вот железо — нельзя. Поэтому линукс сойдет для того же минобороны, а винда — нет.

Lcc использовали, вероятно, потому что это компилятор изначально разрабатывался для легкого добавления новых архитектур. Он вообще сознательно упрощен оригинальными авторами. Соответственно, в смысле оптимизации, тем более под редкую платформу, оставляет желать лучшего.
> Lcc использовали
Lcc, который «Local C Compiler» или «Little C Compiler» и Lcc в Эльбрусе не имеют ничего общего, кроме аббревиатуры.

Разработка МЦСТ полностью собственная, умеет С, С++ и Fortran, оптимизации, много чего еще и, если мне память не изменяет, является сокращением от «eLbrus CC».
Серьезно? Сами тянут компилятор?! Прошу прощения, я не в курсе, по очевидным причинам Эльбрус даже в глаза не видел.

А подумал я на другой LCC, т.к. перепутал Эльбрус с Мультиклетом (https://habrahabr.ru/post/302776/). Они вроде использовали именно тот LCC.
> Серьезно? Сами тянут компилятор?!
С учетом того, что это исторически в России одни из лучших компиляторщиков, то ничего в этом странного не вижу. Бекенд, который собственно занимается оптимизацией и кодогенерацией у них свой.

А фронтенд говорят, что от Edison Design Group, но эта меньшая часть компилятора.

P.S. На эту тему был подкаст http://eax.me/eaxcast-s01e06/ «EaxCast S01E06, о разработке компиляторов и Эльбрусах».
Признаться, я несколько не в курсе российской тусовки компиляторщиков. Можно чуть подробней..? Компиляторы ведь дело такое, серьезный проектов на весь мир не очень много.

Я издалека темой интересуюсь, но до сих пор, например, с соответствующей русскоязычной литературой не сталкивался.
Вообще, на профильной программистской специальности, написание простейшего компилятора — это курсовая работа.
ТАКИХ компиляторов у меня самого полный Гитхаб :-)
Ну, вряд ли именно таких, если Вы говорите, что не сталкивались с русскоязычной литературой. Так-то со времён Гриса в теории этого дела мало что изменилось. Тем более, что для языка Си всю платформеннонезависимую часть можно взять готовую. Работа по написанию промышленно используемого кодогенератора и платформеннозависимого оптимизатора, конечно, небанальна, но это далеко не самое сложное в разработке процессора.

Помнится, в 90-е годы Виталий Мирянов в одиночку и без финансирования написал одну из самых популярных сред разработки под OS/2, Virtual Pascal. Вполне сравнимая задача.
Ну, если по-честному, я сталкивался еще будучи студентом с парой русских книг по теории компиляторов. И да, конкретно парсер, тем более для несложного Си, найти в наши дни очень даже реально.

Более того, я точно знаю, что за три-четыре месяца полноценной дневной работы можно сделать парсер и генератор кода для небольшого языка и несложной архитектуры, реальной или виртуальной. Сам делал пару раз в качестве развлечения и один раз по работе.

Но я не уверен, что аналог GCC или Clang — дело столь же подъемное.

Впрочем, ладно. Процессор и собственная архитектура вообще — дело гораздо более широкое, как вы вполне резонно заметили.

Мне на самом деле интересно, какая есть литература от русских авторов на тему компиляторов, поэтому и спрашиваю. Разумеется, речь не только о парсере, но и об остальных аспектах задачи.

Может, подскажете..?
Я знаю, что, например, Терехов (который Ланит-Терком) этим вопросом много занимается, в том числе и книжки пишет. Наверняка, и другие коллективы есть.

Что касается аналога gcc или clang, то ведь это и не нужно. Обычно народ делает просто свою собственную ветку gcc, в которой добавляет кодогенератор под свою архитектуру.
Посмотрел – вот ещё такую книжку нашёл: http://www.twirpx.com/file/714408/ Я её, правда, не читал, но у авторов учился в институте.
Собственно, эта плюс еще одна политеховская и были у меня в универе (питерский политех). Это сугубо теоретическая книга по теории компиляторов.

Но компиляторы — не только теория парсеров. Собственно, про практические аспекты книг я никогда не видел, к огромному моему сожалению.
Про практические вопросы мало пишут, как правило, это интеллектуальная собственность заказчика работ.
Пишут-пишут… У меня в читалке штук десять англоязычных книг про разные компиляторы, их архитекутуру, различные: lcc, gcc, LLVM, оптимизирующие компиляторы и т.д.

Вообще, в эпоху открытого кода этими вещами никого уже не удивить. Признаться, мое любопытство диктуется скорее уже коллекционными соображениями, чем недостатком материала на английском.

Тут выше кто-то заметил, что российская школа разработки компиляторов очень развита, ну мне и стало любопытно, какую литературу издают и читают.
Ну на уровне открытого кода как бы и нет проблем с вопросом. Эти решения хорошо известны и более-менее неплохо описаны. А вот если вы захотите, например, почитать про архитектуру современных оптимизирующих компиляторов IBM, тот увидите только самые общие тезисы в каком-нибудь IBM Sys. J. Примерно в духе статей того же Терехова.
Бывшие разработчики первой команды Эльбруса, писавшие компилятор под Эльбрус перебрались в Интел дописывать уже ICC под Itanium.
«У х86 есть SSE, AVX, а у Эльбруса вроде DSP и какие-то свои фичи; притом вряд ли их кто-то использует кроме самого МЦСТ в своих либах».

Позиция МЦСТ такова, что на платформе «Эльбрус» надо пользоваться высокоуровневыми языками C/C++ и Fortran и специальными библиотеками для них, а опускаться на уровень машинных команд можно разве что в исключительных случаях. Как бы то ни было, у их компилятора C/C++ есть флаги, включающие поддержку GCC-шных встроенных функций для работы с MMX, 3DNow, SSE вплоть до 4.2, XOP, AVX, FMA4, CLMUL, BMI, F16C, AES, — насколько я понимаю, некоторое из этого и так реализовано в железе (просто инструкции другие), а остальное эффективным образом конвертируется в нативные широкие команды.
«на платформе «Эльбрус» надо пользоваться высокоуровневыми языками C/C++ и Fortran» — странная позиция.

Подавляющие большинство операций в реальном мире не параллелятся, либо параллелятся слабо. Собственно поэтому для задействования этого параллелизма надо параллельно исполнять множество «потоков исполнения», а для того, чтобы их исполнять — они должны быть, но их нет.

Допустим, надо нам вычислить синус( вычислить полином) — его, конечно, расспараллелить можно, только это имеет мало смысла(90% нашего параллелизма будет простаивать из-за постоянных зависимостей по данным).

Решается это просто — надо считать не один отдельный синус, а много. Просто в теории. На практике эта задача сложнее векторизации, а даже векторизацию до сих ни один компилятор делать, кроме примитивных случаев, не умеет.

Да что там распараллеливание — даже банально зашедулить(раскидать инструкции по «каналам исполнения») один поток такая же непосильная для компилятора задача.

Проблема в самих языках и подходах к разработке/сборки.

Динамическая линковка? Нерешаемая проблема — компилятор просто не может получить код того же синуса, не может его заинлайнить. На уровне процессора её решить можно — как решить на уровне компилятора?

Раздельная сборка, статическая линковка? Много ли компилятором имеют вменяемое lto+ipo? Один? Сколько к этому шли? 10лет? До сих пор не работает без подпорок. Когда это будет в эльбрусе?

В конечном итоге эти(да и любые другие) языки просто не могут в параллелизм — да, компилятор может взять эту работу на себя, но много ли умеет гцц/шланг для х86? Сколько от этого будет иметь эльбрус?

В конечном на х86 радуются ipc в районе 2, при потолке ~4/6(фронтенд/бекенд) — толку с теоретических 23(или сколько там?) на эльбрусе?

Почему бы не сделать dsl пусть на основе C, со своей логикой вычислений? Зачем цпу с такой архитектурой? На эти вопросы нет ответа.

Тот же интел с итаником не смог. Повторяем ошибку?

Во многих реальных ресурсоёмких задачах основная вычислительная нагрузка приходится на реализацию нескольких стандартных операций. Условно говоря, если эльбрусовцы наваяли оптимизированную библиотеку матричных и векторных функций на ассемблере, то во многих прикладных областях этого вполне достаточно, чтобы обеспечить производительность, близкую к максимальной.

Хотя есть, конечно, задачи другого рода, именно алгоритмически запутанные, где значительную роль играет качество кодогенератора.
Спорное заявление. Я не знаю таких прикладных задач — возможно какие-то научные расчёты и строятся.

По поводу оптимизированной библиотеки — я описывал проблемы всех этих библиотек. Тем более эти библиотеки невозможно написать на асм — это всё должно быть машинная генерация. А зачем шедулить каждую операцию заново — проще написать дсл. А если есть дсл — зачем нужны эти языки? Только как скриптовая обёртка вокруг.

По поводу серебряных пуль. Тот же штеуд не может писать в память без nt, а nt собственно это обход кешей. Поэтому версия для работы в кешах не может работать вменяемое для данных больше кешей, а версия для памяти не может работать вменяемо для кешей.

ТС померил трупут л2(хотя и то навряд-ли, ибо 4/4GB/s даже для 600мггц смешно — это по ~два флоата лоад/стор на такт). И тут варианта два — либо библиотека от производителя слаба, либо процессор слаб сам по себе, либо ТС что-то не то померил.

По поводу операций. Функции с операциями — это тупиковый интерфейс. Допустим, нам надо сложить два массива, а потом как-то обработать. Нормализовать, отсеять, либо ещё что-то. Все эти операции для 10^5 упираются в llc, а значит мы просто так гоняем данные по кругу и греем воздух.

Делай мы это операцию не конвейерно, а параллельно — мы бы получили вторую, треть, десятую операцию бесплатно.

Т.е. вменяемый интерфейс это не просто функция — это паттерн доступа/обхода структуры данных + набор операций. Это не реализуемо, ибо опять же требует компилятор. Поэтому, собственно, это никто не использует.

Опять же — какая разница библиотека, либо нет. Реализациях этой самой библиотеки требует автоматических средств, иначе вменяемого качества не добиться. Если они есть — почему они не выкатываются, а если их нет — библиотеки не будет.
«Подавляющие большинство операций в реальном мире не параллелятся, либо параллелятся слабо. Собственно поэтому для задействования этого параллелизма надо параллельно исполнять множество потоков».

Если какая-то задача в принципе не распараллеливается, то при чём тут любой конкретно взятый процессор и компилятор? А если всё-таки распараллеливается для одной архитектуры, значит, можно как-нибудь распараллелить и для другой. Компилятор C/C++ помешает? Ну, если вы уже написали что-то для SSE, значит, вы пишете не совсем на C/C++, а на конкретном диалекте с использованием конкретных спецфункций, — этого добра и в МЦСТ-шном LCC хватает, как своего, так и GCC-совместимого.

«Надо считать не один отдельный синус, а много. На практике эта задача сложнее векторизации, а даже векторизацию до сих пор ни один компилятор делать, кроме примитивных случаев, не умеет».

Есть такая буква в библиотеке EML! Вычисление синуса элементов вектора — eml_Vector_Sin_32F, eml_Vector_Sin_64F. И, если верить утверждениям МЦСТ (я не проверял), компилятор в некоторых случаях может заменять обычный вызов скалярной функции sin() на вызов такой вот оптимизированной функции из библиотеки.

«Даже банально раскидать инструкции одного потока по каналам исполнения — такая же непосильная для компилятора задача».

Внезапно, именно этим LCC и занимается; собственно, на его оптимизациях всё и держится. Насколько он эффективен в среднестатистическом случае, судить не берусь, но сами МЦСТшники считают, что человеку не под силу с ним тягаться: если только вы не пишете ну очень критичный кусочек кода с большим потенциалом ручной оптимизации (для этого вы должны знать систему команд и учитывать тайминги каждой инструкции в составе широкой команды), не стоит даже пытаться смотреть в сторону ассемблера.
«Если какая-то задача в принципе не распараллеливается, то при чём тут любой конкретно взятый процессор и компилятор?»
Я уже рассказал как это делается. Её не надо паралеллелить — её надо коневеизировать( я не знаю как пишется это слово и есть ли он вообще).

Мы не может распараллелить одну операцию, но мы может параллельно делать много.

Штука в том, что любая обработка данных — это множество одинаковых, последовательных операций на разными данными.

Берём обычный цикл while() {...}, где тело независимо. Естественно он заанролится, но как? Любой компилятор, любой программист сделает просто набор последовательных блоков копипастой.

Собственно для этого и существует out of order execution. х86 сделает из этого множество независимых потоков исполнения.

Но проблема у х86 в том, чего его ооо существует только в рамках окна определённой длинных.

Т.е. если длинна тела цикла шире этого окна — ооо идёт в мусорку. Т.е. это актуально для х86. Эту проблему никто до сих пор в х86-компилятор не решает. Даже её подзадача векторизация не решена.

>>Компилятор C/C++ помешает?
Помешает сам язык и подходы к разработке. В рамках этого языка не таких понятий. Этим нельзя рулить. Даже передовые компиляторы эту проблему решить не могут, да и она не решаема в полной мере.

>>Ну, если вы уже написали что-то для SSE, значит, вы пишете не совсем на C/C++, а на конкретном диалекте с использованием конкретных спецфункций, — этого добра и в МЦСТ-шном LCC хватает, как своего, так и GCC-совместимого.
Ну это очередной подтверждение того, что эти(да и любые другие) языки не подходят. Да и их диалекты с набором интерфейсов к кастылям компилятора так же — об этом я то же писал.

Собственно поэтому и приходится кастылять на асм, ибо шедулер симдов в компиляторе никакой и ничем ты с этим не сделаешь. Ни язык, ни компилятор этому не способствует — на их уровне нет таких понятий. Всё это дети скалярной архитектуры.

«Есть такая буква в библиотеке EML! Вычисление синуса элементов вектора — eml_Vector_Sin_32F, eml_Vector_Sin_64F.»
А если мне нужен синус и косинус сразу, а если мне надо их на что-то помножить? Тупик. Но молодцы, что это сделали — нигде такого не видел.

>>И, если верить утверждениям МЦСТ (я не проверял), компилятор в некоторых случаях может заменять обычный вызов скалярной функции sin() на вызов такой вот оптимизированной функции из библиотеки.
Это имеет мало смысла. Если и может, то только для случая while() {b[i] = sin(a[i]);}. Даже если там будет паттерн сложнее и он в него сможет — это будет конвейер. Мы обойдём массив для записи в него синусов, потом для умножения их на что-то там.

Реально же это мало кому поможет.

>>Внезапно, именно этим LCC и занимается; собственно, на его оптимизациях всё и держится.
Я описывал основные проблемы — они решены? У ТС«а я не видел ни одного упоминания lto, ipo — без этого это не имеет смысла. Ваятели очень любят раскидывать всё по файликам, ибо раздельная компиляция. Это тупик для компилятора.

>>Насколько он эффективен в среднестатистическом случае, судить не берусь
Я уже объяснял — это задача, подзадачей которой является векторизация. Векторизация даже в передовых компиляторах в зачаточном состоянии. Они собираются переплюнуть гцц?

>>но сами МЦСТшники считают, что человеку не под силу с ним тягаться
Враньё.

Сила человека не в раскидывании, а в умении реализовать программу с учётом особенностей железяки. Это стоит много — само же раскидывание не стоит ничего.

Изначально это подлог. Вас пытаются обмануть подменой понятий. В этом сравнении предполагается, что человек будет решать ту же задачу что и компилятор в уме, но это не так. Никакой человек не пишет на ассблере считая тайминги на листочке. Всё это автоматизируется. Для частного случая, когда человек может подбить код под генератор — это задача не представляет никакой сложности и решается оптимально.

>>для этого вы должны знать систему команд и учитывать тайминги каждой инструкции в составе широкой команды
Эльбрус это вменяемая архитектура( жалко что мало пригодная в реальном мире), поэтому с нею не должно быть никаких проблем. Что я имею ввиду — в ней нет подводных камней, в ней не 16регистров и для неё есть вменяемая документация.

х86 в этом плане сложнее своей огороженностью. И для х86 ничего не мешает людям( в частности мне) писать оптимально на асм, а вот компилятор этого как не мог так и не может.

«Проблема у х86 в том, что его внеочередное исполнение существует только в рамках окна определённой длинны. Если длина тела цикла шире этого окна — ооо идёт в мусорку».

Эльбрус имеет гораздо более широкое окно, что в сочетании с большим количеством регистров позволяет замахиваться выше, чем x86, — как, например, в случае с шифром ГОСТ, тело которого удаётся полностью развернуть, из-за чего Э4С@800 оказывается вдвое быстрее i7-2600@3400.

«А если мне нужен синус и косинус сразу?»

Вы не поверите, но таки eml_Vector_SinCos_32F и eml_Vector_SinCos_64F. Вообще, там 60 страниц одного только перечисления названий функций. К тому же, они открыты для предложений: если функция объективно полезная, можно добавить новую.

«Никакой человек не пишет на ассемблере, считая тайминги на листочке».

Даже на x86 без учёта времени выполнения инструкций — почти никак (ну, как минимум надо себе представлять, какие инструкции предпочтительнее, и какие зависимости они создают), то на архитектурах с явным параллелизмом всё на этом же и держится. Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?
>>Эльбрус имеет гораздо более широкое окно
Эльбрус не имеет окна — он не имеет out-of-order execution — он in-order.

>>что в сочетании с большим количеством регистров позволяет замахиваться выше,
Регистров у х86 на уровне архитектуры действительно мало — вот бы интел пробросил все сотни регистров на уровень архитектуры, которые внутри используются для ренейма.

На самом деле vex3 частично решает проблема малого кол-ва регистров и на вычислениях их хватает.
>>чем x86, — как, например, в случае с шифром ГОСТ, тело которого удаётся полностью развернуть, из-за чего Э4С@800 оказывается вдвое быстрее i7-2600@3400.
Проблема в том, что тело изначально не написанное под разворачивание развернуть не получится без lto и ipo — есть ли это в их компиляторе, работает ли оно?

По поводу госта. Можно мне увидеть сорцы под х86? Как я могу повторить результаты бенчмарка? Без всего этого это не более чем булшит.

>>Вы не поверите, но таки eml_Vector_SinCos_32F и eml_Vector_SinCos_64F
В глибц есть sincos — это можно так сказать «стандартная функция» и наличие её не достижение и меня никак не удивляет. Зачем передёргивать?

Мне надо записать синус в один массива — косинус в другой, либо в один. Помножить их на что-то. Ещё какие операции добавить нужные мне. Что делать?

В этом проблема — никто и никак не сможет сделать нужную мне функцию. Для этого придётся делать из них пайплайн, а это прощай производительность. Я уже объяснял почему.

>>если функция объективно полезная, можно добавить новую.
Нужна не функция, а возможность написания собственных операций, которые бы работали в один проход.

>>Даже на x86 без учёта времени выполнения инструкций — почти никак
Почему для вас отсутствие вычислений в блокноте есть отсутствие вычислений? Есть такая вещь как кодогенерация и программные вычисления. Я же уже отвечал на этот вопрос загодя. Написание такого генератора для примитивного случая(а случай там примитивен — вся обвязка си и не трогается. Остальное без ветвлений с минимумом операций) сложности не представляет.

Берём кусок написанный кое-как — строим дерево — раскидываем. Нету операций — размножаем деревья — сливаем. Порты простаивают — пытаемся руками ребалансировать код(замена шафлов на битопы, разные коверторы, реализация через разные типы операций и прочее). Мало регистров? Минимизируем руками. Эксплуатируем ренейм. Уперлись во фронтенд — бахаем побольше micro-fusion и прочих куллстори.

>>Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?
Этот вопрос не имеет смысла — причины написал выше.
> Эльбрус не имеет окна — он не имеет out-of-order execution — он in-order.

На этапе исполнения скомпилированного кода — да
Однако на этапе компиляции — он именно out-of-order с «гораздо более широким окном», как упомянуто выше.
Во-первых об этом я выше писал, хотя может и не в этом ветке. Во-вторых это очередной подлог. Для х86 ничего не мешает на уровне компилятора делать какое угодно окно. Это не является плюсом.

В-третьих в х86 оно существует РЕАЛЬНО, а в эльбрусе ПОТЕНЦИАЛЬНО и именно о сложности реализации этого ПОТЕНЦИАЛЬНО я и говорю.

Более того, эльбрусовская архитектура, по сути, принадлежит к классу MIMD. Поэтому потенциально она гораздо более гибче, чем x86-шный SIMD.
Даже потенциально это маловероятно. Мало есть задач, где симд проигрывают.

Опять же — симд проигрывают в исполнении множества разных потоков команд одновременно, но это не реализуемая мечта на уровне компилятора. И опять же реально существующая в интеле в их гипертредах.

Как вы себе представляете слияние двух потоков команд на уровне языка(С/С++)? Как сделать слияние двух потоков разных тредов/процессов на уровне компилятора?

> Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?

Это действительно могло бы стать проблемой, если бы не наличие конвейера выполнения команд. О котором многие почему-то забывают))
Летенси инструкций в любом случае нужно для снятия результата. Конвейер тут никак не помогает. Конвейер даёт возможность каждый такт накидывать инструкций не обращая внимание на другие, но опять же надо учитывать куда и что ты отправил ранее, ибо «конвейер» он не один.

> Как бы то ни было, у их компилятора C/C++ есть флаги, включающие поддержку GCC-шных встроенных функций для работы с MMX, 3DNow, SSE вплоть до 4.2, XOP, AVX, FMA4, CLMUL, BMI, F16C, AES, — насколько я понимаю, некоторое из этого и так реализовано в железе (просто инструкции другие), а остальное эффективным образом конвертируется в нативные широкие команды.

Насколько понимаю, эльбрусовская архитектура отменяет необходимость в таких интеловских костылях, как SSE и AVX. Хотя компилятор поддерживает «интринсинки» в целях совместимости с исходниками для x86
Эльбрус это не только SIMD, но и гораздо более гибкий MIMD
> Даже х86 трудно сравнивать между собой, даже среди интелов между собой.
Почему же трудно? Тем более у вас все правильно написано Intel Core i7 4750HQ работает быстрее Intel Core2 Duo E8400, а Intel Core2 Duo E8400 работает быстрее AMD Athlon 5350. Или вас смущает что тактовая частота E8400 выше? Так «меряться» частотой перестали где-то после 4 пентиума. А AMD просто шлак :)
А если сравнивать AMD K6-2 3Dnow! с Cyrix Cayenne?
UFO just landed and posted this here
Ну так автор же пишет, что оптимизация для Intel и ARM заняла несколько лет.
Не можем оспорить ваше утверждение. Действительно, на любой конференции/семинаре после выступлений звучат самые разные заявления. Иногда верные, иногда безумные, иногда возникшие в результате недопонимания. Также ясно, что процитированная вами первая фраза может вызывать весьма эмоциональную реакцию. Однако составлялась она в здравом уме и твердой памяти, и она верна. А эмоциональный фон мог помешать увидеть, что объектом оценки в первой фразе выступает архитектура, а во второй приводятся экспериментальные данные о конкретной модели процессора. Производительность процессора определяется, помимо архитектуры, тактовой частотой (и не только, но не будем усложнять). Тактовая частота определяется в большой степени тех. процессом. Для нас представляется важным, что архитектура действительно является эффективной, как и обещал производитель. Это значит, что мы продолжим тратить своё время (а, следовательно, деньги) на освоение третьей основной для нас архитектуры (после Intel и ARM) в расчете на дальнейшее повышение производительности за счет смены тех. процесса. Догонять по тех. процессу всяко легче, чем усовершенствовать архитектуру. Поймите правильно — продукты мы делаем уже сейчас, производительности хватает. Но, как говорила Черная Королева, «здесь… приходится бежать со всех ног, чтобы только остаться на том же месте». И мы видим у МЦСТ приличный задел на этот самый бег.
Прошу прощения, а каких единицах вы измеряете эффективность архитектуры? Вот для длины метры, для массы граммы. Меня бы устроило бы сравнение с Intel/ARM но именно эту информацию вы не даете. Какая разница сколько лет что вы оптимизируете. Сравнительные данные могли бы стать реперной точкой от которой можно было бы считать производительность через 3 месяца, через пол года. Пока извините выглядит как маркетинговый булшит. Благо что по Intel, что по ARM аналогичные дифирамбы по архитектуре можно нарыть вагон. И по оптимизации, и по энергоэффективности, и по много еще чему.
Архитектура и частота так же взаимосвязанных — на простом процессоре с длинным конвейером проще наращивать частоту. Для примера есть П4, который на старом тех процессе имел высокие частоты. А те же GPU даже на современных ТП не могут достичь высоких частот.
Разницу между архитектурой и производительностью программы улавливаете? Если хотите сравнить архитектуры — сравните их пиковую теоретическую производительность. Если хотите сравнить реализации неких алгоритмов — сравните скорости работы программ. Не надо смешивать всё в одну кучу.
Мы не стали сравнивать производительность с Intel или ARM

Вот так, на самом интересном месте облом.

Кстати, а EML таки задействует встроенный в процессор DSP, или она работает на основных ядрах, но написана оптимально под архитектуру?
EML таки задействует встроенный в процессор DSP, или она работает на основных ядрах? Судя по документации, EML таки не задействует DSP; и вообще, компиляция для DSP — это особое дело. В любом случае, процессор «Эльбрус-4С», на основе которого построен используемый авторами сервер «Эльбрус-4.4», не имеет DSP-ядер.
Все верно, на этом сервере нет DSP, выигрыш достигается за счет более эффективной загрузки АЛУ.
Как соотносится достигнутая вами производительность к теоретической? Во что упёрлись после оптимизации?
В данный момент мы перешли на следующий этап оптимизации и пока явных барьеров не видим. Вопрос времени и более глубокого изучения возможностей. Мы хотим довести время распознавания до 1 секунды и дальше уже снижать число потоков. А пока что уперлись в лето :)
Честно говоря, хотелось узнать, сколько Гфлопс и/или Гб/с было достигнуто (если не коммерческая тайна). Может, вы уже 80% ресурсов исчерпали, и дальше расти особенно некуда.
UFO just landed and posted this here
Оптимизация программы под архитектуру = насколько сильно ты загружаешь железо расчётами. Не путайте с оптимизацией алгоритмов. Так что вопрос — нормальный.
UFO just landed and posted this here
Проц от Intel решает некую эталонную задачу за время Х. Эльбрус решает ту же задачу за время 5Х. Проц от Intel выдаёт 85% теоретической производительности (софт давно написан, отлажен, оптимизирован). Эльбрус выдаёт 30% (мало что оптимизировали? упёрлись в память? медленный процессор? молодой компилятор?)

Меня интересует качество реализации (насколько эффективно используется вычислительный ресурс), а не качество алгоритмов. В статье прямо так и написано — кодовая база (то есть алгоритмы) для разных платформ одинаковые, поменяли 100 строчек под условной компиляцией. Если команда автора быстро выжала из Эльбруса все соки, то оптимизировать под него условно легко. Если не выжала — оптимизировать под него условно нелегко.

Теперь ясно?
UFO just landed and posted this here
Уже теплее. Поэтому сначала смотрим на то, сколько данных мы читаем и пишем (не упёрлись ли мы в память и не голодают ли АЛУ), а затем — сколько арифметики в секунду делаем (flops, ipc и прочее). И только потом лезем на уровень ассемблера (не факт, что придётся, может intrinsic'ами отделаемся).

Таким образом, полученный bandwidth и flops (ipc) дают поверхностную, но очень важную оценку. Возвращаемся к первому вопросу.
>>результат один и тот же но за разное время.
Не верно. х86 умеет распознавать паттерны для зануления регистров и sub/xor ничем друг от друга не отличается, как и прямое зануление через присваивание.

>>В случае пары инструкций — смотрим в справочник, там написано за сколько тактов оно выполнится, дальше смотрим на мегагерцы.
Что есть «выполняется»? Это когда результат будет получен, когда можно исполнить следующую? Если первое, то где основание для определения суммы этого времени как результирующие время исполнения набора инстуркций опять же в трактовке номер один.

Время можно получить только эмуляцией потока исполнения — никак иначе.

>>В случае сложных задач на х86 можно получать пенальти (простои)
Это не простои а дополнительная латенси для доступа к данным/а в следствии и результатам инструкиций, либо сами результатам.

Опять же это пайплайн и без контекста в котором летенси что-то определяет это ничего не стоит.

>>отсутствием данных в кеше
Отсутствие данных в кеше стоит доступа их из памяти к пенальти не имеет никакого отношения.

>>и некоторые инструкции когда рядом могут параллельно выполнятся
Не верно. Это утверждение не имеет смысла. По определению при out-of-order execution нет такого понятия как «рядом».

Да и вообще нет такого понятия. В х86 есть «каналы»/пайплайны по амд/порты по штеуду исполнения.

Каждый порт объединяет доступ к набору исполнителей( либо там заморочки более сложны — неизвестно). Они абсолютно независимы. Там есть свои заморочки с пенальти между переключениями исполнителей, но опять же — это +летенси к самой операции, а не лок исполнителя.

Исполнятся параллельно инструкции могут как в рамках одного пайплайна, так и в рамках разных «портов». Рядом/не рядом — от этого ничего не зависит.

Пайплайн — это трупут 1оп/такт, когда в мануале написано 0.5 — это значит, что эту операцию может исполнять 2порта.

>>плюс есть ещё предсказание переходов и вообще переходы могут очищать конвеер
Переход просто инвалидирует те инструкции, которые начали исполнятся/исполнились спекулятивно.

Переходы — это алгоритмические заморочки. Если он есть — он будет всегда. Другое дело, что у него может быть разная цена на разных процессорах, только в этом и есть смысл сравнения.

>>Даже результаты бенчей memcpy(), memset() оптимизированных под платформу трудно однозначно интерпретировать.
Просто. Только надо понимать что ты и зачем измеряешь. Что ты и для чего используешь.

Надо просто в голове иметь модель рабочую, с разными уровнями «памяти»(уровни кешей, уровни оперативной памяти, уровни иной памяти), а не пихать всё в одну кучу.

>>Оптимизировать легко когда время выполнения команд предсказуемое
Оно всегда предсказуемое — написано в мануалах, либо измеряется.

>>и один и тот же код может исполнятся в разы и порядки быстрее/медленее на разных процах.
Можно увидеть примеры? Единственные примеры, которые можно сюда притянуть за уши — это сложные инструкции, но они используются редко и ими можно пренебречь.

UFO just landed and posted this here
Я имел ввиду примерно то же самое. Спасибо за уточнение.
UFO just landed and posted this here
В данный момент мы предлагаем всю нашу линейку продуктов по распознаванию и у нас есть совместный продукт с МЦСТ.
UFO just landed and posted this here
В очень общих чертах алгоритм таков: поиск документа и наведение зон, поиск полей, распознавание полей. Наибольший эффект был достигнут на первом этапе. Про оптимизацию отдельных алгоритмов мы планируем часть 2.
… а потом дорисовываем сову
Всего за несколько месяцев нам удалось не только добиться правильной работы распознавания


А можно в человекочасах?
И какая квалификация персонала потребовалась для адаптации?
И на какой кодовой базе все происходило (кол строк измененных для совместимости/общее кол строк кода)?
И как вообще верифицировалась правильность?
И насколько все изменения совместимы между платформами (не нужно ли поддерживать два репозитория с кодом)?
1. Правильность распознавания проверяется прогоном на референтном датасете (1000 изображений паспортов).
2. Первая рабочая версия — 3 дня работы одного человека, после чего началась оптимизация производительности (3 ч.м.).
3. Для адаптации заменили порядка 100 строчек кода из ~20 мегабайт кода, все изменения обратно совместимы.
4. Оптимизированный код в том же репозитории, вызовы EML под условной компиляцией.
5. Квалификация: студенты и аспиранты, для нас — обычная.
Я правильно понял, что юнит и модульных тестов на проекте нет? Только функциональные

Квалификация — студент/аспирант мне не знакома. Если нет возможности оценить с точки зрения тайтлов, то хотя б, какой примерный опыт работы в коммерческой разработке софта в данной области знания?
Первая рабочая версия — опыт работы 4 года.
Оптимизация — опыт работы 2 и 4 года.

Тесты есть, проходят.
Распознавание паспорта РФ на платформе Эльбрус. Часть 1

Представил на секунду следующую картину: оператору эльбруса на экран выводится скан паспорта и оператор начинает его распознавать
Ожидал увидеть строку — из 25,000 юнит тестов сломалось 300.
Зачем нужны «25000 юнит тестов» одной операции, которая может либо работать, либо не работать?
От всей статьи, ждал одного слова. Да или Нет.
Сопоставима скорость работы реального приложения на Эльбрусе со схожим процессором х86 или нет?
ИМХО, на данный момент, это самый главный вопрос об Эльбрусе. Что процессор может на самом деле?

В статье вполне достаточно информации на этот счет. «Эльбрусы» с частотой 0.8ГГц и с 64-битными векторами отстают от Интелов менее, чем на порядок. А Интелы — это, надо полагать, Haswell с 256-битным AVX-2 и с 3+ ГГц. С учетом того, что, как упомянуто в статье, оптимизация кода под Эльбрусы только-только началась, а под Интел с АРМ этот процесс шел годами, результат вполне себе неплохой.

Понятно, что Эльбрус-4С на сегодня далек от вершин производительности. Производительность камня — на уровне Core2 Duo 2ГГц. Но это не вина Эльбруса и МЦСТ. Наоборот, с учетом тех крох, которые выделялись и выделяются на разработку новых процессоров, мцст-совцы совершили подвиг. Порядок этих крох примерно такой: на разработку Эльбруса-8С контрактом было выделено 25млн$ на 4 года. В то время как мировые производители процессоров средней руки тратят на НИОКР не менее 1 миллиарда$ _ежегодно_! (Интел — так все 10 ярдов). Что называется, почувствуйте разницу. При таком подходе наивно ожидать, что продукция МЦСТ будет на равных с мировыми конкурентами. Тем более, нет никаких оснований этого с праведным гневом требовать, как поступают некоторые.

А вот если бы у государства были здоровые приоритеты на развитие страны, следствием чего было бы надлежащее финансирование и размах работ, сейчас уже был бы в серии какой-нить 2ГГц Эльбрус-16С с 128-битными, и это как минимум.

Да, авторам — огромное спасибо за статью! Очень познавательно! Молодцы! Ждем продолжения
Странно производить продукт, если он никогда не выйдет на уровень конкурента

Странно продавать продукт своим за бешенные деньги, если свои и так уже заплатили за него из налогов
Странно ожидать выхода на «уровень конкурента» при уровне финансирования, который ниже на порядкИ.
Как альтернатива — разгон МЦСТ и закрытие отечественной школы проектирования процессоров.
Пока эта школа существует, есть надежда и на достижение «уровня конкурента», хотя бы теоретическая…
Плюс к этому, есть такая важная вещь, как независимость страны. В данном случае — по части создания процессоров (и чипсетов к ним).
Некоторым подобные вещи, конечно, глубоко побоку, но кому интересно их мнение?

Ну и потом, Интел и АРМ — это не те конкуренты, которые в состоянии предложить доверенную платформу российской разработки. Т.е. не все меряется исключительно быстродействием.

Что касается «бешеных денег», то все определяется величиной серии. Которая сейчас мизерная.

Доверенность платформы никак не зависит от проектировщика или производителя.
Она зависит от открытости и наличия большого числа исследователей, которые не дадут положить закладку

Пока что разработка больше похожа на последствия синдрома NIH. Что впринице хорошо, если б оно было направлено на массовый, а не локальный рынок.

Серия всегда будет мизерная, если она ориентируется на мизерный рынок. Что никак не оправдывает цены за, по сути, опытные образцы

ПС: характерно, что «еллекторату» внушили, что есть только один способ решения проблемы —
разгон МЦСТ
> Доверенность платформы никак не зависит от проектировщика или производителя.

Да ну?

> Она зависит от открытости и наличия большого числа исследователей, которые не дадут положить закладку

Степень открытости как раз целиком зависит от политики производителя.
Сомневающиеся могут попытаться получить исходники интеловских процессоров на уровне Verilog RTL

> Серия всегда будет мизерная, если она ориентируется на мизерный рынок.

На другой при текущих объемах финансирования замахиваться нет никакой возможности. Это понятно?

> Что никак не оправдывает цены за, по сути, опытные образцы

Одному из законов производства, в соответствии с которым себестоимость продукции обратно пропорциональна размеру серии, нет никакой необходимости оправдывать что-либо. Он просто объективно существует. Как таблица умножения.

Что насчет опытных образцов, то это не так. Они серийные, потому как камни отлажены и выпускаются серийно. Опытными можно назвать инженерные образцы, напечатанные в «шаттле». Но эту стадию Эльбрус-4С давно прошел.
Подскажите, пожалуйста, название такого открытого производителя и хотя бы одну- две группы исследователей топологий микропроцессоров, работающих не на контрактной основе.
Выйти по какому критерию? По критерию производительности? Этому ничего не мешает.

Сила интела не в том, что он быстрый(хотя хасвел скакнул не слабо), а в том что он может исполнять плохой код с приемлемой производительностью. Естественно здесь с ним тягаться никто не может, да и не будет.

В данном случае вся «обвесочная» сложность была выпилена из процессора. Это дало возможность выпустить «быстрый» процессор без ресурсов интела.

Потенциально его слабость перед интелом можно решить сильным компилятором, при этом на уровне компилятора эта задача решается на порядки проще и оптимальней.

Сейчас же даже без компилятора производительность можно снять руками(прям как на интеле), а компилятор потихоньку пилится. Это решение намного лучше, нежели пытаться повторить достижения интел.

Продукт продаётся за бешеные деньги лишь потому, что стоит он бешеных денег.

Не понимаю почему они так противятся популяризации своего детища среди энтузиастов. Я не думаю что это прям очень дорого — заказать дополнительно, либо сделать версию ширпотребного качества. Хотя зная паникёров и всёпросральщиков в интернетах — я понимаю их мотивацию.

В целом, я не особо верю в то, что они, да и кто-либо вообще может сделать вменяемый компилятор С/С++ для данной архитектуры. Но пусть делаю — я рад за них.
Выйти по какому критерию?

по тому что указали выше
Понятно, что Эльбрус-4С на сегодня далек от вершин производительности.


Продукт продаётся за бешеные деньги лишь потому, что стоит он бешеных денег.

Деньги уже уплочены. Зачем брать второй раз?

>>по тому что указали выше
Я объяснил. Эльбрус не далёк до вершин — далёк от вершин конпелятор. Тем более под х86 они так же далеки от вершин и всё надо делать руками.

х86 выигрывает из-за того, что просто технологичней и своей архитектурой, которая более приспособлена для исполнения кода такого качества, который производят нынешние программисты, языки, их рантаймы и компиляторы.

Были бы у меня реальные спеки эльбруса — я бы мог сравнить, а так заявлять безосновательно о том, что он говно — я не готов.

>>Деньги уже уплочены. Зачем брать второй раз?
Откуда информация? За что уплочены — за разработку? За реализацию? За что?

Скорее всего оплачена только разработка и тестовые стенды/прочее железо. Далее дали чуть бабок на партию, а дальше крутись как хочешь.

Я не знаю сколько и что там стоит, но если нифа из сети верна и себестоимость самого чипа копейки, то почему они не заказали сразу большую партию — пусть бы продавали за столько же, но и выкатывали энтузиастам.

Возможно так нельзя и им надо отчитываться, возможно они не хотят, либо не знают как. Возможно обвязка стоит денег, но что мешает сделать партию материнок из ширпотреба?

Я так и не понял какие у вас претензии. Их можно ругать за многое, но явно не за то, за что ругаете вы.

Тем более цена у них как у серверных интелов. У обывателя пригорает только из-за сравнения с десктопным железом. Сколько флопсов в даблах выдаёт игровая видяшка? Как х86. Сколько там стоит e5-й хеон? Либо 2011 десктоп? У 2011 трупут рамы в 2раза выше, чем у 1055/6, либо какие там щас. Собственно как и у е5 по сравнению с е3.
>Я объяснил. Эльбрус не далёк до вершин — далёк от вершин конпелятор. Тем более под х86 они так же далеки от вершин и всё надо делать руками.

Это в мемориз))
Как раз компилер в случае с VLIW — просто немерянно крут по сравнению с компилерами для Out-of-order процессоров.

>х86 выигрывает из-за того, что просто технологичней и своей архитектурой, которая более приспособлена для исполнения кода такого качества, который производят нынешние программисты, языки, их рантаймы и компиляторы.

Насчет архитектуры — набор бездоказательных утверждений. Как раз архитектура Эльбруса — гораздо гибче и гармоничней в сравнении с x86, потому как в ней отсутствуют многочисленные костыли x86, вроде SSE и AVX.
А вот насчет технологичности — в самую точку. С такой низкой ТЧ (0.8ГГц) мерятся с Интелами бесполезно. Проблема в том, что физдизайн Эльбрусов выполнен на основе standard cells, в то время как Интеловские камни — с использованием очень дорогостоящего full custom design. По этой причине, в основном, ТЧ Эльбрусов такая низкая (хотя на этот счет есть и ограничения самой архитектуры)
Ну и надо иметь в виду, что ядро Эльбруса-4С — это, по сути, E2K образца 1999г, только с б0льшими кэшами. Более-менее заметные изменения в архитектуре появились в Е8С, когда добавили 2 FPU. Хотя, по хорошему, давно бы пора ввести те же 128 векторы. Но это из серии «лучше быть богатым и здоровым»: все упирается в мизерное финансирование и недостаток людских ресурсов небольшой, по сути, конторы МЦСТ.
>>Как раз компилер в случае с VLIW — просто немерянно крут по сравнению с компилерами для Out-of-order процессоров.
Какое отношение компилятор имеет к архитектуре? Правильно — никакое. Генерировать код можно с ООО на уровне инструкций хоть для ООО-процессоров, хоть и для не-ООО. Вернее для ООО — это и делается, правда руками, ибо на уровне компилятора это в зачаточном виде, да и я объяснял когда это надо и почему это надо.

>>Насчет архитектуры — набор бездоказательных утверждений.
Попытка не имеет смысла — не важно кто и что приписывает к моим утверждениям — они ничего не теряют. Если они не верны — их можно опровергнуть, а если это не можется — надо хотя-бы попытаться доказать утверждение в адрес моих утверждений, ибо в противном случае я могу написать то же самое.

>>Как раз архитектура Эльбруса — гораздо гибче и гармоничней в сравнении с x86,
Архитектура х86 — протухшее дерьмо и никого она не интересует. Её никто не поменяет и даже в эльбрсе кастыляют транслятор. На уровне микроархитектуры, которая всех и интересует, никакого х86 нет.

Говорить о чём-то иметь смысл будет тогда, когда компиляторы упруться хотя-бы в х86.

>>потому как в ней отсутствуют многочисленные костыли x86, вроде SSE и AVX.
С чего вдруг симды — это кастыли? Когда эльбрус дойдёт до производительности х86 — тогда там симды появятся, если уже не появились( судя по х2 флоат вс дабл — флоат там накастылен на базе дабла — т.е. типичные симды).

Кстати — видя это http://www.elbrus.ru/files/521dd0/256487/1a773c/000000/2014-04-19_160400.png у меня возникает вопрос — каждый «канал исполнения» — это «широкий канал», либо под одну инструкцию?

>>С такой низкой ТЧ (0.8ГГц) мерятся с Интелами бесполезно.
Мерятся с интелами бесполезно не из-за ТТ, а из-за тех причин, что описал я.

Слабый компилятор и невозможность написать нормальный в рамках текущей экосистемы и языков.

Простите, но фраза «какое отношение компилятор имеет к архитектуре» звучит, скажем так, чересчур громко.

Компилятор — или его бэкэнд — пишется под конкретную архитектуру. Некоторые архитектуры без корректного компилятора вообще не имеют смысла.

Например, тот же Эльбрус.
>>Простите, но фраза «какое отношение компилятор имеет к архитектуре» звучит, скажем так, чересчур громко.
Звучит так, как должно звучать. Никакие архитектуры друг от друга не отличаются. Что ООО, что не-ООО. Разницы нет — в любом случае компилятор обязан уметь шедулить инструкции сам. Другое дело, что никакой(из тех, что я знаю) компилятор это делать не умеет, ибо зачем — когда есть ООО.

>>Компилятор — или его бэкэнд
Бэкэнд — это малая часть компилятора. Остальная часть архитектуро-независима( вернее как — естественно зависима, но скорее от более обобщенной архитектуры c «обычными» инструкциями).

>>пишется под конкретную архитектуру.
Архитектура — это лишь таблица трансляции операций. На этом архитектура закончилась.

>>Например, тот же Эльбрус.
Почему же — работает и без вменяемого компелятора, правда хуже, чем х86 в равных условиях, но из этого ничего не следует, кроме более серьёзных требований к компилятору для работы и хоть какой-то производительности.

Вся та логика, что требуется для эльбруса — требуется и для х86. Шедулинг не ограничен окном в сотню инструкций.

В конечном итоге разница только в том, что для эльбруса это собирается в одну, а для х86 во множество инструкций, которая так же представляет из себя «одну».

Опять же, ещё раз — если чего-то нет — это не значит что этого не надо. И если мы говорим о гипотетически «идеальных» компиляторах — они идентичны за редкими исключениями именно на уровне генерации машинкодов.
Ответы, которые мы получили для себя:
1. Процессор — рабочий.
2. Набор инструментов для разработки — имеется.
3. Поддержка и консультации — имеются.
4. Документация — есть (по ГОСТу).
5. Нужная скорость работы нашего софта — достижима (при должной оптимизации).
6. Интересно — очень!
7. Идем ли дальше — да.
Кроме того, в процессе работы над Эльбрусом мы улучшили производительность и на других платформах.
Если кратко, то вот так.
Sign up to leave a comment.