Re[20]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.06.17 14:51
Оценка:
Здравствуйте, 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>Тебя тоже в Гугле забанили?


Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.