Оптимизированный доступ к памяти.

Booster
Во-первых, разворот цикла - это уменьшение количества его итераций за счёт увеличения количества действий за одну итерацию. Возможная при этом параллельность некоторых операций - побочный эффект, имхо. В смысле, его может и не быть. Да можешь посмотреть всё в той же книге Криса - он там сначала вовсе не параллельность напирал. И даже сказал, что, мол, "мы и близко не достигли теоретической пропускной способности памяти". И только в следующем разделе сказал как это можно за счёт параллельности.

Во-вторых, да, при записи dword'ами команд меньше. Однако четыре команды записи байтами можно исполнить параллельно (от проца зависит... хотя я не уверен: а есть ли проц, на котором четыре mov'а можно исполнять разом?), ибо они независимы друг от друга и их опкоды уже давно в L1 кодовом кэше.
Так что при dword'ах ты уменьшаешь количество команд, да. Но и увеличиваешь количество действий за одну итерацию - в четыре раза.

P.S. leo?

 

Tier

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

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

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

 

Tier
Вообще речь была не о развёртке, а о записи байтами/двойными словами. Ещё у меня на P4 сильно поднимется быстродействие от записи с развёрткой (4X развёртка (в 3 раза при записи двойными словами и в 2 байтами)), о чём Крис вроде вообще не писал, хотя может я ещё до этого не дошёл. ^)

 

Сдаётся мне, что при развороте путём повторения тела цикла это не главное. Главное - это уменьшение количества jump'ов.

 

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

 

Дело не в самих параметрах DDR, а в соотношении частот DDR и CPU. Элементарная арифметика: на P4 частота памяти в 2400/400=6 раз ниже частоты CPU, поэтому при ширине шины 64 бита (два дворда) скорость их доставки не превышает 1 такт DDR = 6 тактов CPU. А обработка двух двордов процессором даже без разворота составляет 2*2=4 такта, а при развороте и того меньше. Например при развороте на 4 загрузка из ОЗУ 16 байт занимает 2*6=12 тактов, а обработка всего 1*4+(1..2)=5-6 тактов. И соотв-но добавление еще одной зависимой операции даст 2*4+(1..2) = 9-10 тиков - все равно быстрее чем ОЗУ.
А теперь то же самое посчитай для коры: 4 дворда грузятся всего за 2*3.16/1.33 < 5 тактов, и их обработка с разворотом на 4 занимает те же 5-6 тактов, т.е. проц уже тормозит относительно ОЗУ и соотв-но при добавлении еще одной зависимой операции скорость должна упасть как минимум вдвое. Резюме - дело не в "мощи", а в соотношении частот CPU и ОЗУ

Тем более, кора, несмотря на свою мощь, может идти лесом на зависимых операциях, т.к. NetBurst может выполнять зависимые add\sub на удвоенной частоте, а P6 только одну за такт. Но в рассматриваемом случае (x+=mem) они работают одинаково (в тактах), т.к. и P6 и NetBurst могут выполнять только одну загрузки из памяти за такт

 

leo

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

 

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

 

А как же зависимые операции? На них же конвейер тоже сбрасывается и Кора должна быть эффективней.

 

Ты бы хоть цитату привел - думаешь тут все наизусть знают все труды великого Криса ?!
Если речь идет об 1 байте и 1 дворде, то ес-но время их записи одинаково. Если же речь о записи большого массива, то тут возможны варианты. В общем действительно, чем более крупными блоками производится запись тем меньше требуется операций и тем соотв-но быстрее осущ-ся запись. Но если данные не в кэше, то тут опять нужно учитывать соотношение частот ОЗУ и CPU. В приведенном примере на P4 2.4ГГц с DDR-400 разницы действительно почти не будет, т.к. тормозит память, а не проц

 

В среднем да, а в частностях - у каждого свои достоинства и свои недостатки

Причем тут зависимые операции и сброс конвеера ? Ковеер сбрасывается только при непредсказанных переходах по условию (или при первом выполнении участка кода, когда встречается новый переход или call).

 

Если аргумент второй операции зависит от результата первой, то конвейер ждёт облом. Разве не так?

 

Нет. Просто вторая операция ждет первую. Если при этом есть другие независимые операции в буфере, то они исполняются вне очереди. Если нет таких операций, то происходит переполнение очереди планировщика и выдается сигнал на приостановку конвеера. По мере выполнения операций очередь освобождается и поступление команд из префетчера (или декодера) продолжается. Участок между префетчером и планировщиком - это не весь конвеер, а только часть (в P4 всего около 4-5 стадий из 20), поэтому пока выполняются старые команды из очереди планировщика, новые успевают заполнить конвеер или вообще без разрыва или с незначительным разрывом (bubble)
Также следует иметь в виду, что конвеер P4 не просто равномерно растянут в два раза по сравнению с P6, т.к. в P6 нехилое кол-во стадий тратится на декодирование команд (4-1-1..), а P4 работает с готовенькими мопами из кэша трасс, поэтому номер стадии засылки мопа в очередь планировщика у него отличается от P6 незначительно - от силы на 1-2 такта (это уже потом мопы вдвое дольше крутятся в планировщике, диспатчере и т.д.)

PS: И вообще, я думаю, что интелы прокололись, увеличив число стадий конвеера до 30 в Prescott, а вот если бы они Northwood продолжили бы до ума доводить, то в принципе неплохая была получилась "тачка", правда чересчур горячая

 

Tier

Нет, во всех интеловских процах за 1 такт можно выполнить только 1 чтение и 1 запись независимо от размера операнда (в Core2 до 16 байт, в остальных до 8 байт за раз), соотв-но в них только один блок load и одна парочка store_address\store_data. Соотв-но чем более крупными операндами производится чтение\запись массивов, тем в целом быстрее.
PS: В атлонах за 1 такт можно вычислять до 3-х адресов, но реально читать\сохранять можно только 2 операнда за такт (либо 2 чтения, либо 2 записи, либо 1 чтение и 1 запись)

Booster

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

 

leo

Читаться может 8 байт, а оптимальное чтение двойными словами. Чтение два раза двойными словами не параллельно, а movq тормоз ещё тот. Толи здесь какая-то недоработка, то-ли мне чего-то неизвестно. Зачем было делать шину данных 64 бита, если от этого толку всё равно мало?

 

А может дело в этом?

 

Y_Mur
Спасибо, похоже и правда movntq рулит. Ещё я ошибся в тесте с развёрткой при записи, там нету прироста. Для чтения всё же наверно кэш рулит. Хотя и не понимаю, почему чтение/запись четверного слова через кэш так тормозит.

 

Тогда по-идее на коре, 128бит movntpd будет ещё быстрее.

 

TermoSINteZ
На P4 она похоже здорово проигрывает 64бит movntq, так что пока не знаю.