Здравствуйте, karbofos42, Вы писали:
K>Ничего с собой не могу сделать, годы идут, а Чемезов (Ростех) у меня ассоциируется со словом прототип: https://www.ntv.ru/novosti/204961/
Если кому-то нужно будет объяснить выражение "испанский стыд", то можно будет использовать это. Много лет уже прошло — это незабываемо.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф> А ведь мне сама идея VLIW нравилась — что-то в этом есть интересное: суперскалярные архитектуры очень сложные
Простота привлекательна, жаль, что не работает.
Ф> Всё-таки лучше переупорядочивать на этапе компиляции — мне кажется, что тут больше возможностей — тут легче загрузить конвеер(Ы).
Лучше, да не выходит. У интела не вышло. У МЦСТ не вышло. Без ручной подстройки алгоритма под конкретную модель камня (ужас нах) все весьма печально получается. Ставка на тупой процессор и умный компилятор не сыграла. Нет у компилятора информации о потоке исполнения и реальной загрузке блоков процессора, хоть что ты делай.
Здравствуйте, Философ, Вы писали:
Ф> K>Ничего с собой не могу сделать, годы идут, а Чемезов (Ростех) у меня ассоциируется со словом прототип: https://www.ntv.ru/novosti/204961/
Ф> Если кому-то нужно будет объяснить выражение "испанский стыд", то можно будет использовать это. Много лет уже прошло — это незабываемо.
Здравствуйте, rudzuk, Вы писали:
R>Уже только один. Сдулся VLIW. МЦСТ позорно делают OoO в новой версии архитектуры E2K.
О, это интересно. Я про новую версию их архитектуры не слышал ничего. Где можно посмотреть детали про отказ от VLIW?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Простите, я не понимаю. "Параллелизм" — это ни о чём. Параллелизм зависимых задач — велком в современные многоядерники.
В них нет аппаратных примитивов распараллеливания и синхронизации логических потоков.
Примитивы синхронизации в современных многоядерниках реализованы программной логикой поверх CAS.
Сверху этого дорогое переключение контекстов исполнения в защищённом режиме — прощай выхлоп от многоядерности. ))
S>Параллелизм независимых задач (я так понимаю, именно его вы и имеете в виду) — велком в современные векторные процессоры.
Развитием этой идеи как раз стали видеоускорители.
Это опять "не то".
S>Что-то среднее — всего два известных подхода: переупорядочивание инструкций (интел/амд) и VLIW (МЦСТ-шный Эльбрус).
Давно известны концепции требуемой вычислительной модели — это как в современных языках Go или Erlang.
Когда-то экспериментировали с похожими концепциями в железе и соотв. языках, но однажды рванувшая по мегагерцам Интел убила вообще всю индустрию.
Сейчас приходится всё переизобретать заново, причём делают это инженеры, получившие крен в мозгу в процессе своего образования.
Из-за безальтернативных мейнстримовых суперскаляров, конечно. ))
S>Не очень понятно, что такого могли придумать Бабаяны за пределами этих известных подходов.
Разве сейчас системотехников не учат видам параллелизма? ))
Ты ж получал вторую корочку по этой специальности, вроде...
В современной парадигме, кстате, параллелизм на уровне задач должен сливаться с распределёнными вычислениями, учитывая принципиальную реализуемость независимых по задачам гипотетических много-тысяче-ядерников только через гетерогенную архитектуру памяти. Эти системы когда-то вполне успешно проектировались и строились, потом долго нет, сейчас опять пытаются копать в эту сторону.
Здравствуйте, Sinclair, Вы писали:
K>>напихать в 200 раз больше исполняющих блоков чем кто-то, кого они считают образцом. S>Хорошая идея. Вопрос: откуда возьмётся в 200 раз больше места на кристалле? Интел, значит, со своими 11нм, еле как впихивает свои несколько десятков FMA-блоков, а мы со своими 90 впихнём столько же?
Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет.
У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код)
S>Или там 192-ядерный RISC-V: чтобы впихнуть хотя бы в 30 раз больше, нужно как-то сделать площадь блоков в 30 раз меньше.
Основная проблема многоядерников — это когерентность памяти.
Сейчас обеспечение этой когерентности безальтернативное и довольно-таки тупое — по линейкам кеша, но зачастую оно не требуется вовсе, а ср-в управления когерентностью нет.
Т.е. лишние тормоза зачастую, возня с физическим разнесением конкурентно обрабатываемых независимых данных по линейкам этого кеша и прочие постыдные для 21-го века танцы с бубном, которые исполняет программист, а не компилятор + железо.
S>Хоть одним глазком — на что там Бабаяну выделили деньги.
Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм".
Просто Бабаян был когда-то впечатлён Burroughs:
Сам подход к проектированию B5000 считался довольно новаторским для своего времени: обычно инженеры сначала разрабатывали аппаратную архитектуру ЭВМ, а потом предоставляли соответствующую документацию разработчикам ПО, чтобы они написали под эту архитектуру софт. В Burroughs поступили в точности наоборот: сначала подготовили требования к программному обеспечению и языкам программирования, а уже затем начали создавать под них «железо».
Рискну предположить, что увидим нечто подобное. ))
Здравствуйте, Sinclair, Вы писали:
R>>Уже только один. Сдулся VLIW. МЦСТ позорно делают OoO в новой версии архитектуры E2K. S>О, это интересно.
Враки ))
Архитектура и инструкции те же, спекулятивное исполнение такое же, просто более глубокое.
Эффект обещает еще больше превзойти опостылевшее ОоО, которое нон-стоп решает задачу железнодорожных вагонов, вместо целевой прикладной (бгг), но не факт. ))
Здравствуйте, Sinclair, Вы писали:
S>О, это интересно. Я про новую версию их архитектуры не слышал ничего. Где можно посмотреть детали про отказ от VLIW?
Не отказались они от VLIW, просто добавляют типа не VLIW фичи (тот же OoO):
В Эльбрусе функцию «аутофордера» берёт на себя компилятор, заранее распределяя команды по АЛУ в оптимальном порядке следования. Минусом данного подхода является невозможность управлять очерёдностью команд в динамике, уже во время выполнения команды. Однако благодаря этому повышается безопасность вычислений.
...
Как я уже упоминал выше, МЦСТ ведёт работы уже по восьмой арихитектуре Эльбрусов (та, что будет после т.н. Эльбрус-32С). Если до этого микропроцессоры Эльбрус затачивались на суперкомпьютеры, то в восьмой версии внимание будет обращено в сторону потребностей обычного бизнеса.
Например, ведутся исследования того, какую новую технологию можно предложить вместо классического аппаратного «аутофордера», отсутствующего в Эльбрусе.
...
Когда Intel из x86 делает сборную солянку и непонятно CISC это или RISC или что вообще такое, то всё нормально.
Когда МЦСТ в Эльбрусах отходит от "чистого" VLIW, то всё, сдулся.
Ф>Я в этом тексте не вижу ничего, чтобы могло дать какой-либо буст производительности. Приведённый кусок текста похож на маркетинговый булшит — вот ту хрень, которую пишут рисуют маркетологи в презентациях ради выбивания бюджета и выковыривания денег из инвесторов.
в связи с чем экскурс в типы паралеллизма предлагаю считать тупиковой ветвью разговора
пока они не добавят какой-то инфы пока-что это выглядит как очередной подход к снаряду к которму уже толпа народа до них подходила, и результат ожидается примерно тот же
Здравствуйте, Sinclair, Вы писали:
S> R>Уже только один. Сдулся VLIW. МЦСТ позорно делают OoO в новой версии архитектуры E2K.
S> О, это интересно. Я про новую версию их архитектуры не слышал ничего. Где можно посмотреть детали про отказ от VLIW?
От VLIW они не отказываются, просто проходят стадию принятия фишек, которые ранее гневно отвергали Некоторые детали есть в интервью Трушкина, которое он дал на канале Горшенина.
Здравствуйте, vdimas, Вы писали:
V>Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет. V>У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код)
Гипертрединг не добавляет мощности. Это скорее наоборот — возможность загрузить свободные FMA-блоки, если не получается распараллелить на них инструкции в конвеере.
Чтобы объехать Интел, нужно а) добавить FMA-блоков и б) обеспечить, чтобы они не простаивали в ожидании памяти. V>Основная проблема многоядерников — это когерентность памяти.
Смотря на каких задачах.
V>Т.е. лишние тормоза зачастую, возня с физическим разнесением конкурентно обрабатываемых независимых данных по линейкам этого кеша и прочие постыдные для 21-го века танцы с бубном, которые исполняет программист, а не компилятор + железо.
И каким чудом можно эти танцы с бубном переложить на компилятор+железо? И даст ли это переложение хотя бы 30-кратный рост производительности, не говоря уже о 200?
V>Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм".
Я об этом уже написал.
V>Рискну предположить, что увидим нечто подобное. ))
Рискну предположить, что мы вообще ничего не увидим. Но надежда, как водится, умирает последней.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, karbofos42, Вы писали:
K>Не отказались они от VLIW, просто добавляют типа не VLIW фичи (тот же OoO):
Спасибо, я вас неправильно понял. K>
K>В Эльбрусе функцию «аутофордера» берёт на себя компилятор, заранее распределяя команды по АЛУ в оптимальном порядке следования. Минусом данного подхода является невозможность управлять очерёдностью команд в динамике, уже во время выполнения команды. Однако благодаря этому повышается безопасность вычислений.
K>...
K>Как я уже упоминал выше, МЦСТ ведёт работы уже по восьмой арихитектуре Эльбрусов (та, что будет после т.н. Эльбрус-32С). Если до этого микропроцессоры Эльбрус затачивались на суперкомпьютеры, то в восьмой версии внимание будет обращено в сторону потребностей обычного бизнеса.
K>Например, ведутся исследования того, какую новую технологию можно предложить вместо классического аппаратного «аутофордера», отсутствующего в Эльбрусе.
K>...
Ну, вот это как раз интересно. Особенно интересно, как смешивать VLIW с его "статическим" OoO и какие-то динамические OoO-фичи.
K>Когда Intel из x86 делает сборную солянку и непонятно CISC это или RISC или что вообще такое, то всё нормально.
Ну, так "нормально" — это 20+ лет опыта успешной эксплуатации. В том числе и разработки компиляторов, и прикладных алгоритмов и библиотек, которые на этой "сборной солянке" показывают вполне себе впечатляющий перформанс.
У Эльбруса, судя по их же статьям с рассказами об успехах, разработчику нужно держать в голове полную модель процессора и считать на пальцах такты, а потом скрещивать пальцы в надежде, что компилятор его правильно поймёт и догадается, какие инструкции сгенерировать для тела плотного цикла.
K>Когда МЦСТ в Эльбрусах отходит от "чистого" VLIW, то всё, сдулся.
Ну, тут имело место недопонимание. Лично я бы не считал, что они прямо "сдулись", даже если бы они полностью отказались от VLIW. Если они хотят его развивать — прекрасно, особенно если новые фичи удастся удачно обыграть в прикладном коде.
Интересно всё же, кто победит — V8 или Б. Если вообще кто-то из них доедет до запуска.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну, так "нормально" — это 20+ лет опыта успешной эксплуатации.
Ну, вот в Apple сказали, что отстой этот x86, запилили свой ARM и плевать им на опыт эксплуатации.
Мой посыл был в том, что Intel кучу раз упиралась в проблемы и ограничения, в итоге современные процессоры уже непонятно что из себя представляют.
Что-то я не слышал, что слился CISC (как rudzuk про VLIW написал) или Intel.
S>В том числе и разработки компиляторов, и прикладных алгоритмов и библиотек, которые на этой "сборной солянке" показывают вполне себе впечатляющий перформанс.
Ну, так десятилетия софт писался под x86, странно ожидать, что при перекомпиляции его с минимальными изменениями под Эльбрус будет всё работать с отличным перформансом.
S>У Эльбруса, судя по их же статьям с рассказами об успехах, разработчику нужно держать в голове полную модель процессора и считать на пальцах такты, а потом скрещивать пальцы в надежде, что компилятор его правильно поймёт и догадается, какие инструкции сгенерировать для тела плотного цикла.
Не встречал таких статей. Обычно наоборот там вроде: оптимизация в целом примерно как под x86, с некоторыми своими особенностями. То просто Java-программу запускают с другими ключами VM и выполнение ускоряется в разы.
Сколько человеко-часов потрачено на компиляторы под x86? Странно ожидать, что полтора землекопа из МЦСТ за несколько лет напишут сопоставимый оптимизатор.
Итого пока имеем: существующий код написан под x86, а не Эльбрусы, а под Эльбрусы ещё и "молодой" компилятор, который ещё допиливать и допиливать.
Лет 15 назад и под x86 вполне себе мне встречались ассемблерные вставки, т.к. оптимизатор не вывозил.
Сейчас уже оптимизаторы нормально развились, что давно такого не встречал, в основном ограничиваются допиливанием кода на языке высокого уровня, без погружения.
Не понимаю что должно помешать со временем добиться аналогичных успехов в компиляторах под Эльбрусы.
Собственно периодически и проскакивало, что вот мы свой существующий код собрали новой версией компилятора и он стал работать быстрее на N % без каких-либо изменений и на том же железе (просто допиленный оптимизатор лучше отработал).
S>Интересно всё же, кто победит — V8 или Б. Если вообще кто-то из них доедет до запуска.
Как-то не верится ни в то, ни в то. При существовании Эльбрусов не кинулись налаживать их производство и уже хоть что-то своё иметь (хотя бы уж модели на 90нм или подобное).
Вместо этого то выискивают деньги на RISC-V, то теперь Эльбрус-Б. В итоге уже существующее сливается, а нового пока ничего не видели (планшет на RISC-V уже в этом году обещали вроде).
Надеюсь, что у причастных людей есть план, они его придерживаются и просто не распространяются.
Здравствуйте, karbofos42, Вы писали:
k> Мой посыл был в том, что Intel кучу раз упиралась в проблемы и ограничения, в итоге современные процессоры уже непонятно что из себя представляют. k> Что-то я не слышал, что слился CISC (как rudzuk про VLIW написал) или Intel.
Если бы интели били себя пяткой в грудь, говоря, что духу вашего поганого риська не будет в наших православных циськах, я бы и про них такое написал Это же, млять, смешно, когда вам сперва рассказывают какой #уевый этот ваш аутофордер, а потом оба-на!
Здравствуйте, rudzuk, Вы писали:
R>Если бы интели били себя пяткой в грудь, говоря, что духу вашего поганого риська не будет в наших православных циськах, я бы и про них такое написал Это же, млять, смешно, когда вам сперва рассказывают какой #уевый этот ваш аутофордер, а потом оба-на!
Что оба-на?
Единственное, что я нашёл, чуть выше тут цитировал: "Например, ведутся исследования того, какую новую технологию можно предложить вместо классического аппаратного «аутофордера», отсутствующего в Эльбрусе.".
Есть информация что в итоге они по out-of-order придумали? Реализовали как-то в железе или просто оптимизатор в компиляторе подкрутили или вообще решили, что нафиг надо?
Здравствуйте, Философ, Вы писали:
Ф>А ведь мне сама идея VLIW нравилась — что-то в этом есть интересное: суперскалярные архитектуры очень сложные — даже просто понять как работает переупорядочивание сложно, а переименование регистров умножает эту сложность кратно.
У меня возникла идея "как оживить VLIW" из серии "станьте ежиками и я занимаюсь только стратегией, не беспокойте меня деталями" — почему бы вместо АОТ, который очевидно в тупике, не скрестить VLIW с каким-нибудь передовыми JIT технологиями типа Profile Guided Optimization.
Здравствуйте, Sinclair, Вы писали:
V>>Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет. V>>У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код) S>Гипертрединг не добавляет мощности.
Ес-но, он добавляет выхлоп от имеющейся мощности, и небольшое увеличение кол-ва вентилей лишь показывает печальную реальность — кол-во выч.блоков рассчитывается "на крайний случай", т.е. большинство их простаивает грубо 90% времени, отсюда появляется смысл в аппаратной многопоточности.
И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.
S>Чтобы объехать Интел, нужно а) добавить FMA-блоков и б) обеспечить, чтобы они не простаивали в ожидании памяти.
Ес-но.
Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
V>>Основная проблема многоядерников — это когерентность памяти. S>Смотря на каких задачах.
На обычных многопоточных, даже независимых по данным.
Эту независимость приходится организовывать физически разметкой лейаута.
Вот у тебя есть некий объект, в нём работает пара потоков, их локальные данные необходимо разносить по линейкам кеша.
В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.
И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))
V>>Т.е. лишние тормоза зачастую, возня с физическим разнесением конкурентно обрабатываемых независимых данных по линейкам этого кеша и прочие постыдные для 21-го века танцы с бубном, которые исполняет программист, а не компилятор + железо. S>И каким чудом можно эти танцы с бубном переложить на компилятор+железо?
Размечать блоки данных, которые локальные для некоего потока, т.е. чтобы была возможность разметить несколько таких блоков в лейауте объекта.
Дальнейшая автоматизация в компиляторе, потом на реальном железе на уровне загрузчика ОС со стандартной коррекцией адресов в процессе загрузки.
Да, языки необходимо допиливать, но это надо было начинать делать еще в нулевые, когда многоядерность пошла в мейнстрим десктопа.
S>И даст ли это переложение хотя бы 30-кратный рост производительности, не говоря уже о 200?
Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
А так же от везения — исполняются ли целевые конкурирующие за память потоки в одном ядре с гипертредингом, или в разных.
И эта эффективность в случае разных ядер достигается за счёт разгрузки механизма обеспечения когерентности памяти, а у того тоже предельный трафик не бесконечный.
Т.е., тут двойной выхлоп: (1) убираются задержки, связанные с обеспечением когерентности памяти и (2) подсистема обеспечения когерентности освобождается для других конкурентных задач/процессов, давая тем больше эффективности.
V>>Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм". S>Я об этом уже написал.
Ты написал лишь два базовых вида, хотя существовали системы с железным параллелизмом на уровне задач — это более высокоуровневые механизмы, реализованные в железе.
Это когда железо автоматически обслуживает начало и окончание вычислительных потоков через железные же примитивы синхронизации, т.е. создание и завершение потока вычисления практически ничего не стоит. В таких системах распараллеливание циклов начинает давать профит при намного меньших оборотах цикла, чем в современных многопоточных ОС (и даже в сравнении с мануально наваянными зелеными потоками).
Разумеется, подходы к параллелизму будут еще допиливаться, коль с ростом частоты уже давно понятно, что обломались, т.е. теперь будет рост только вширь, а значит нужна поддержка для извлечения хорошего КПД от большого кол-ва выч.блоков. Такие темы примерно раз в 5 лет тут возникают, давно понятно что делать, но "проклятое легаси" пугает, конечно... ))
V>>Рискну предположить, что увидим нечто подобное. )) S>Рискну предположить, что мы вообще ничего не увидим. Но надежда, как водится, умирает последней.
Да нет, они в макетах всё неплохо демонстрировали.
Умудрились же в самую эпоху развала создать нехилую архитектуру E2k, которая была натурально революционной по меркам второй половины 90-х...
А что не сумели воплотить в актуальном техпроцессе — это не к разработчикам проца вопросы, а к технологиям страны в целом, конечно, и к банальным вложениям денег.
Но именно разрабатывать нестандартные, но востребованные и офигенно крутые на момент разработки архитектуры они умеют и уже показали это ранее.
E2k — это переосмысление архитектуры мощного сигнального процессора, способного на равных тягаться с топами даже в "обычных задачах".
А по числодроблению (как проц позиционировался) он на тот момент уделывал топовые Интелы почти на порядок на сравнимых частотах.
Будь тогда возможность воплотить в железе на актуальном техпроцессе в начале нулевых — все бы офигели, конечно... ))
Здравствуйте, vdimas, Вы писали:
V>Ес-но, он добавляет выхлоп от имеющейся мощности, и небольшое увеличение кол-ва вентилей лишь показывает печальную реальность — кол-во выч.блоков рассчитывается "на крайний случай".
Если рассматривать именно P4, то там гиперпоточность часто даже вредила, а не помогала. А там где профит был, он был слишком мал, чтобы считать что она помгает — цифры в районе 15% отнюдь не впечатляли. Не знаю, с чем это было связано, однако изначальная идея применительно именно к P4 выглядела провальной.
А ведь идея была красивой: если один поток загружает целочисленные блоки, то второй вполне мог использовать (загрузить работой) блоки для плавающей точки. И нет, это никак не подтверждает, что кол-во выч.блоков было слишком большим, или что большинство из них простаивали.
Есть теория, что P4 не оправдал ожиданий из-за слишком длинноего конвейера — слишком дорого было его заново загружать после условных и безусловных переходов.
V>... т.е. большинство их простаивает грубо 90% времени, отсюда появляется смысл в аппаратной многопоточности.
Выше я показал, что простаивание вычислительных блоков 90% времени — сомнительная гипотеза.
V>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
О! А откуда известно, что Эльбрус полагается на спекулятивное исполнение, и что оно там вообще есть? Я серьёзно — почти ничего не знаю об Эльбрусах.
Эх, глянуть бы мануал к нему....
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
V>>... т.е. большинство их простаивает грубо 90% времени, отсюда появляется смысл в аппаратной многопоточности. Ф>Выше я показал, что простаивание вычислительных блоков 90% времени — сомнительная гипотеза.
Это смотря сколько блоков простаивает на обычных вычислениях, т.е. какое поколение SSE. ))
И да, архитектуру P4 давно похоронили и вернулись в нулевые к архитектуре PIII с гипертредингом и новым техпроцессом, вот там выхлоп был поинтересней.
V>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются. Ф>О! А откуда известно, что Эльбрус полагается на спекулятивное исполнение, и что оно там вообще есть? Я серьёзно — почти ничего не знаю об Эльбрусах. Ф>Эх, глянуть бы мануал к нему....
Да, в руководстве по программированию проца всё оч детально расписано.
Некоторые детали есть в интервью Трушкина, которое он дал на канале Горшенина.
