Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Железо и гаджеты доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
Очень интересно посмотреть как будет обстоять дело с кешем у этих super core.
Sа как это возможно ? Например 1 инструкция пропихиваетсч в io in процессора за такт. Этоже не делимое целое, как это работает ? Или тут как всегда чисто маркетинг?
Как я понял - это распараллеливание изначально однопоточной программы. Неясно только, на каком этапе (прямо во время исполнения бинарника?).
Гипертрединг наоборот - там два независимых потока запихивали на одно ядро, тут один поток распихивают по нескольким ядрам (выявляя независимые куски кода?).
Судя по всему, они будут производить чередование блоков инструкций по ядрам. Блоки должны быть независимы по данным, а за это будет отвечать компилятор при оптимизации.
Какой-то VLIW на стероидах.
Заявлен же старый софт. Значит по-идее никакой пере-компиляции не ожидается?
Скорее, аппаратный подход. Как у Transmeta или некоторых процессоров Nvidia Tegra.
Но эффективнее это будет работать на заранее подготовленном коде, где инструкции объединены в независимые блоки для чередования. Их обычный процессор выполнит нормальным образом, последовательно, а вот эти новые раскидают блоки по fused-ядрам.
Но эффективнее это будет работать на заранее подготовленном коде, где инструкции объединены в независимые блоки для чередования.
Такая "блочная оптимизация" кода, скорее всего, снизит скорость в однопоточном режиме. В ситуации, когда одновременно работающих приложений много, и каждое из них займет по одному ядру, эта "блочная оптимизация" окажется вредной.
Собственно в патенте они указывают, что режим "Суперядр" не универсальный и не идеальный. В ряде случаев он будет тормозить работу, и разумнее будет его отключить.
В некоторых примерах, после того как поток запущен в режиме суперядер, он отслеживается на случай необходимости его переключения обратно на обычное ядро. Необходимость в возврате к обычному ядру может возникнуть по разным причинам, например: а) приложение испытывает большое количество ошибок предсказания ветвлений из-за смены фазы программы или теряет параллелизм на уровне инструкций; б) в системе имеется много ожидающих выполнения потоков, которым требуются независимые ядра (по сути, системе требуется больше ядер, а не более крупные ядра); и т. д. В упомянутых выше сценариях ОС может принять решение о переводе приложения обратно из режима суперядер в режим обычного ядра. В некоторых примерах HGS, который может отслеживать IPC каждого приложения, будет знать обо всех потоках, использующих режим суперядер, и выберет наименее выгодный поток из них. Он порекомендует ОС перевести это приложение обратно на обычное ядро и освободить другое ядро для ожидающих выполнения потоков.
Такая "блочная оптимизация" кода, скорее всего, снизит скорость в однопоточном режиме
как я понимаю, нет. печь просто о хинтах процессору какие блоки не зависят друг от друга и могут быть разнесены на разные ядра. в общем-то out-of-order исполнение и так уже в современных процессорах есть
о хинтах процессору какие блоки не зависят друг от друга и могут быть разнесены на разные ядра
Это сложный анализ. Его можно делать заранее, но в этом случае преимущества новой архитектуры становятся не слишком очевидными.
Тут речь о каком-то дубовом решении, от которого среднестатистически должно быть больше пользы чем вреда. И это решение не должно ломать обычную архитектуру.
В описании сказано, что все переходы известны заранее. Они определяются выбранным фиксированным размером разбивки кода. Первая задача аппаратной поддержки в том, чтобы команды перехода вовремя подкинуть, после того как ядро выполнило свой блок. Вторая задача в том, чтобы данные полученные после выполнения блока одним ядром, были доступны для другого ядра, как будто оно само это блок выполняло.
А зачем так сложно? Вероятная ветка кода остаётся на первом ядре, маловероятная - запускается параллельно на свободном (допустим, третьем). В случае, если пошло по вероятной, третье ядро опять чистится и ждет новую ветку. Если же пошло по маловероятной - чистится первое ядро и исполнение продолжается на третьем. А первое ждет очередного ветвления.
В итоге ветвление "всегда угадывается" ценой двойной работы и повышения энергопотребления.
не понял, а что вас смущает? суперскалярность уже давно есть.
тут просто суперскалярность будет использовать alu/fpu/simd не одного, а нескольких ядер.
разумеется, далеко не любой код от этого выиграет.
Она использует инструкции управления потоком, вставленные в однопоточную программу.
Это как, простите? Если такие инструкции есть, то программа уже многопоточная.
Судя по тексту, инструкции управления потоком не присутствуют в исходном исполняемом коде, их напихивает тот самый софт, который рулит процессом.
Может речь об обычных инструкциях ветвления. Одно ядро выполняет одну ветку, другое вторую.
как я понял, имеются в виду явные и неявные зависимости между участками кода.
от vliw отличается тем, что в vllw компилятор уже заранее делит код на фиксированное число ядер, а тут в коде прописываются только зависимости, а разбиение по исполняющим ядрам динамическое.
мне кажется, я даже в каком-то из срачей по поводу vliw уже высказывал эту идею )
А я такое уже помню. Невероятная технология, которую AMD в Bulldozer использовала. Именно с этой целью там были два ядра в модуль объединены, но что-то пошло не так. Впрочем, тут скорее всего будет так же.
Не, не то.
Судя по тому, что я вижу, там всё забавнее.
Короче, лет так 6 назад, когда интел уже буксоал, но ещё не тонул, вышла у них микроархитектура Sunny Cove и активно готовилась флагманская архитектура Golden Cove. Флагманская, так сказать, переворот игры. Та самая, которая приносила P и E ядра.
Где-то в тоже время, в каком-то из центров, вроде бы в Орегоне, притащили супер-пупер идею, под названием Royal. По сути перспективная разработка. Как Golden Cove, только вот прям типа в разы лучше.
На идею этого Royal подтянули и Джима Келлера. Ну и сделали ставку.
Архитектура буксовала, инженеры говорили, что на бумаге вроде норм, но как-то такое себе на деле. ДА и запуск оценивался где-то на 2026 год, не раньше (а надо было раньше).
Келлер, понятно дело, в 20 году уже свалил, зато Гелсингер, как говорят, чуть ли е молился на эту архитектуру. Это ж типа не надо делать производительные и мелкие ядра, можно просто напихать дофига мелких, которые могут самоорганизовываться в крупные если надо.
Короче, я вижу вот в том, что описано, тот самый Royal, Только пока не понятно, это какое-то отчаяние, типа "вбухали ресурсы - не выбрасывать же" или же они как-то это смогли довести хотя бы до какого-то рабочего состояния.
Если я правильно понял, то идея "Суперядра" такая - бьем однопоточный код на одинаковые куски, и ядра выполняют эти куски в шахматном порядке. Профит.
Ну а если профита нет, то отползаем с "Суперядра" обратно на обычное.
У Суперядра есть программная часть в ОС, и аппаратная часть в процессоре.
Размер кусков определяется на уровне ОС, по какому-то принципу, и записывается в спецрегистр.
Аппаратная часть поддержки Суперядра содержит кенгуратор и анализатор. Кенгуратор помогает ядрам перепрыгивать через куски кода, предназначенные для других ядер. Анализатор оценивает эффективность всей это авантюры. Если эффективность низкая, то анализатор посылает программной части сигнал - "Походу не сработало". Программная часть отключает режим Суперядра, или как-то меняет настройки, например длину кусков кода.
Вспоминаю новости из 2000х про то как AMD хотела выпустить свой ответ INTEL Hyper threading - Анти HT - в нем то как раз и было заявлено объединение мощностей двух ядер в одно суперядро.
Может, это под какую-то специфичную нагрузку? Типа, что-нибудь про слабые нейросети на локальных компах.
А если туда и HT ещё впихнуть... :)))
Это че, у меня наконец-то стелларис на 2200 году на гигантской галактике перестанет тормозить что ли?
HyperComposed-Threading :-)
О, Интел решил использовать идею VISC от Soft Machines, которую он купил и успешно забросил.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Intel запатентовала новый формат процессорных ядер