После обработчика она будет продолжена с того места, где оно упало. И будет бесконечно пытаться прочитать не читаемое. Наверное я криво сформулировал вопрос.
Как продолжить программу дальше? Разрешить рид перед завершением? А как тогда потом поймать другие?
>>Как раз компилер в случае с 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ГГц) мерятся с Интелами бесполезно.
Мерятся с интелами бесполезно не из-за ТТ, а из-за тех причин, что описал я.
Слабый компилятор и невозможность написать нормальный в рамках текущей экосистемы и языков.
Летенси инструкций в любом случае нужно для снятия результата. Конвейер тут никак не помогает. Конвейер даёт возможность каждый такт накидывать инструкций не обращая внимание на другие, но опять же надо учитывать куда и что ты отправил ранее, ибо «конвейер» он не один.
Даже потенциально это маловероятно. Мало есть задач, где симд проигрывают.
Опять же — симд проигрывают в исполнении множества разных потоков команд одновременно, но это не реализуемая мечта на уровне компилятора. И опять же реально существующая в интеле в их гипертредах.
Как вы себе представляете слияние двух потоков команд на уровне языка(С/С++)? Как сделать слияние двух потоков разных тредов/процессов на уровне компилятора?
Во-первых об этом я выше писал, хотя может и не в этом ветке. Во-вторых это очередной подлог. Для х86 ничего не мешает на уровне компилятора делать какое угодно окно. Это не является плюсом.
В-третьих в х86 оно существует РЕАЛЬНО, а в эльбрусе ПОТЕНЦИАЛЬНО и именно о сложности реализации этого ПОТЕНЦИАЛЬНО я и говорю.
>>по тому что указали выше
Я объяснил. Эльбрус не далёк до вершин — далёк от вершин конпелятор. Тем более под х86 они так же далеки от вершин и всё надо делать руками.
х86 выигрывает из-за того, что просто технологичней и своей архитектурой, которая более приспособлена для исполнения кода такого качества, который производят нынешние программисты, языки, их рантаймы и компиляторы.
Были бы у меня реальные спеки эльбруса — я бы мог сравнить, а так заявлять безосновательно о том, что он говно — я не готов.
>>Деньги уже уплочены. Зачем брать второй раз?
Откуда информация? За что уплочены — за разработку? За реализацию? За что?
Скорее всего оплачена только разработка и тестовые стенды/прочее железо. Далее дали чуть бабок на партию, а дальше крутись как хочешь.
Я не знаю сколько и что там стоит, но если нифа из сети верна и себестоимость самого чипа копейки, то почему они не заказали сразу большую партию — пусть бы продавали за столько же, но и выкатывали энтузиастам.
Возможно так нельзя и им надо отчитываться, возможно они не хотят, либо не знают как. Возможно обвязка стоит денег, но что мешает сделать партию материнок из ширпотреба?
Я так и не понял какие у вас претензии. Их можно ругать за многое, но явно не за то, за что ругаете вы.
Тем более цена у них как у серверных интелов. У обывателя пригорает только из-за сравнения с десктопным железом. Сколько флопсов в даблах выдаёт игровая видяшка? Как х86. Сколько там стоит e5-й хеон? Либо 2011 десктоп? У 2011 трупут рамы в 2раза выше, чем у 1055/6, либо какие там щас. Собственно как и у е5 по сравнению с е3.
>>Эльбрус имеет гораздо более широкое окно
Эльбрус не имеет окна — он не имеет 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 и прочих куллстори.
>>Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?
Этот вопрос не имеет смысла — причины написал выше.
Выйти по какому критерию? По критерию производительности? Этому ничего не мешает.
Сила интела не в том, что он быстрый(хотя хасвел скакнул не слабо), а в том что он может исполнять плохой код с приемлемой производительностью. Естественно здесь с ним тягаться никто не может, да и не будет.
В данном случае вся «обвесочная» сложность была выпилена из процессора. Это дало возможность выпустить «быстрый» процессор без ресурсов интела.
Потенциально его слабость перед интелом можно решить сильным компилятором, при этом на уровне компилятора эта задача решается на порядки проще и оптимальней.
Сейчас же даже без компилятора производительность можно снять руками(прям как на интеле), а компилятор потихоньку пилится. Это решение намного лучше, нежели пытаться повторить достижения интел.
Продукт продаётся за бешеные деньги лишь потому, что стоит он бешеных денег.
Не понимаю почему они так противятся популяризации своего детища среди энтузиастов. Я не думаю что это прям очень дорого — заказать дополнительно, либо сделать версию ширпотребного качества. Хотя зная паникёров и всёпросральщиков в интернетах — я понимаю их мотивацию.
В целом, я не особо верю в то, что они, да и кто-либо вообще может сделать вменяемый компилятор С/С++ для данной архитектуры. Но пусть делаю — я рад за них.
>>результат один и тот же но за разное время.
Не верно. х86 умеет распознавать паттерны для зануления регистров и sub/xor ничем друг от друга не отличается, как и прямое зануление через присваивание.
>>В случае пары инструкций — смотрим в справочник, там написано за сколько тактов оно выполнится, дальше смотрим на мегагерцы.
Что есть «выполняется»? Это когда результат будет получен, когда можно исполнить следующую? Если первое, то где основание для определения суммы этого времени как результирующие время исполнения набора инстуркций опять же в трактовке номер один.
Время можно получить только эмуляцией потока исполнения — никак иначе.
>>В случае сложных задач на х86 можно получать пенальти (простои)
Это не простои а дополнительная латенси для доступа к данным/а в следствии и результатам инструкиций, либо сами результатам.
Опять же это пайплайн и без контекста в котором летенси что-то определяет это ничего не стоит.
>>отсутствием данных в кеше
Отсутствие данных в кеше стоит доступа их из памяти к пенальти не имеет никакого отношения.
>>и некоторые инструкции когда рядом могут параллельно выполнятся
Не верно. Это утверждение не имеет смысла. По определению при out-of-order execution нет такого понятия как «рядом».
Да и вообще нет такого понятия. В х86 есть «каналы»/пайплайны по амд/порты по штеуду исполнения.
Каждый порт объединяет доступ к набору исполнителей( либо там заморочки более сложны — неизвестно). Они абсолютно независимы. Там есть свои заморочки с пенальти между переключениями исполнителей, но опять же — это +летенси к самой операции, а не лок исполнителя.
Исполнятся параллельно инструкции могут как в рамках одного пайплайна, так и в рамках разных «портов». Рядом/не рядом — от этого ничего не зависит.
Пайплайн — это трупут 1оп/такт, когда в мануале написано 0.5 — это значит, что эту операцию может исполнять 2порта.
>>плюс есть ещё предсказание переходов и вообще переходы могут очищать конвеер
Переход просто инвалидирует те инструкции, которые начали исполнятся/исполнились спекулятивно.
Переходы — это алгоритмические заморочки. Если он есть — он будет всегда. Другое дело, что у него может быть разная цена на разных процессорах, только в этом и есть смысл сравнения.
>>Даже результаты бенчей memcpy(), memset() оптимизированных под платформу трудно однозначно интерпретировать.
Просто. Только надо понимать что ты и зачем измеряешь. Что ты и для чего используешь.
Надо просто в голове иметь модель рабочую, с разными уровнями «памяти»(уровни кешей, уровни оперативной памяти, уровни иной памяти), а не пихать всё в одну кучу.
>>Оптимизировать легко когда время выполнения команд предсказуемое
Оно всегда предсказуемое — написано в мануалах, либо измеряется.
>>и один и тот же код может исполнятся в разы и порядки быстрее/медленее на разных процах.
Можно увидеть примеры? Единственные примеры, которые можно сюда притянуть за уши — это сложные инструкции, но они используются редко и ими можно пренебречь.
«Если какая-то задача в принципе не распараллеливается, то при чём тут любой конкретно взятый процессор и компилятор?»
Я уже рассказал как это делается. Её не надо паралеллелить — её надо коневеизировать( я не знаю как пишется это слово и есть ли он вообще).
Мы не может распараллелить одну операцию, но мы может параллельно делать много.
Штука в том, что любая обработка данных — это множество одинаковых, последовательных операций на разными данными.
Берём обычный цикл 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 ничего не мешает людям( в частности мне) писать оптимально на асм, а вот компилятор этого как не мог так и не может.
Спорное заявление. Я не знаю таких прикладных задач — возможно какие-то научные расчёты и строятся.
По поводу оптимизированной библиотеки — я описывал проблемы всех этих библиотек. Тем более эти библиотеки невозможно написать на асм — это всё должно быть машинная генерация. А зачем шедулить каждую операцию заново — проще написать дсл. А если есть дсл — зачем нужны эти языки? Только как скриптовая обёртка вокруг.
По поводу серебряных пуль. Тот же штеуд не может писать в память без nt, а nt собственно это обход кешей. Поэтому версия для работы в кешах не может работать вменяемое для данных больше кешей, а версия для памяти не может работать вменяемо для кешей.
ТС померил трупут л2(хотя и то навряд-ли, ибо 4/4GB/s даже для 600мггц смешно — это по ~два флоата лоад/стор на такт). И тут варианта два — либо библиотека от производителя слаба, либо процессор слаб сам по себе, либо ТС что-то не то померил.
По поводу операций. Функции с операциями — это тупиковый интерфейс. Допустим, нам надо сложить два массива, а потом как-то обработать. Нормализовать, отсеять, либо ещё что-то. Все эти операции для 10^5 упираются в llc, а значит мы просто так гоняем данные по кругу и греем воздух.
Делай мы это операцию не конвейерно, а параллельно — мы бы получили вторую, треть, десятую операцию бесплатно.
Т.е. вменяемый интерфейс это не просто функция — это паттерн доступа/обхода структуры данных + набор операций. Это не реализуемо, ибо опять же требует компилятор. Поэтому, собственно, это никто не использует.
Опять же — какая разница библиотека, либо нет. Реализациях этой самой библиотеки требует автоматических средств, иначе вменяемого качества не добиться. Если они есть — почему они не выкатываются, а если их нет — библиотеки не будет.
«на платформе «Эльбрус» надо пользоваться высокоуровневыми языками C/C++ и Fortran» — странная позиция.
Подавляющие большинство операций в реальном мире не параллелятся, либо параллелятся слабо. Собственно поэтому для задействования этого параллелизма надо параллельно исполнять множество «потоков исполнения», а для того, чтобы их исполнять — они должны быть, но их нет.
Допустим, надо нам вычислить синус( вычислить полином) — его, конечно, расспараллелить можно, только это имеет мало смысла(90% нашего параллелизма будет простаивать из-за постоянных зависимостей по данным).
Решается это просто — надо считать не один отдельный синус, а много. Просто в теории. На практике эта задача сложнее векторизации, а даже векторизацию до сих ни один компилятор делать, кроме примитивных случаев, не умеет.
Да что там распараллеливание — даже банально зашедулить(раскидать инструкции по «каналам исполнения») один поток такая же непосильная для компилятора задача.
Проблема в самих языках и подходах к разработке/сборки.
Динамическая линковка? Нерешаемая проблема — компилятор просто не может получить код того же синуса, не может его заинлайнить. На уровне процессора её решить можно — как решить на уровне компилятора?
Раздельная сборка, статическая линковка? Много ли компилятором имеют вменяемое lto+ipo? Один? Сколько к этому шли? 10лет? До сих пор не работает без подпорок. Когда это будет в эльбрусе?
В конечном итоге эти(да и любые другие) языки просто не могут в параллелизм — да, компилятор может взять эту работу на себя, но много ли умеет гцц/шланг для х86? Сколько от этого будет иметь эльбрус?
В конечном на х86 радуются ipc в районе 2, при потолке ~4/6(фронтенд/бекенд) — толку с теоретических 23(или сколько там?) на эльбрусе?
Почему бы не сделать dsl пусть на основе C, со своей логикой вычислений? Зачем цпу с такой архитектурой? На эти вопросы нет ответа.
Тот же интел с итаником не смог. Повторяем ошибку?
Как продолжить программу дальше? Разрешить рид перед завершением? А как тогда потом поймать другие?
Какое отношение компилятор имеет к архитектуре? Правильно — никакое. Генерировать код можно с ООО на уровне инструкций хоть для ООО-процессоров, хоть и для не-ООО. Вернее для ООО — это и делается, правда руками, ибо на уровне компилятора это в зачаточном виде, да и я объяснял когда это надо и почему это надо.
>>Насчет архитектуры — набор бездоказательных утверждений.
Попытка не имеет смысла — не важно кто и что приписывает к моим утверждениям — они ничего не теряют. Если они не верны — их можно опровергнуть, а если это не можется — надо хотя-бы попытаться доказать утверждение в адрес моих утверждений, ибо в противном случае я могу написать то же самое.
>>Как раз архитектура Эльбруса — гораздо гибче и гармоничней в сравнении с 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ГГц) мерятся с Интелами бесполезно.
Мерятся с интелами бесполезно не из-за ТТ, а из-за тех причин, что описал я.
Слабый компилятор и невозможность написать нормальный в рамках текущей экосистемы и языков.
Опять же — симд проигрывают в исполнении множества разных потоков команд одновременно, но это не реализуемая мечта на уровне компилятора. И опять же реально существующая в интеле в их гипертредах.
Как вы себе представляете слияние двух потоков команд на уровне языка(С/С++)? Как сделать слияние двух потоков разных тредов/процессов на уровне компилятора?
В-третьих в х86 оно существует РЕАЛЬНО, а в эльбрусе ПОТЕНЦИАЛЬНО и именно о сложности реализации этого ПОТЕНЦИАЛЬНО я и говорю.
Я объяснил. Эльбрус не далёк до вершин — далёк от вершин конпелятор. Тем более под х86 они так же далеки от вершин и всё надо делать руками.
х86 выигрывает из-за того, что просто технологичней и своей архитектурой, которая более приспособлена для исполнения кода такого качества, который производят нынешние программисты, языки, их рантаймы и компиляторы.
Были бы у меня реальные спеки эльбруса — я бы мог сравнить, а так заявлять безосновательно о том, что он говно — я не готов.
>>Деньги уже уплочены. Зачем брать второй раз?
Откуда информация? За что уплочены — за разработку? За реализацию? За что?
Скорее всего оплачена только разработка и тестовые стенды/прочее железо. Далее дали чуть бабок на партию, а дальше крутись как хочешь.
Я не знаю сколько и что там стоит, но если нифа из сети верна и себестоимость самого чипа копейки, то почему они не заказали сразу большую партию — пусть бы продавали за столько же, но и выкатывали энтузиастам.
Возможно так нельзя и им надо отчитываться, возможно они не хотят, либо не знают как. Возможно обвязка стоит денег, но что мешает сделать партию материнок из ширпотреба?
Я так и не понял какие у вас претензии. Их можно ругать за многое, но явно не за то, за что ругаете вы.
Тем более цена у них как у серверных интелов. У обывателя пригорает только из-за сравнения с десктопным железом. Сколько флопсов в даблах выдаёт игровая видяшка? Как х86. Сколько там стоит e5-й хеон? Либо 2011 десктоп? У 2011 трупут рамы в 2раза выше, чем у 1055/6, либо какие там щас. Собственно как и у е5 по сравнению с е3.
Эльбрус не имеет окна — он не имеет 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 и прочих куллстори.
>>Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?
Этот вопрос не имеет смысла — причины написал выше.
Сила интела не в том, что он быстрый(хотя хасвел скакнул не слабо), а в том что он может исполнять плохой код с приемлемой производительностью. Естественно здесь с ним тягаться никто не может, да и не будет.
В данном случае вся «обвесочная» сложность была выпилена из процессора. Это дало возможность выпустить «быстрый» процессор без ресурсов интела.
Потенциально его слабость перед интелом можно решить сильным компилятором, при этом на уровне компилятора эта задача решается на порядки проще и оптимальней.
Сейчас же даже без компилятора производительность можно снять руками(прям как на интеле), а компилятор потихоньку пилится. Это решение намного лучше, нежели пытаться повторить достижения интел.
Продукт продаётся за бешеные деньги лишь потому, что стоит он бешеных денег.
Не понимаю почему они так противятся популяризации своего детища среди энтузиастов. Я не думаю что это прям очень дорого — заказать дополнительно, либо сделать версию ширпотребного качества. Хотя зная паникёров и всёпросральщиков в интернетах — я понимаю их мотивацию.
В целом, я не особо верю в то, что они, да и кто-либо вообще может сделать вменяемый компилятор С/С++ для данной архитектуры. Но пусть делаю — я рад за них.
Не верно. х86 умеет распознавать паттерны для зануления регистров и sub/xor ничем друг от друга не отличается, как и прямое зануление через присваивание.
>>В случае пары инструкций — смотрим в справочник, там написано за сколько тактов оно выполнится, дальше смотрим на мегагерцы.
Что есть «выполняется»? Это когда результат будет получен, когда можно исполнить следующую? Если первое, то где основание для определения суммы этого времени как результирующие время исполнения набора инстуркций опять же в трактовке номер один.
Время можно получить только эмуляцией потока исполнения — никак иначе.
>>В случае сложных задач на х86 можно получать пенальти (простои)
Это не простои а дополнительная латенси для доступа к данным/а в следствии и результатам инструкиций, либо сами результатам.
Опять же это пайплайн и без контекста в котором летенси что-то определяет это ничего не стоит.
>>отсутствием данных в кеше
Отсутствие данных в кеше стоит доступа их из памяти к пенальти не имеет никакого отношения.
>>и некоторые инструкции когда рядом могут параллельно выполнятся
Не верно. Это утверждение не имеет смысла. По определению при out-of-order execution нет такого понятия как «рядом».
Да и вообще нет такого понятия. В х86 есть «каналы»/пайплайны по амд/порты по штеуду исполнения.
Каждый порт объединяет доступ к набору исполнителей( либо там заморочки более сложны — неизвестно). Они абсолютно независимы. Там есть свои заморочки с пенальти между переключениями исполнителей, но опять же — это +летенси к самой операции, а не лок исполнителя.
Исполнятся параллельно инструкции могут как в рамках одного пайплайна, так и в рамках разных «портов». Рядом/не рядом — от этого ничего не зависит.
Пайплайн — это трупут 1оп/такт, когда в мануале написано 0.5 — это значит, что эту операцию может исполнять 2порта.
>>плюс есть ещё предсказание переходов и вообще переходы могут очищать конвеер
Переход просто инвалидирует те инструкции, которые начали исполнятся/исполнились спекулятивно.
Переходы — это алгоритмические заморочки. Если он есть — он будет всегда. Другое дело, что у него может быть разная цена на разных процессорах, только в этом и есть смысл сравнения.
>>Даже результаты бенчей memcpy(), memset() оптимизированных под платформу трудно однозначно интерпретировать.
Просто. Только надо понимать что ты и зачем измеряешь. Что ты и для чего используешь.
Надо просто в голове иметь модель рабочую, с разными уровнями «памяти»(уровни кешей, уровни оперативной памяти, уровни иной памяти), а не пихать всё в одну кучу.
>>Оптимизировать легко когда время выполнения команд предсказуемое
Оно всегда предсказуемое — написано в мануалах, либо измеряется.
>>и один и тот же код может исполнятся в разы и порядки быстрее/медленее на разных процах.
Можно увидеть примеры? Единственные примеры, которые можно сюда притянуть за уши — это сложные инструкции, но они используются редко и ими можно пренебречь.
Я уже рассказал как это делается. Её не надо паралеллелить — её надо коневеизировать( я не знаю как пишется это слово и есть ли он вообще).
Мы не может распараллелить одну операцию, но мы может параллельно делать много.
Штука в том, что любая обработка данных — это множество одинаковых, последовательных операций на разными данными.
Берём обычный цикл 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 ничего не мешает людям( в частности мне) писать оптимально на асм, а вот компилятор этого как не мог так и не может.
По поводу оптимизированной библиотеки — я описывал проблемы всех этих библиотек. Тем более эти библиотеки невозможно написать на асм — это всё должно быть машинная генерация. А зачем шедулить каждую операцию заново — проще написать дсл. А если есть дсл — зачем нужны эти языки? Только как скриптовая обёртка вокруг.
По поводу серебряных пуль. Тот же штеуд не может писать в память без nt, а nt собственно это обход кешей. Поэтому версия для работы в кешах не может работать вменяемое для данных больше кешей, а версия для памяти не может работать вменяемо для кешей.
ТС померил трупут л2(хотя и то навряд-ли, ибо 4/4GB/s даже для 600мггц смешно — это по ~два флоата лоад/стор на такт). И тут варианта два — либо библиотека от производителя слаба, либо процессор слаб сам по себе, либо ТС что-то не то померил.
По поводу операций. Функции с операциями — это тупиковый интерфейс. Допустим, нам надо сложить два массива, а потом как-то обработать. Нормализовать, отсеять, либо ещё что-то. Все эти операции для 10^5 упираются в llc, а значит мы просто так гоняем данные по кругу и греем воздух.
Делай мы это операцию не конвейерно, а параллельно — мы бы получили вторую, треть, десятую операцию бесплатно.
Т.е. вменяемый интерфейс это не просто функция — это паттерн доступа/обхода структуры данных + набор операций. Это не реализуемо, ибо опять же требует компилятор. Поэтому, собственно, это никто не использует.
Опять же — какая разница библиотека, либо нет. Реализациях этой самой библиотеки требует автоматических средств, иначе вменяемого качества не добиться. Если они есть — почему они не выкатываются, а если их нет — библиотеки не будет.
Подавляющие большинство операций в реальном мире не параллелятся, либо параллелятся слабо. Собственно поэтому для задействования этого параллелизма надо параллельно исполнять множество «потоков исполнения», а для того, чтобы их исполнять — они должны быть, но их нет.
Допустим, надо нам вычислить синус( вычислить полином) — его, конечно, расспараллелить можно, только это имеет мало смысла(90% нашего параллелизма будет простаивать из-за постоянных зависимостей по данным).
Решается это просто — надо считать не один отдельный синус, а много. Просто в теории. На практике эта задача сложнее векторизации, а даже векторизацию до сих ни один компилятор делать, кроме примитивных случаев, не умеет.
Да что там распараллеливание — даже банально зашедулить(раскидать инструкции по «каналам исполнения») один поток такая же непосильная для компилятора задача.
Проблема в самих языках и подходах к разработке/сборки.
Динамическая линковка? Нерешаемая проблема — компилятор просто не может получить код того же синуса, не может его заинлайнить. На уровне процессора её решить можно — как решить на уровне компилятора?
Раздельная сборка, статическая линковка? Много ли компилятором имеют вменяемое lto+ipo? Один? Сколько к этому шли? 10лет? До сих пор не работает без подпорок. Когда это будет в эльбрусе?
В конечном итоге эти(да и любые другие) языки просто не могут в параллелизм — да, компилятор может взять эту работу на себя, но много ли умеет гцц/шланг для х86? Сколько от этого будет иметь эльбрус?
В конечном на х86 радуются ipc в районе 2, при потолке ~4/6(фронтенд/бекенд) — толку с теоретических 23(или сколько там?) на эльбрусе?
Почему бы не сделать dsl пусть на основе C, со своей логикой вычислений? Зачем цпу с такой архитектурой? На эти вопросы нет ответа.
Тот же интел с итаником не смог. Повторяем ошибку?