Здравствуйте, Kernighan, Вы писали:
K>Ну правильно. Именно поэтому и нужно делать своё. K>Чтобы не попадать в технологический тупик. K>Весь смысл Эльбруса именно в этом.
K>Да, кстати, ты знаешь, что у Эльбруса есть специфичная фишка — тегированная память?
О да. Редкостно бесполезная реализация.
The God is real, unless declared integer.
Re[7]: Подскажите как сейчас принято искать работу
Здравствуйте, vdimas, Вы писали:
V>в основном вычислительных/математических и мультимедиа) получались в среднем не хуже, а иногда даже серьёзно лучше
То есть тех, где прекрасно справляется GPGPU и исполнять их на обычном универсальном процессоре нет практически никакого смысла.
V>А у тебя какие будут доказательства всей твоей голословности в этом топике?
Не хами. Что конкретно я должен доказать?
Re[8]: Подскажите как сейчас принято искать работу
Здравствуйте, Kesular, Вы писали:
V>>в основном вычислительных/математических и мультимедиа) получались в среднем не хуже, а иногда даже серьёзно лучше K>То есть тех, где прекрасно справляется GPGPU
Не справляется. У него архитектура не подходящая и большие задержки по передаче данных.
K>и исполнять их на обычном универсальном процессоре нет практически никакого смысла.
И вот опять сугубо умозрительные рассуждения.
Опять это фантазёрство...
V>>А у тебя какие будут доказательства всей твоей голословности в этом топике? K>Не хами. Что конкретно я должен доказать?
Ты много чего тут успел понаписать, эдак тебя понесло-то.
Я лишь хочу поинтересоваться источником твоего вдохновения.
Здравствуйте, Kernighan, Вы писали:
C>>Современные Intel'ы внутри так и работают — предсказатель переходов, по сути, и есть "перекомпиляция на лету". Туда ещё добавляется и спекулятивное исполнение, когда CPU одновременно исполняет обе ветки if'а до тех пор, пока точно не станет известен результат сравнения. K>Неправильно! K>CPU всегда исполняет ОДНУ ветку. Ту, которую он считает более вероятной.
Это так обычный предсказатель переходов работает. А современные Intel именно что исполняют обе ветки, хотя предсказанная ветка пойдёт дальше.
K>А если не угадал, то откатывает результаты. K>Достаточно подумать пять минут, чтобы понять, почему это лучше.
Проблема тут в том, что при неправильном предсказании CPU должен будет переделать всю работу. В случае параллельного исполнения одна ветка просто будет отброшена.
Минус в том, что глубина предсказания ограничена (на практике одним уровнем) и требуется больше ALU на выполнение ненужных операций (которые можно было бы израсходовать на ещё одно ядро).
Здравствуйте, m2l, Вы писали:
V>>Примерно так надо писать параллельный код для сигнальных процов: V>>Исходник на С: m2l>Я не знаю к чему ты его привел.
Не удивительно.
Поэлементное умножение векторов с накоплением суммы — это основная операция при обработке информации и фактически единственная.
Это происходит в задачах ИИ, фильтрации, регрессии/корреляции, прямого и обратного преобразования Фурье, наложения оконных и вероятностных ф-ий, перемножения матриц, преобразования координат и т.д. до бесконечности. Поэтому и был взят именно этот код в ответ на просьбу привести пример. Любое кодирование/раскодирование аудио-видео, фазовое детектирование и автоподстройка WiFi/Bluetooth и т.д. выполняется именно так.
Или разложение тригонометрических ф-ий в ряд Тейлора — берётся x*x и ряд известных коэф разложения некоей конечной длины — тоже будет операция умножения со сложением, где каждый новый член ряда получается из предыдущего. Например, четные и нечетные члены ряда можно считать параллельно, потом сложить.
m2l>Скомпилится в любую архитектуту...
Но хорошо работает только в DSP, бо он заточен именно на подобного рода операции. И делает это весьма эффективно при потреблении энергии, стремящейся к 0-лю.
V>>Или аналогичный исходник на так называемом "последовательном ассемблере": m2l>Отлично, ассемблер TMS. Какие их dsp на архитектуре VelociTY стоят в iPhone 5, на который ты ссылаешься?
Ядра TI занимают бОльшую долю рынка всех существующих DSP. Поэтому, разумеется, я привёл одну из архитектур TI. Разумеется, этих архитектур более одной, но приводить в кач-ве примера стоило современный мейнстрим, если речь о сегодняшнем положении дел.
А так-то можно было привести архитектуру AltiVec от Apple/IBM/Motoolla. Ядра с этой архитектурой включают, например, в PowerPC и Cell. Но там примерно то же самое:
Согласно документации Apple, AltiVec в реализации на процессорах G4 и G5 может выполнять восемь 32-битных FLOPS за цикл,
Или еще можно было привести пример CEVA-XC архитектуры (тоже VLIW): http://www.ceva-dsp.com/product/ceva-xc4500/
которая используется в микросхемах потребительского уровня WiFi/Bluetooth от Broadcom. Про последнюю контору ты должен был как минимум слышать.
Погуглив еще (при желании) ты увидишь достаточно альтернатив, в том числе суперскалярные, где практически все суперскалярные успешно сдохли во второй половине 2000-х. Потому что настала мобильная эра и опять энергоэффективность стала в цене. Вот поэтому имеем засилье RISC и VLIW, как ни крути.
Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы.
m2l>Если честно я вообще не слышал распрастраненных моделей TMS для "Bluetooth/WiFi/Звуковой чип/камера".
Ну, что далек от темы даже просто вычислений, было видно по твоей реакции на мой пример.
Ну и в плане эрудиции тоже вопросы, однако. Уже лет 15-20 DSP-микропроцессоры в "чистом виде" практически не применяются. Чаще в составе некоей SoC, где могут жить, в том числе, ядра того же ARM или MIPS. А даже если взять какой-нить "отдельный" современный DSP-процессор, то внутри него окажется чуть ли не весь южный и северный мост (в терминах архитектуры Интел).
V>>Но не суть, действительно интересующимся предлагаю погуглить, например, по "TMS320C6000 assembly optimizer". m2l>Вот смотри, меняем один символ и получаем TMS320C5000. Который не разу не VLIW
Который на этапе т.н. "компоновки команд" делает VLIW.
Просто у него 2 операции за раз, а не 8.
m2l>но производится и используеться.
И уже лет 15 как не является мейнстримом.
m2l>И выходит, твоё: m2l>
m2l>Собсно, все современные сигнальные процы — VLIW
m2l>Ложно.
Ключевое выделил.
V>>Так вот, из любого из данных выше исходных вариантов в итоге получается такое: m2l>Отлично листинг VLIW ассембленра. Но из прошивки для какого "Bluetooth/WiFi/Звуковой чип/камера"? Как твой пример доказывает, что на моём "ноуте/планшете" есть Bluetooth с VLIW архитектурой?
— Петька, приборы!
— 42!
— что "42"?
— а что "приборы"?
Ты бы хоть марку чипов назвал для начала разговора.
V>>Что означает признак "||" объяснять надо? m2l>Не думаю, что там что-то менялось.
А подумай.
V>>Чтобы происходящее было понятней — это код для одной из самых популярных DSP-архитектур последних 20 лет: m2l>Ты понимаешь, что из утверждения VelociTY VLIW архитектура, не следует: m2l>
m2l>Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично. Звуковой чип? — разумеется тоже.
Не согласен — опровергай, какие проблемы?
Я и так уже слишком много вводных дал для твоего простого несогласия.
А от тебя пока ровно ноль инфы.
Нечестно как-то...
m2l>Лично мне как-бы побоку CISC/RISC/VLIW
тогда зачем всё это тебе? скучно? ))
m2l>гранитцы между ними эфимерны. Но если ты хочешь делиться своими знаниями
Инфой обычно делятся перед любопытной/благодарной аудиторией или хотя бы в честном споре.
Увы, такое ощущение последние лет 10, что умение спрашивать и навыки честного спора более не в цене.
Здравствуйте, netch80, Вы писали:
K>>Да, кстати, ты знаешь, что у Эльбруса есть специфичная фишка — тегированная память? N>О да. Редкостно бесполезная реализация.
Можно аппаратно защититься от проходов по памяти.
Не так уж и бесполезно.
Re[9]: Подскажите как сейчас принято искать работу
Здравствуйте, vdimas, Вы писали:
V>Не справляется.
И что это за алгоритмы такие? Давай конкретику.
V>Ты много чего тут успел понаписать, эдак тебя понесло-то. V>Я лишь хочу поинтересоваться источником твоего вдохновения.
Здравствуйте, Ops, Вы писали:
Ops>Давно вытащил и выкинул этот пылесборник.
Это рабочий комп. Я его не разбираю. Дома другое дело: нигде ничего не осталось.
Ops>У меня одна 8-дюймовая — единственное, что из дискет вообще сохранилось, так, на память.
Я дома внезапно обнаружил пачку 3-дюймовых дискет. 5-, а тем более 8-дюймовых не осталось. Не сохранились.
Даже CD/DVD все повыкидывал, только привод оставил в шкафу на всякий случай, думаю, и его уже пора на помоечку.
DVD лежит в сторонке. На всякий случай. За последние 5 лет таких случаев было не более двух.
Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично. Звуковой чип? — разумеется тоже. Камера? — а как же, в ней живет "аппаратный кодек MP4", который представляет из себя банальный сигнальный процессор с фиксированной прошивкой. Про тач-скрин уже писал.
V>А так-то можно было привести архитектуру AltiVec от Apple/IBM/Motoolla. Ядра с этой архитектурой включают, например, в PowerPC и Cell. Но там примерно то же самое:
"архитектуру AltiVec" --> "набор инструкций AltiVec". Apple Power PC ушел лет 15 назад. И это не DSP из iPhone 5, на который ты ссылаешься. И G4/G5 это не DSP для Bluetooth/WiFi даже...
V>Или еще можно было привести пример CEVA-XC архитектуры (тоже VLIW): V>http://www.ceva-dsp.com/product/ceva-xc4500/
На этом сайте внизу примеры, где используется. С твоим утверждением "Собсно, все современные сигнальные процы — VLIW" не стыкуется.
Подтверждений твоих слов нет. Только читаешь лекции про использование умножения в ИИ и расказываешь, от чего я далек, с чем несогласен.
Здравствуйте, vdimas, Вы писали:
V>Ядра TI занимают бОльшую долю рынка всех существующих DSP. Поэтому, разумеется, я привёл одну из архитектур TI. Разумеется, этих архитектур более одной, но приводить в кач-ве примера стоило современный мейнстрим, если речь о сегодняшнем положении дел.
V>А так-то можно было привести архитектуру AltiVec от Apple/IBM/Motoolla. Ядра с этой архитектурой включают, например, в PowerPC и Cell. Но там примерно то же самое: V>
V>Согласно документации Apple, AltiVec в реализации на процессорах G4 и G5 может выполнять восемь 32-битных FLOPS за цикл,
Приводить SIMD в качестве аргумента за VLIW — это пять. Косяков.
Я уже не удивляюсь, просто замечу для окружающих, что в таком смысле и x86 нынешний — VLIW. А на самом деле, естественно, нет.
V>Погуглив еще (при желании) ты увидишь достаточно альтернатив, в том числе суперскалярные, где практически все суперскалярные успешно сдохли во второй половине 2000-х. Потому что настала мобильная эра и опять энергоэффективность стала в цене. Вот поэтому имеем засилье RISC и VLIW, как ни крути.
RISC ничуть не противоречит суперскалярности, а все топовые RISC реализации как раз суперскалярны.
V>Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы.
Это как раз не "всей разницы", а критично для данного обсуждения. Потому что SIMD мало того, что не составляет никакой специфики VLIW — он цеплялся даже поверх неконвейеризованных процессоров 70-х — он и не конфликтует с суперскалярностью, скорее даже наоборот — например, SIMD регистры типа XMM в x86 точно так же переименовываются, а операции переставляются.
Не комментирую остальное (про VLIW в сигнальных процессорах и т.п.), но тут тебя явно не туда понесло.
Или в сигнальных на самом деле такой же VLIW, который на самом деле не VLIW?
Здравствуйте, netch80, Вы писали:
V>>Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы.
N>Это как раз не "всей разницы", а критично для данного обсуждения.
Критично, это когда SIMD не на RISC.
N>он цеплялся даже поверх неконвейеризованных процессоров 70-х
При чем тут конвейеризированость?
Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях. Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду". Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.
N>он и не конфликтует с суперскалярностью
Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))
N>скорее даже наоборот — например, SIMD регистры типа XMM в x86 точно так же переименовываются, а операции переставляются.
Сам же себе возразил.
Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один так (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))
В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
N>Не комментирую остальное (про VLIW в сигнальных процессорах и т.п.), но тут тебя явно не туда понесло. N>Или в сигнальных на самом деле такой же VLIW, который на самом деле не VLIW?
Тебя тоже в Гугле забанили?
Re[10]: Подскажите как сейчас принято искать работу
Здравствуйте, Kesular, Вы писали:
V>>Не справляется. K>И что это за алгоритмы такие? Давай конкретику.
Любые, где требуется low-latency и вообще hard realtime.
V>>Ты много чего тут успел понаписать, эдак тебя понесло-то. V>>Я лишь хочу поинтересоваться источником твоего вдохновения. K>Конкретику давай, твой треп меня уже утомил.
До этого меня утомил твой трёп:
Судя по реальным бенчмаркам, они таки тянут очень неплохо, и далеко не факт, что ядра эльбруса чем-то лучше.
Здравствуйте, m2l, Вы писали:
V>>Или еще можно было привести пример CEVA-XC архитектуры (тоже VLIW): V>>http://www.ceva-dsp.com/product/ceva-xc4500/ m2l>На этом сайте внизу примеры, где используется. С твоим утверждением "Собсно, все современные сигнальные процы — VLIW" не стыкуется.
Мде...
По ссылке:
The CEVA-XC4500 DSP core is the fourth generation of the widely licensed CEVA-XC architecture. Optimized for advanced communication applications, especially high-performance wireless infrastructure equipment, it features a combination of VLIW (Very Long Instruction Word) and vector engines that enhance typical DSP capabilities with advanced scalar and floating-point vector processing.
Более того, спеки архитектуры CEVA-XC лежат в свободном доступе, какие у тебя проблемы-то?
m2l>Подтверждений твоих слов нет.
Это сразу в сад.
Кто не умеет проглотить даже разжёванное — молча на выход.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kernighan, Вы писали:
K>>Неправильно! K>>CPU всегда исполняет ОДНУ ветку. Ту, которую он считает более вероятной. C>Это так обычный предсказатель переходов работает. А современные Intel именно что исполняют обе ветки, хотя предсказанная ветка пойдёт дальше.
Современный Интел делает именно так, как я сказал.
Тебе надо было пять минут подумать. А ты не подумал.
За то, что не подумал, будешь порот.
K>>А если не угадал, то откатывает результаты. K>>Достаточно подумать пять минут, чтобы понять, почему это лучше. C>Проблема тут в том, что при неправильном предсказании CPU должен будет переделать всю работу. В случае параллельного исполнения одна ветка просто будет отброшена.
По словам "переделать всю работу" сразу видно, что ты не понимаешь, о чём говоришь.
C>Минус в том, что глубина предсказания ограничена (на практике одним уровнем) и требуется больше ALU на выполнение ненужных операций (которые можно было бы израсходовать на ещё одно ядро).
Ну разумеется. И поэтому ВСЕГДА предпочитают сделать ещё одно ядро, а не то, что ты тут нафантазировал.
Итак, что происходит на самом деле.
Процессор исполняет программу и в коде программы встречает условный переход.
Процессор не знает, куда пойдёт исполнение — прямо или по направлению перехода.
Есть хорошая эвристика — переходы назад всегда исполняются (потому что это цикл),
А переходы вперёд никогда не исполняются (потому что большинство условий — это обработка нереальных ошибок).
Эта эвристика позволяет угадать 90% случаев.
Остальные случаи угадываются за счёт того, что помнится направление перехода в этом месте в прошлый раз.
Но мы это рассматривать не будем. Просто поверим в то, что предсказатель в 90% (или больше) предсказывает правильно.
Теперь мы стоим перед выбором — что делать: выполнять одну ветку или обе?
Пусть процессор имеет 4 АЛУ, которые можно загрузить операциями.
И пусть направление перехода мы узнаем через три такта.
В случае, если мы все 4 АЛУ отдали под главную ветку, мы выполним 12 операций и с 90% вероятностью угадаем.
В случае, если мы 2 АЛУ отдали под одну ветку, а 2 под другую, то мы выполним только 6 операций нужной ветки.
Да, при втором варианте мы никогда не ошибёмся, но в первом варианте мы в 90% выполняем в два раза больше операций.
Поэтому всегда выбирается первая схема. Она и более простая и более эффективная.
Причём, чем лучше предсказывает предсказатель, тем меньше нужна вторая ветка.
В случае,если мы не угадали направление перехода ничего переделывать не надо.
Запущенные операции идут через АЛУ как шли.
Просто результаты выполненных операций не пишутся в регистры.
Поскольку конвейер у нас выполняет все операции за одно число тактов,
то к моменту записи мы уже знаем, произошёл переход или нет.
Так работает любой нормальный суперскалярный RISC (и с перестановкой и без перестановки команд).
VLIV-ы я не разрабатывал, но наверное и там всё так же.
Могу рассказать, что произойдёт, если в этих 12 командах тоже встретится условный переход
Здравствуйте, vdimas, Вы писали:
V>>>Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы. N>>Это как раз не "всей разницы", а критично для данного обсуждения. V>Критично, это когда SIMD не на RISC.
Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом), или вообще что-то очень оригинальное (и слабо соответствующее действительности) думаешь про RISC. Оба варианта меня смущают.
N>>он цеплялся даже поверх неконвейеризованных процессоров 70-х V>При чем тут конвейеризированость? V>Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях.
Не во всех RISC. И откуда тут взялась идея про побочные эффекты?
V> Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду".
Если ты про Thumb в ARM, то это больше похоже на вариант "нам же надо как-то сэмулировать условное выполнение от полного режима, не ломая компиляторы, сделаем хоть как-то".
V> Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.
Delay slot на 5 команд? Оригинально ты же перед этим показывал, что это VLIW. Зачем это называть конвейером, когда это пакет одновременно исполняющихся команд?
N>>он и не конфликтует с суперскалярностью V>Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))
Видимо, конфликтует только в твоих представлениях, в которых RISC не может иметь суперскалярность.
Или они для тебя уже не RISC? Тогда вводи свои термины специально для этой дискуссии.
N>>скорее даже наоборот — например, SIMD регистры типа XMM в x86 точно так же переименовываются, а операции переставляются. V> V>Сам же себе возразил.
Нет.
V>Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один так (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))
Спасибо, кэп. И что?
V>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
N>>Не комментирую остальное (про VLIW в сигнальных процессорах и т.п.), но тут тебя явно не туда понесло. N>>Или в сигнальных на самом деле такой же VLIW, который на самом деле не VLIW?
V>Тебя тоже в Гугле забанили?
Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию
Здравствуйте, Kernighan, Вы писали:
C>>Минус в том, что глубина предсказания ограничена (на практике одним уровнем) и требуется больше ALU на выполнение ненужных операций (которые можно было бы израсходовать на ещё одно ядро). K>Ну разумеется. И поэтому ВСЕГДА предпочитают сделать ещё одно ядро, а не то, что ты тут нафантазировал.
Ну почитай про Silvermont.
K>Остальные случаи угадываются за счёт того, что помнится направление перехода в этом месте в прошлый раз. K>Но мы это рассматривать не будем. Просто поверим в то, что предсказатель в 90% (или больше) предсказывает правильно. K>Теперь мы стоим перед выбором — что делать: выполнять одну ветку или обе?
Отойдём на шаг назад. CPU при прохождении ветки переименовывает регистры, так что у него получается две копии их. Одна для прохождения ветки, другая для отката назад.
K>Пусть процессор имеет 4 АЛУ, которые можно загрузить операциями. K>И пусть направление перехода мы узнаем через три такта. K>В случае, если мы все 4 АЛУ отдали под главную ветку, мы выполним 12 операций и с 90% вероятностью угадаем. K>В случае, если мы 2 АЛУ отдали под одну ветку, а 2 под другую, то мы выполним только 6 операций нужной ветки.
Пока всё так.
Но 3 такта на результат операции — это очень часто сверхоптимистичная оценка, очень часто вычисление условия требует взятия данных из дальних областей памяти. И в этих случаях получаем классический pipeline stall, что позволяет нам безболезненно использовать свободные ALU для вычисления второй ветки.
K>Так работает любой нормальный суперскалярный RISC (и с перестановкой и без перестановки команд).
Не совсем любой. Некоторые предпочитают вместо предсказания перехода делать, например, переключение на другой поток.
Здравствуйте, vdimas, Вы писали:
V>Любые, где требуется low-latency и вообще hard realtime.
А, то есть где нормальные люди используют FPGA или ASIC. Это во первых.
А во вторых, насколько я понимаю, на Ельбрусе используется обычный линух — со всеми плюшками типа многозадачности, виртуальной памяти и так далее. И кэш там, насколько я понимаю, тоже есть. Так что откуда там вообще мог взяться hard realtime?
V>Пруфы таких громкий заявлений будут?
Здравствуйте, netch80, Вы писали:
N>Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом)
Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.
RISC — это философия построения процессоров, хотя сама аббревиатура изначально появилась от философии формирования системы команд. Но сейчас хватает RISC-процессоров, у которых количество команд поспорит с оными из CISC-мира.
N>или вообще что-то очень оригинальное (и слабо соответствующее действительности) думаешь про RISC. Оба варианта меня смущают.
Ну вот чтобы не смущало, надо отделять мух от котлет.
V>>Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях. N>Не во всех RISC.
Почти во всех с конвейером ненулевой длины.
N>И откуда тут взялась идея про побочные эффекты?
От конвейеризированности в отсутствии планировщика, вестимо.
Всё-таки философия RISC — это минимизация "побочных" устройств в процессоре (помимо целевых-исполнительных).
V>> Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду". N>Если ты про Thumb в ARM, то это больше похоже на вариант
Не важно, на что это похоже. Это один из способов условного ветвления без сброса конвейера.
Ключевое выделено. Безусловные ветвления отслеживаются еще на этапе предвыборки.
V>> Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.
N>Delay slot на 5 команд? Оригинально ты же перед этим показывал, что это VLIW. Зачем это называть конвейером, когда это пакет одновременно исполняющихся команд?
Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.
V>>Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". )) N>Видимо, конфликтует только в твоих представлениях, в которых RISC не может иметь суперскалярность.
Не может. Еще раз, медленно. В основе суперскалярности лежит абстракция исходного кода от кол-ва исполнительных устройств. Это принципиально. И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.
Помимо RISC и CISC есть еще гибридная технология со своим названием — MISC, может тебя это смущает?
N>Или они для тебя уже не RISC? Тогда вводи свои термины специально для этой дискуссии.
Зачем? Есть вики, там вполне доступно и в этом вопросе правильно.
V>>Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один такт (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. )) N>Спасибо, кэп. И что?
Дык, в этом состоит принципиальное отличие RISC от суперскаляра/СISC. Т.е. отличие не в системе команд, а в способе исполнения этих команд.
V>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях. N>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS и имел собственную аббревиатуру. Затем в других архитектурах — DEC Alpha и PowerPC, где под векторные вычисления явным образом были введены дополнительные процессорные элементы, т.е. доступные для непосредственного их программирования. Их даже иногда называют "DSP-сопроцессоры". А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике. Т.е. как по мне — это просто стыренная из другой предметной области аббревиатура. Маркетинг, мать его так. ))
В терминологии оно как? Кто первый, того и тапки. Я просто показываю, откуда "оно" взялось.
N>Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию
Да, я в курсе, что иногда умею разродиться постами, "режущими слух".
Зрите в корень, как грится, и да пребудет с вами сила. ))
Здравствуйте, Kesular, Вы писали:
V>>Любые, где требуется low-latency и вообще hard realtime. K>А, то есть где нормальные люди используют FPGA или ASIC. Это во первых.
Ты спрашивал про GPU — я ответил.
K>А во вторых, насколько я понимаю, на Ельбрусе используется обычный линух — со всеми плюшками типа многозадачности, виртуальной памяти и так далее. И кэш там, насколько я понимаю, тоже есть. Так что откуда там вообще мог взяться hard realtime?
Не факт, что в военных комплексах будет использоваться Linux, а не какая-нить реалтаймовая ось или даже вовсе без всякой ОС. В крайнем случае есть разновидности реалтаймового Linux.
V>>Пруфы таких громкий заявлений будут? K>Они там были. Иди и читай.
