LINUX.ORG.RU

Понимание широкой команды, VLIW

 ,


4

2

Лорчик, у меня тут вопрос возник, чисто теоретический.

Есть VLIW, архитектура e2k. Если посмотреть ассемблерный код, то команда там будет в фигурных скобках. Это и есть одна широкая команда.

Пример:

{
  nop 2
  istofd,3    %g17, %g18
}
{
  nop 7
  sdivs,5     %g17, %g16, %g16
}

В документации сказано, что одна такая широкая команда выполняется процессором за 1 такт. Справедливости ради, нужно заметить, что здесь ни слова про ядра. Просто сказано, что за один такт.

Дальше отсебятина, точнее «отменятина». Как бы суть-то широкой команды именно в том, чтобы распределить мелкие команды внутри этой широкой между ядрами процессора. Т.е. смысл фразы «за один такт» - это просто распараллеливание по ядрам.

Поскольку e2k не содержит жуткого блока предсказаний, как на обычном х86_64 и не умеет распаралеливать команды сам. За него это делает компилятор. Вот для этого и нужна эта широкая команда - компилятор распаралелил, перетасовал команды и сказал как их надо выполнить.

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

Допустим прога собрана для Эльбрус 8С, у которого 8 ядер. Значит в фигурных скобках будет много команд. Т.е. широкая команда будет ну очень широкой, широчайшей прям! А запустится ли этот получившийся бинарник, скажем на 4С, у которого только 4 ядра? А на 1С? В смысле без пересборки.

★★★★★

Ответ на: комментарий от no-such-file

Если тупо взять и перекомпилять условный «ffmpeg» обмазанный SIMD интрисниками, то результат будет такой себе.

Зато можно в рекламной брошюре поставить галочку, что ffmpeg работает. Как там с джавой обстоят дела? Запускается, но люто бешено тормозит?

anonymous
()
Ответ на: комментарий от no-such-file

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

cobold ★★★★★
()
Ответ на: комментарий от greenman

Нативного - это в смысле во vliw-командах?
Вроде Линус, когда там ещё работал, говорил про отсутствие смысла для юзеров лезть напрямую на этот уровень.

Там же прикол, что оно кроме трансляции, ещё и оптимизации в рантайме делает.

devl547 ★★★★★
()
Ответ на: комментарий от greenman

А нативного онтопика под трансмету не было?

Писать натив для Crusoe не имело смысла, т.к. для исполнения доступно 64 Мбайт (если я правильно помню) с начальных адресов. JIT компилировал x86 в натив и помещал код в этот регион.

numas13
()

5 звезд

Мда.
Ни один существующий процессор, ни интел, ни арм, ни е2к тем более не распараллеливает код на разные ядра, тем более инструкции. Многопоточный код пишут в ручную, делается автоматическиео определение колличества ядер и разбрасываются по ним задачи, самое очевидное это обработку нескольких файлов распределить.
Из менее очевидного итерации цыкла на все ядра развернуть таким занимается OpenMP.

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

uin ★★★
()
Ответ на: комментарий от uin

Да-да, я перепутал ядра процессора и наборы АЛУ в этих ядрах. Даже и не знаю как так получилось, вероятно я думал сначала об одном, потом о другом и все смешалось воедино. Посыпаю голову пеплом. Рад, что мы разобрались наконец-то.

hibou ★★★★★
() автор топика
Ответ на: комментарий от uin

не распараллеливает код на разные ядра

А как же Мультиклет?

i-rinat ★★★★★
()
Ответ на: комментарий от hibou

Ну с алу - нет, если добавятся новые алу или новые устройства в алу то старый код будет работать (совместимость то сохраняется). А вот если строго под новый процессор скомпилировать то на старых он не заработает. Но это нормально это и в интеловских процессорах примерно так.
Вливо-специфичная проблема это при изменений стадий конвеера, задержек весь старый код идет по звезде особенно где расставлены задержки, и может даже на нем менее эффективно работать чем на старых процессорах. Но это тоже проблема из разряда «учитесь правильно готовить под влив» Если программе или библиотеке максимально выжимать скорость не требуется то и не надо ее компилировать под конкретный процессор, в компиляторе есть патерны generic и версий системы команд, они абстрагированы от конкретной модели процессора с ее задержками. В остальном же как у интела этот код для AVX этот для SSЕ

i-rinatПро мультиклет как то не знаю ничего, он что то типа IBM Cell?

uin ★★★
()
Ответ на: комментарий от anonymous

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

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

наврядли, ведь влив они не закопали

anonymous
()
Ответ на: комментарий от max_lapshin

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

Нет, остальной буст доступен. А вот корутины не завезли.

anonymous
()
Ответ на: комментарий от devl547

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

anonymous
()
Ответ на: комментарий от anonymous

SM - это не те ребята, которые хотели одно виртуальное ядро параллелить на несколько аппаратных?
А у них хоть что-то взлетело?

devl547 ★★★★★
()
Ответ на: комментарий от devl547

SM - это не те ребята, которые хотели одно виртуальное ядро параллелить на несколько аппаратных? В том числе. А у них хоть что-то взлетело? Зависит от точки зрения. Прототипы доделывали и после поглощения, а о большем не могу рассказывать из-за NDA.

steeels
()
Ответ на: комментарий от no-such-file

Ещё для jit тоже вкусные возможности открываются в теории


Да но не с байткодом. Надо перейти к модели скрипт -> AST представление -> слабооптимизированный холодный код <-> агрессивнооптимизированный горячий код, как в v8 короче.

uin ★★★
()
Ответ на: комментарий от alexanius

Тем не менее все изменения проделываются так чтобы сохранялась прямая бинарная совместимость. Например, коды, собранные для Эльбрус-4С будут работать и на Эльбрус-8С и на Эльбрус-8СВ.

Когда более новый проц жрёт коды для более старого, это называется «обратная совместимость», а не «прямая».

anonymous
()
Ответ на: комментарий от no-such-file

Не будет. Конвеер не резиновый. Компилятор же видит весь код

Говорю же, буфер на несколько сотен операций.

Да, компилятор видит весь код и оптимизирует лучше, но это касается глобальной оптимизации, типа выкидывания вычислений, результат которых не нужен, типа подстановки тела функции вместо вызова, векторизации циклов в sse. Но когда дело касается раскидывания инструкций по вычислительным блокам тут компилятор в пролете. Мало того что в случае промаха мимо кэша порядок инструкций собьётся, подобная оптимизация может серьезно навредить.

Приведу пример, пусть в исходнике есть последовательно 3 простых куска, каждый из которых реализуется с использованием группы машинных инструкций и 3х целочисленных регистров. Предположим, эти куски не совпадают, поэтому упаковать всё в SSE/AVX нельзя. Тупой компилятор выдаст последовательно 3 группы в каждой из которых использует регистры a, b и c. Декодер OOO процессора встретив первое присваивание регистру a выделит под него физический регистр r0, аналогично для других, встретив следующее присваивание выделит архитектурному регистру a физический r3, а в третьей группе инструкций этому же назначат r6, после чего все эти команды смогут отправиться на исполнение в любом порядке. Неиспользованные в этом коде архитектурные регистры могут хранить значения переменных, экономя обращения к памяти. Если же компилятор слишком умный и хочет сам перемешать инструкции, то ему придется использовать в этих группах разные архитектурные регистры. В x86, например, всего 6 регистров общего назначения, в x64 их целых 14, но для работы с последними 8ю нужен однобайтовый префикс, который удлиняет команду и нагружает декодер.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Интел все эти свои 8 регистров отображает на более чем 100+ внутренних физических. То есть по простому говоря x86 наименование регистров давно уже тупо виртуальные, которые переотображаются на физические.

Вот только не все OoO суперскаляры пропускают входной код через фронтенд как интел. То есть это мало того что проблема любого ппроцессора любой архитектуры с большим количеством регистров (именно большое количество регистров создает эту проблему о том как их все использовать, а не твои какие то фантазии про неумеющие компиляторы vs могучие суперскаляры), так еще и давно решенная двумя способами: 1) фронтенд как у интела 2) регистровое окно (спарк, итаниум, эльбрус).
Одна процедура создает окно в одном месте регистрового файла, другая в другом, третья в третьем во всех трех регистры именуются от 0-XX в соответствии с размером окна, окные могут перехлестываться и передавать таким образом в другую аргумент, компилятор это спокойно рассчитывает, физическое расположение и доступность места в файле ему побоку, этим железо занимается - хоть у влив, хоть интела с фронтендами и ооо, хоть у риск без таковых.

К слову в RISС-V тупо сделали мало регистров, нет регистров нет проблем с их использованием.

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

К слову в RISС-V тупо сделали мало регистров, нет регистров нет проблем с их использованием.

Мало регистров в сравнении с чем?
У х86 архиттектурных регистров в 2 раза меньше, у aarch64 архитектурных регистров столько же, у эльбруса архитектурных регистров гораздо больше. Микроархитектурные фичи вроде RAT/RS с уровня архитектуры не видны: не стоит путать архитектуру и микроархитектуру.
Насколько я помню, регистровое окно есть в спарках и эльбрусах, но это не то, чтобы популярная штука.

anonymous
()
Ответ на: комментарий от uin

Вот только не все OoO суперскаляры пропускают входной код через фронтенд как интел

Все. Даже сраный cyrix 6x86 (96 год выпуска) умел в переименование регистров. Собственно без него OOO бессмысленно. И в армах оно тоже есть.

Что до окон и прочей лабуды, да, было много попыток решить эту проблему силами программиста/компилятора, но все они убились о факт непредсказуемости. Осталось два подхода, либо OOO, либо какой-то дико ядрёный smt, чтоб поток ожидающий данных не останавливал ядро. Но я не слышал о каких-то особых успехах Ниагары, походу этот вариант так же себя не окупает

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Осталось два подхода, либо OOO, либо какой-то дико ядрёный smt, чтоб поток ожидающий данных не останавливал ядро

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

Блокировка конвеера на ожиданиях из памяти это проблема всех in-order процессоров с конвеером, поэтому и придумали ооо - хрень которая тупо берет и зависимые спихивает в свой там какой то буфер, потом достает. Он не решает проблему он ее сглаживает, и есть сомнения что подобные костыли в будущем вообще нужны, ядер становится больше, на их фоне уже не очень различимо стоит там одно ядро или нет, кэши ширятся, скорость связи растет, предлагают уже на сам кристал память сверху припаивать (вот тебе четвертый уровень кэша 2-4 гигабайта). А так можно даже к эльбрусу прикрутить ооо-подобное решение без изменения системы команд, у него там несколько параллельных конвееров, можно в случае возникновения какой то такой ситуации через прерывания или события переключаться туда и там какой то код исполнять вне очереди, но вопрос стоит ли вообще оно того.

uin ★★★
()
Ответ на: комментарий от anonymous

Микроархитектурные фичи вроде RAT/RS с уровня архитектуры не видны: не стоит путать архитектуру и микроархитектуру.

Ну охренеть теперь, у эльбруса тогда «архитектурных регистров» столько, сколько при входе в процедуру укажешь, столько и будет. У спарк помоему фиксированного размера окно на 32 регистра.

это не то, чтобы популярная штука.

Так архитектур новых и не делают особо больше, вот итаниум сделали в 2000м и там помоему были.

uin ★★★
()
Ответ на: комментарий от uin

А так можно даже к эльбрусу прикрутить ооо-подобное решение без изменения системы команд

Тогда это уже будет не vliw и машина потеряет всякую энергоэффективность, тк CAM структуры потребляют очень много энергии.

anonymous
()
Ответ на: комментарий от uin

Ну охренеть теперь, у эльбруса тогда «архитектурных регистров» столько, сколько при входе в процедуру укажешь

И как это отменяет различие между архитектурными(видимыми в ISA) регистрами и реальными физическими регистрами, на которые могут быть переименованы архитектурные?

anonymous
()
Ответ на: комментарий от uin

тогда «архитектурных регистров» столько, сколько при входе в процедуру укажешь, столько и будет.

Десять тысяч можно? А миллион? Миллиард?

anonymous
()
Ответ на: комментарий от anonymous

это уже будет не vliw

А что по твоему, суперскаляр будет? Энергоэффективность это не цель, а побочный эффект от того что процессор избавили от необходимости переставлять и перепланировать команды каждый раз при исполнении одного и того же кода. То есть эффективность эту можно разглядеть только во временном векторе (то есть он банально чутьменьше тока потребляет на исполнении тех же задачь а сумарно потом видна экономия).
И дополнительные конвееры они увеличивают энергозатраты одномоментно, но эффективность в длинном отрезке от этого не страдает если код подготовленный туда в любом случае будет исполнен. Только при условных переходах или вызовах может получиться так что зря код загрузили и нажгли энергии причем так же при каждом исполнении.

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

И как это отменяет различие между архитектурными(видимыми в ISA) регистрами и реальными физическими регистрами, на которые могут быть переименованы архитектурные?

Так сама суть этих различий в том что когда в «микроархитектуре» много регистров (что бы как можно реже к загрузкам/записи прибегать в контексте одной процедуры), они неизбежны так как оперировать всеми сотнями регистров уже проблематично.
В risc-v эту проблему решили оставить разработчикам железа и в оригинальной архитектуре регистры как есть отображаются на физические.

Меня ыообще коробит слово «архитектура» по отношению к процессорному фронтенду (я знаю что это интел форсит). Архитектура это что-то конкретное, ярко выраженное в деталях, а фронтенд это интерфейс (или система) программирования не более.

Десять тысяч можно? А миллион? Миллиард?

«Сколько укажешь, столько и будет» - это всмысле указал восемь - будет r0-7, указал 32 - будет r0-31, никто не сказал про «бесконечно» или «сколько захочешь». Научись читать и понимать написанное.

uin ★★★
()
Ответ на: комментарий от uin

Меня ыообще коробит слово «архитектура» по отношению к процессорному фронтенду (я знаю что это интел форсит). Архитектура это что-то конкретное, ярко выраженное в деталях, а фронтенд это интерфейс (или система) программирования не более.

Бросается в глаза, что учебного курса по computer architecture или опыта работы в разработке CPU у тебя нет. Одна из первых вещей, которую объясняют - различие между архитектурой(Instruction Set Architecture) и микроархитектурой(деталями реализации). ISA это контракт(API?) между разработчиком софта и железа, если утрировать.

А что по твоему, суперскаляр будет?

Я бы предложил не мешать в кучу суперскалярность, ООО и остальное. Более того, ООО это очень широкое понятие, тк у тебя разные куски процессора могут работать в разных режимах: фронтент - in-order, экзек - OOO, коммит - in-order(привет, ROB).

То есть эффективность эту можно разглядеть только во временном векторе (то есть он банально чутьменьше тока потребляет на исполнении тех же задачь а сумарно потом видна экономия).

Я бы тут предложил посмотреть лекцию от Onur Mutlu про параллелизм, про закон Амдала и про (энерго)эффективность всего этого на абстрактных примерах. Там есть весьма неочивидные примеры.

VLIW строится на предположении, что планирование инструкций можно сделать статически, поэтому от {энерго,место}затратных структур можно отказаться, а на их место воткнуть больше вычислителей. И чтобы это эффективно работало, компилятор должен извлечь достаточно паралеллизма из программы.
Дальше в дело должны вступать аналитики, которые скажут, что параллелизма на 20-wide машину найти, мягко говоря, сложновато, поэтому, например, можно забивать исполнительные устройства спекулятивным выполнением обоих веток условного перехода и откидывать ненужную при вычислении нужного условия. Про это все тоже рассказывают в курсе лекций по computer architecture.

фронтенд это интерфейс (или система) программирования не более.

Фронтенд у процессора это то, что достает из памяти инструкции и декодирует их во внутреннее представление.

В risc-v эту проблему решили оставить разработчикам железа и в оригинальной архитектуре регистры как есть отображаются на физические.

Я еще раз повторю, что архитектура не накладывает ограничений на реализацию. RISC-V это архитектура, ее описание(а скоро и формализованное) можно получить где-нибудь с riscv.org или соответствующего гитхаба. В частности ты можешь реализовать riscv как 100500-wide ООО машину(помним про закон Амдала) с переименованием регистров(пример BOOM) или же SERV ака выполнять АЛУ операции _побитово_.

anonymous
()
Ответ на: комментарий от anonymous

Бросается в глаза, что учебного курса по computer architecture или опыта работы в разработке CPU у тебя нет
computer architecture

Русский язык не английский и в русском языке под «архитектурой» обычно понимается нечто имеющее физическое воплощение, микроархитектура это вообще непонять что такое, «микро» - это уже что то мелкое компактное.
Нет хочешь говорить как мудак - пожалуйста, говори микроархитектура, геликоптер (так тоже в советских учебниках 30х годов писали) и каждому объясняй что архитектура это вот какой то абстрактный слой поверх физического дизайна.

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

Слава богу что у меня нет такого образования которое вдалбливает в голову какую то ерунду которая вообще не соответствует действительности.

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

Зачем вообще такое образование если тебя там не научили заставлять себя понимать и вникать в непонятное, а научили только запоминать слова из учебников и в блистающих латах отстаивать то во что веришь. Даже наверное в духовных семинариях уже так не учат.

uin ★★★
()
Ответ на: комментарий от uin

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

Так это реальная причина почему говноэльбрус сосёт и будет сосать всегда: компилятор не может знать, какими будут задержки, поэтому не может обеспечить загрузку испольнительных блоков ядра. Проблема принципиально нерешаема. Ну а сложность распределения регистров в компайлтайме - это всего лишь бонус OOO. Товарищ вот предположил, будто бы компиляторы этой дурью занимаются, а я объяснил, почему так делать нельзя.

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

У кого это есть сомнения? У разработчиков Эльбруса?

Вменяемые люди понимают, что внешняя обвязка достигла предела, что задержки, выраженные во времени, уже не будут падать, а если их выразить в тактах, то они будут расти. На десктопные процессоры уже ставят по 32 мегабайта кэша 3го уровня, и это делают не от хорошей жизни. И сволочной Парето уже глядит с укором и говорит, мол, ребята, чему я вас учил, вы уже самые вкусные части выели, и умножение кэша на два вам приносит смешные крохи. Так что твои 2-4 гигабайта кэша будут только термопакет ухудшать.

Кэши вообще проблему не решают, от слова совсем. Ты не задумывался, почему делают 3 уровня кэша? Ладно L3, он общий на все ядра, типа для обмена данными сойдёт, но нафига в одном ядре иметь L1 и L2? Может быть потому, что уже задержки L2 слишком велики, чтоб их просто игнорировать? Чем там поможет нашлёпка из L4, задержки которой будут раз в 10 больше чем у L2?

Подходы остались такие:

  1. Тупо делать всё в одном кристалле, вместе с памятью. Получится Cell BE. Всё предельно предсказуемо. Вроде даже в PPE Cell не было контроля готовности данных, компилятор пишет инструкцию загрузки, потом должен отступить несколько команд и только потом может пользоваться. Если попытается воспользоваться раньше - получит мусор в регистре. Просто праздник любителей выносить задачи на компилятор. Сони попыталась, оказалось слишком сложно для программистов.
  2. Экстремальная SMT. Смотри ниагару, например. Ядро жрёт 4 или более потоков, если какие-то из них стоят, то и фиг с ними, ядро выполняет другие. На практике людям не нравится, где взять нужное количество потоков? Да и иногда однопоточная производительность важна. И потом много потоков отчасти решают проблему, но и одновременно усугубляют её: повышаются требования к размеру и ассоциативности кэшей, иначе потоки будут вытеснять данные друг друга.
  3. ООО.

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

Вообще, проблема одна: иногда нужна тупая пропускная способность вычислений, но при этом вариант разнесения работы на много потоков или выноса на внешний вычислитель типа GPGPU неприемлем. В таких случаях увеличивают количество АЛУ в ядре и далее делают доступ к ним либо через VLIW, либо через SIMD. Однако из-за большого количества АЛУ становится как-то стрёмно позволять этому ядру простаивать. Суперскалярность + OOO + SIMD оказался практичнее, все к нему пришли. Да, требуется сложная обвязка, но на фоне уже жирного ядра, к которому нужен достаточно большой кэш, декодер/диспетчер умеющий в ООО не так уж и страшен.

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

Какие прерывания, ты в своём уме? Прерывание с контекст свичём для того чтоб избежать простоя из-за ожидания данных? Эльбрус можно спасти либо через SMT, чтоб тупо аппаратно переключался на другой поток, либо просто сделать нормальный OOO процессор просто с кривым VLIW-фронтендом, но это вариант при котором собираются худшие черты RISC и VLIW подходов, придётся глотать разреженный код, выкидывать все nop’ы и потом в рантайме отслеживать зависимости, как будто это был обычный RISC.

khrundel ★★★★
()
Ответ на: комментарий от anonymous

каждому объясняй что архитектура это вот какой то абстрактный слой поверх физического дизайна.

Я русский из деревни. Что такое «фронтенд»?

anonymous
()
Ответ на: комментарий от uin

Этого поциента порвало, следующего нам не нужно.[br] Ремарка напоследок: разница между нами в том, что те цпу, над которыми я работал, напечатаны и работают, а ты, выходит, даже не мамкин теоретик.[br] Ну, будешь на крылатской - заходи и послушай сказки от Бабаяна про неулучшаемую архитектуру.

anonymous
()
Ответ на: комментарий от uin

Современные компиляторы давно уже на практике строят оптимальный поток инструкций под суперскаляры

В такой формулировке это полуправда.

У арма вот было отличное суперскалярное in-order ядро, Cortex a8 называлось. Потом было тоже неплохое in-order ядро, как раз для big.Little Cortex a7. Потом, кажется, Cortex a53. Потом Cortex a55. И все они суперскалярят до 2х инструкций. Не больше. 2 инструкции им компилятры обеспечивают, да. Больше нецелесообразно, дальше лучше в OOO. Intel аналогично, добавил в Pentium второй порт для запуска очень ограниченного набора инструкций и дальше сразу пошёл в OOO. Потом были атомы у интела, аналогично 2-way in-order superscalar и далее так же добавляется OOO.

Так что довольно сложно понять, насколько хороший код могут генерировать компиляторы под суперскаляры, если в природе есть только 2-way in-order суперскаляры. Когда дело касалось VLIW, то даже 4-way суперскалярность оказалась не под силу компиляторам. Пока AMD работала с компиляцией удобного шейдерного кода, где половина работы - это матрицы и вектора, их кодогенератор как-то справлялся. Но с пришествием моды на GPGPU они выкинули нафиг VLIW. При том, что 4-way суперскалярность с OOO вполне себе работает и справляется.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Ты написал столько бреда. Попробую ничего не упустить.

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

Проблема частично решаема спекулятивным исполнением.

На десктопные процессоры уже ставят по 32 мегабайта кэша 3го уровня, и это делают не от хорошей жизни.

Локальность данных. Чем она выше, тем выше производительность.

нафига в одном ядре иметь L1 и L2?

Чтобы повысить локальность и сохранить тактовую частоту.

Чем там поможет нашлёпка из L4, задержки которой будут раз в 10 больше чем у L2?

Повысит локальность данных, тем самым повысит производительность в тех алгоритмах где это эксплуатируется.

Тупо делать всё в одном кристалле, вместе с памятью.

Если процесс миниатюризации не остановиться, то так и будет. Ядра станут меньше и быстрее. Задержки может и уменьшатся, но никуда не денутся.

Экстремальная SMT. Смотри ниагару, например.

Там не SMT, а Fine-grained multithreading (FGMT).

ООО

Вот тут ты прав. ООО отлично сглаживает задержки доступа в кеши. Память сглаживает похуже из-за небольшого окна, потому что длинная цепочка зависимостей заполняет очередь и ROB. Например 60 нс, это 240 тактов на 4 ГГц. За 240 тактов ядро в цикле может заполнить 1440 микроопераций, но размер очереди всего 97, а ROB 224. ООО помогает, но размер окна должен быть раз в 5-10 больше для отличного планирования промахов в кеш.

Вариант «ядер дофига, пусть стоят сколько влезет» не прокатил даже в мобилах, армы были вынуждены в OOO податься.

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

Эльбрус можно спасти либо через SMT, чтоб тупо аппаратно переключался на другой поток

Ему помог бы даже SoEMT, не говоря уже об FGMT или не дай боже SMT.

anonymous
()
Ответ на: комментарий от khrundel

Так это реальная причина почему говноэльбрус сосёт и будет сосать всегда: компилятор не может знать, какими будут задержки, поэтому не может обеспечить загрузку испольнительных блоков ядра. Проблема принципиально нерешаема. Ну а сложность распределения регистров в компайлтайме - это всего лишь бонус OOO. Товарищ вот предположил, будто бы компиляторы этой дурью занимаются, а я объяснил, почему так делать нельзя.

Так не надо знать точные задержки что бы осознавать что лоады это потенциально долгая хрень и лучше их закидывать как можно выше, а инструкции которые используют загружаемые данные подальше от него. Запустил лоад, посчитал что было независимо, а дальше ну подождать/постоять если уж не готово что поделаешь. Эффективность ОоО тут неочевидна потому что следующие инструкции могут быть частью другой программы которая ждет результат исполняемой, или там результат загрузился, а процессор уже забит каким то другим кодом, это при условии что так вообще возможно в одном треде, в гипертрединге то понятно что возможно его за этим и сделали потому что волшебный ОоО внезапно так же не знает откуда взять еще каких то инструкций на параллельно исполнить, если их тупо нет. Но спрашивается нахрена козе гипертрейдинг с 32-64 физическими ядрами (а все к этому идет).

Однако из-за большого количества АЛУ становится как-то стрёмно позволять этому ядру простаивать.

Ну так не позволяй своему процессору простаивать, всегда держи нагруженным на 100%, симды все нагрузи вычислениями.

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

Какие прерывания, ты в своём уме? Прерывание с контекст свичём для того чтоб избежать простоя из-за ожидания данных?

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

uin ★★★
()
Ответ на: комментарий от anonymous

Я русский из деревни. Что такое «фронтенд»?

Ну передний фронт значит, как у дидов в сороквтором - когда немцев в окопах в бинокль видно, можно инструкций им туда очередью послать и смотреть как они бегают. А что в тылу (в бакенде) и генштабе у них твориться это только разведданные.
Че те, мужик, не понятно то?

uin ★★★
()
Ответ на: комментарий от khrundel

У арма вот было отличное суперскалярное in-order ядро, Cortex a8 называлось. Потом было тоже неплохое in-order ядро, как раз для big.Little Cortex a7. Потом, кажется, Cortex a53. Потом Cortex a55. И все они суперскалярят до 2х инструкций. Не больше. 2 инструкции им компилятры обеспечивают, да. Больше нецелесообразно, дальше лучше в OOO. Intel аналогично, добавил в Pentium второй порт для запуска очень ограниченного набора инструкций и дальше сразу пошёл в OOO. Потом были атомы у интела, аналогично 2-way in-order superscalar и далее так же добавляется OOO.

А у тебя вообще не правда. Cortex A8 это был флагманский arm процессор в свое время. Жручий и горячий поэтому часть производителей типа Apple тупо его отказалась рассматривать в качестве подходящего процессора для карманной электроники (айподы айфоны уже были давно). А помоему Nvidia и самсунг тогда и придумали лепить старое ядро ARM11 и Cortex вместе и как бы при простоях и звонилке использовать одно а для задачь посерьезнее кортекс. А потом уже арм поняв что рынку нужно не просто какой то один ускорившийся процессор, а два - что то еще максимальноэкономичное даже в ущерб скорости по типу ARM11.

После этого линейка процессоров стала выпускаться в таком порядке:

armv7 Cortex-A9  (big) Cortex-A5  (LITTLE)
armv7 Cortex-A15 (big) Cortex-A7  (LITTLE)
armv8 Cortex-A57 (big) Cortex-A53 (LITTLE)


Сейчас оказалось что большинству хватает LITTLE ядер заглаза, они уже пор производительности старых флагманов переплюнули, а другим опять оверкил и не хватает экономичности, поэтому арм уже какие то там Cortex-A10-12 делает. В общем концепция давно уже полумертва.

uin ★★★
()
Ответ на: комментарий от anonymous

неулучшаемую архитектуру

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

uin ★★★
()
Ответ на: комментарий от anonymous

Проблема частично решаема спекулятивным исполнением.

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

Локальность данных. Чем она выше, тем выше производительность.

Садись, два.

Локальность данных - это просто название. А то что я написал - это причина, почему за эту локальность следует бороться.

Если процесс миниатюризации не остановиться, то так и будет. Ядра станут меньше и быстрее. Задержки может и уменьшатся, но никуда не денутся.

Процесс миниатюризации уже замедлился, ему есть физический предел, и в общем мы уже видим, что так не будет. Сейчас можно, наверное, несколько десятков компов IBM PC AT в один кристалл запаковать и пусть каждый из них крутит DOS на 640кб, да ещё и на гигагерцовых частотах. Но вместо этого мы видим 4-10 ядерные процессоры с общей памятью.

Говорю же, Sony попытались в много маленьких машин, не вышло. Ну, если хочется, пусть кто-то ещё попытается, решать всё равно будут кодеры на джаваскрипте.

Там не SMT, а Fine-grained multithreading (FGMT).

Для нашей темы разница непринципиальна. Хотя я без понятия, может FGMT реально не поможет, если у них там ожидающий поток жрёт циклы не уступая следующему.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Разбор очередной порции бреда.

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

Частично решаема. Спекулятивность + PGO/JIT.

Садись, два.

Ты у нас учитель информатики? Бедные дети…

Локальность данных - это просто название. А то что я написал - это причина, почему за эту локальность следует бороться.

Даже не знаю, что ответить на этот бред.

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

Но не остановился. Не забывай, что сейчас используется 2D компоновка.

Сейчас можно, наверное, несколько десятков компов IBM PC AT в один кристалл запаковать и пусть каждый из них крутит DOS на 640кб, да ещё и на гигагерцовых частотах. Но вместо этого мы видим 4-10 ядерные процессоры с общей памятью.

Говорю же, Sony попытались в много маленьких машин, не вышло.

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

Для нашей темы разница непринципиальна. Хотя я без понятия, может FGMT реально не поможет, если у них там ожидающий поток жрёт циклы не уступая следующему.

Ещё как принципиальна. SMT на 1 конвейере не сделаешь, нужен суперскаляр или ООО.

anonymous
()
Ответ на: комментарий от anonymous

суперскаляр или ООО

Поправлю себя.

Нужен суперскаляр, а ООО или нет, не важно.

anonymous
()
Ответ на: комментарий от uin

Так не надо знать точные задержки что бы осознавать что лоады это потенциально долгая хрень и лучше их закидывать как можно выше, а инструкции которые используют загружаемые данные подальше от него. Запустил лоад, посчитал что было независимо, а дальше ну подождать/постоять если уж не готово что поделаешь.

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

Ну так не позволяй своему процессору простаивать, всегда держи нагруженным на 100%, симды все нагрузи вычислениями.

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

Вообще, разве ты не видишь зияющей дыры в своей логике? Если тебе плевать на однопоточную производительность, незачем VLIW и вообще все суперскаляры, можно сделать 100500 простых ядер на низкой частоте и норм. Если однопоточная производительность нужна, тогда будут высокие частоты, многоуровневая система кэшей и вариант «ну если данные не успели, то пускай постоит, подождёт» уже не катит.

Эльбрусу тупо некуда тут примоститься, с одной стороны его GPU поджимают или всякие многоядерные/многопоточные широкие системы, с другой - современные OOO суперскаляры.

khrundel ★★★★
()
Ответ на: комментарий от anonymous

Частично решаема. Спекулятивность + PGO/JIT.

Чувак, ты вообще в курсе что такое спекулятивность? Это когда код исполняется, ещё не зная, должен ли он. Это только к условным инструкциям относится. PGO/JIT - это вообще мимо кассы. Я уж не вспоминаю о том, что для спекулятивности нужно иметь возможность отмотать назад, восстановив предыдущее состояние. Для него нужно переименование регистров, поэтому спекулятивность всегда будет идти в комплекте с ООО.

Даже не знаю, что ответить на этот бред.

Давай всё-таки определимся: дурачок тут ты, поэтому и бредом называется твой текст.

То, что ты даже после объяснения не понял, что твоё возражение про локальность данных - это глупость, как бы всё расставило по своим местам.

Разжую ещё проще: если бы у компа была вся память быстрая, то и хрен бы с ней, с локальностью данных. Можно было бы, как в ранней кибернетике любили, хранить всё в связанных списках и деревьях. Но память не быстрая. Поэтому добавляют костыль в виде кэша. И чтоб кэши были наиболее эффективны, придумали метрику «локальность данных». Эта штука, которая описывает, почему одно расположение данных - это хорошо, а другое - плохо. Не путай причину и следствие, это локальность данных нужна для удобства кэширования, а не кэширование нужно для «увеличения локальности данных».

Сложно программировать. Хочешь провернуть такую революцию,

Спасибо, не хочу. Как я уже написал выше, решать будут кодеры на джаваскрипте. На языке, в котором даже структура данных заранее не проектируется.

Ещё как принципиальна. SMT на 1 конвейере не сделаешь, нужен суперскаляр или ООО.

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

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Разбор очередной порции бреда.

Чувак, ты вообще в курсе что такое спекулятивность? Это когда код исполняется, ещё не зная, должен ли он. Это только к условным инструкциям относится.

Читай до просветления.

PGO/JIT - это вообще мимо кассы.

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

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

Или сгенерированный компилятором код восстановления.

Разжую ещё проще: если бы у компа была вся память быстрая, то и хрен бы с ней, с локальностью данных. Можно было бы, как в ранней кибернетике любили, хранить всё в связанных списках и деревьях. Но память не быстрая. Поэтому добавляют костыль в виде кэша. И чтоб кэши были наиболее эффективны, придумали метрику «локальность данных». Эта штука, которая описывает, почему одно расположение данных - это хорошо, а другое - плохо. Не путай причину и следствие, это локальность данных нужна для удобства кэширования, а не кэширование нужно для «увеличения локальности данных».

У тебя какая-то каша в голове. Локальность данных не только про описание структур, но и про доступность далеко удалённых активно используемых данных по минимальным задержкам. Если не согласен, отключай кеш страниц в линуксе. Когда говорят что данные доступны локально – это означает, что они в кеше или памяти или на диске, а не где на другом конце планеты. И чем ближе к потребителю, тем меньше задержки по доступу к ним, но и меньше размер этой памяти.

Спасибо, не хочу. Как я уже написал выше, решать будут кодеры на джаваскрипте. На языке, в котором даже структура данных заранее не проектируется.

Тогда не умничай и не учи остальных.

Я не большой специалист в этой теме

Оно и видно…

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

Multithreading (MT) бывает разный. Использовать всюду SMT нельзя. Пиши просто MT или многопоточность.

anonymous
()
Ответ на: комментарий от uin

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

Ведь именно поэтому бинарочную команду vip'а выдавили из интела(и они осели в нвидии, где пилят денвер), а ты продолжай ждать волшебные стренды от бабаяна, лол

anonymous
()
Ответ на: комментарий от khrundel

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

Вот тебе картинка, которая расставит всё на свои места.

anonymous
()
Ответ на: комментарий от anonymous

Без понятия кого там куда выдворили и я не жду стренды от бабаяна тем более это будут стренды от интела по факту.

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

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

uin ★★★
()
Ответ на: комментарий от uin

ну а ты...

А я вижу это все изнутри, хихикаю с тебя в кулачок и продолжаю работать.

я вообще не понял честно говоря за что ты.

За то, чтобы воинствующих кукаретиков-невежд было как можно меньше.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.