Фог пишет Т.е. получается что вызов API или собственной DLL функции практически всегда сбрасывает конвейер?
Y_Mur Нет не "практически всегда", а только при отсутствии записи в BTB, т.е. при первом вызове. При последующих вызовах осуществляется спекулятивный переход "к той же цели, что и в прошлый раз", а поскольку цель не изменяется, то и ошибок предсказания не будет А вот для типичной конструкции switch\case ошибки предсказания неизбежны, т.к. адрес перехода в общем случае изменяется. Причем только в PM и видимо в Core 2 есть Indirect Branch Predictor, распознающий регулярные чередования косвенных переходов, а на других процах каждое изменение адреса перехода будет сопровождаться ошибкой предсказания
На AMD - точно, кроме случая, когда переход два раза подряд к одной и той же цели. У них для indirect'а сохраняется только одна цель на инструкцию перехода.
leo Т.е. если вызывать кучу разных внешних функций, то ВТВ их все запомнит? Насколько я понял Фога, запоминается только один вызов, т.е. "практически всегда" означает: "за исключением редких случаев, когда одна и та же функция вызывается несколько раз подряд, не чередуясь с вызовом других внешних функций". Буду очень рад если я понял Фога не правильно
Y_Mur Да нет, перечитай еще раз - не один вызов (т.е. адрес самого jmp\call), а одна цель для каждого вызова, т.е. один адрес цели перехода для каждого вызова как и при обычных jcc. Только при jcc еще и последовательности чередования переход\не переход (паттерны) отслеживаются, а тут нет - длина паттерна = 1, т.е. проц запоминает цель последнего перехода и в следующий раз прыгает на эту цель Да, пока они не будут вытеснены другими. Это же относится и к прямым jmp\call, и косвенные от них отличаются только тем, что после каждого вызова происходит обновление адреса цели, а для прямых ес-но нет, т.к. адрес фиксирован
leo Спасибо А что прямой безусловный jmp\call тоже в первый раз сбивает конвейер? Здесь же угадывать совсем ничего не надо.
Y_Mur Сбивает, но не весь - также как и статическое предсказание условных jcc. Угадывать ес-но ничего не надо, а надо просто пройти несколько стадий конвеера от загрузки блока инструкций до выхода декодера, чтобы понять что это инструкция jmp\call и куда нужно прыгнуть. В P6 и AMD fetch+decode составляют около 5-7 стадий, т.е. около половины длины всего конвеера. В P4 число стадий декодирования неизвестно, но видимо оно должно быть больше чем в P6 и AMD. Поэтому грубо можно считать, что пенальти при первом безусловном переходе или статически предсказанном прыжке по jcc может составлять примерно половину штрафа за непредсказанный jcc или indirect, которые приводят к сбросу всего конвеера
Y_Mur Вот картинка для наглядности: Код (Text): Основные стадии конвеера (каждая может состоять из нескольких стадий): BTB.fetch.decode.RAT\ROB\Shed.Exec.Flags ^____________________________________^ - штраф за ошибку jcc и indirect ^_______________^ - штраф за первый проход jmp\call и верный static ^_ - 1(0) такт при правильном прыжке по BTB ^ - 0 при правильном не-прыжке по BTB
[offtopic] Красивая картинка ) [/offtopic] 2leo, я не совсем понял, ты говоришь что если ты по томоже адресу делаешь call, то процессор предскажет это, и то что запоминается N-нное количество адресов. А как процессор угадает по какому из этих адресу я собираюсь сделать call/jmp?
n0name По паттерну. Скажем цель перехода в таком коде: Код (Text): void (* farr)()[] = {f1, f2, f3, f4}; for(int i = 0; i < 256; ++i) farr[i & 3](); на PM и Core2 с какого-то момента всегда будет предсказываться правильно.
n0name Здрасс-те, или я тебя не понял или ты меня Я говорил, что во всех процессорах запоминаются адреса самих инструкций jcc\jmp\call и во всех процессорах кроме PM+ для каждой из них запоминается только один адрес цели перехода (т.е.адрес куда будет совершен переход), поэтому и гадать тут не приходится - куда был прыжок в предыдущий раз, туда и прыгаем - если угадали, то хорошо, если нет - то сброс конвеера и переход по новому адресу. Для прямых переходов и для вызовов API адрес цели не изменяется, поэтому и ошибок не будет. А то, о чем ты говоришь, реализовано только в PM+ - для каждого косвенного перехода запоминаются все адреса целей по которым были переходы. А предсказание осуществляеется по паттерну, почти также как и для jcc. Только в jcc адрес цели фиксирован, зато переход или совершается (taken) или не совершается (not-taken), поэтому паттерны это последовательности бит 1 - taken, 0 - not-taken. А косвенный переход всегда taken, но по разным адресам. Поэтому адреса целей записываются в спец.массив и в паттернах запоминаются не биты 1\0, а индексы этого массива (по мнению Фога 6-7 бит на индекс). В итоге если переходы осуществляются не по случайным адресам, а упорядоченно (как в примере Ustus'а), то через период повторения в паттерне оказывается правильная последовательность чередования адресов и далее проц просто прыгает по этим адресам
n0name Из лесу вестимо А.Фог + мануалы Intel & AMD (в т.ч. и старые по P6) + по крупицам из статеек Но вот разбираться в тонкостях работы предсказателей переходов - чес слово, лень Это к Ustas'у - он аохоже свой виртуальный процессор разрабатывает
n0name Никому еще не удалось выяснить, откуда он столько знает Иногда даже страшно становится: не знает ли он Слишком Много Не совсем Хотя в перспективе - не исключено Пока же гораздо скромнее - что-то типа Pipeline Simulator'а для как можно большего множества процессоров. Но с каким же скрипом идет, зар-р-раза И еще производители смерти моей хотят - не успел еще даже наполовину разобраться с NetBurst - а вражеский Интел хоп так легко прыг-прыг - глядишь и забьет на энту архитектуру.
Ustus Этого и следовало ожидать А ты помниться "восхищался" суперидеей T-кэша и еще каким-то прибамбасам NetBurst А все это оказолось хитрой ловушкой - пока они нам впаривали свои сверчастоты и сверхмощности, "секретные командос" PM & Core втихушечку отрабатывали идеи Next Generation. Похоже и AMD на эту удочку попалось ...
leo Мне все же думается, что некоторые идеи из NetBurst еще пригодятся с будущем - когда процы перестанут соревноваться, кто холоднее и начнут опять тупо гнать частоту. Ведь идея Т-кэша не на ровном месте родилась, это как бы вынужденая мера для обеспечения работоспособности на гигантских конвейерах, которые, в свою очередь возникли в результате попыток разгрузить исполнительные модули процессора и получить приемлемую пропускную способность при высокой латентности. Вот дойдут до 10нм техпроцесса - кто знает, может все по второму кругу пойдет?
Ustus А говорят экстрасенсы в отпуске ?! После предыдущего поста именно эта мысль ползала по моему истощенному мозгу пока я ее решительно не смыл потоком холодного пивка
