1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

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

Тема в разделе "WASM.A&O", создана пользователем Booster, 27 май 2009.

  1. Tier

    Tier New Member

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

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

    P.S. leo? :)
     
  2. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    Tier
    В том то и дело, что аппаратная оптимизация и основана на побочных эффектах. Разворот цикла позволяет более часто, почти одновременно давать запросы памяти, что как уже выяснили не совсем актуально при аппаратном префетче.

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

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

    Booster New Member

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

    Tier New Member

    Публикаций:
    0
    Регистрация:
    14 янв 2008
    Сообщения:
    7
    Сдаётся мне, что при развороте путём повторения тела цикла это не главное. Главное - это уменьшение количества jump'ов.
     
  5. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    И это наверно тоже. Но думается что это гораздо меньше влияет, чем скажем от параллельного чтения.
     
  6. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    Дело не в самих параметрах 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 могут выполнять только одну загрузки из памяти за такт
     
  7. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    leo
    Может я чего-нибудь не понимаю, но всегда считал что на зависимых и не оптимизированных операциях, NetBurst ввиду длины конвеера, сильно тормозит. И это был скорее маркетинговый трюк интела, так как чтобы эта хрень выдала свой потенциал, надо сильно постараться.
     
  8. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    Длина конвеера сказывается только на начальной задержке выполнения куска кода. На практике она проявляется только в виде штрафа за непредсказанный переход. А если нет переходов или они все предсказыватся, то нет и штрафов (в больших циклах все переходы к началу цикла предсказываются верно, кроме последнего - при выходе из цикла)
     
  9. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    А как же зависимые операции? На них же конвейер тоже сбрасывается и Кора должна быть эффективней.
     
  10. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    Ты бы хоть цитату привел - думаешь тут все наизусть знают все труды великого Криса ?! ;)
    Если речь идет об 1 байте и 1 дворде, то ес-но время их записи одинаково. Если же речь о записи большого массива, то тут возможны варианты. В общем действительно, чем более крупными блоками производится запись тем меньше требуется операций и тем соотв-но быстрее осущ-ся запись. Но если данные не в кэше, то тут опять нужно учитывать соотношение частот ОЗУ и CPU. В приведенном примере на P4 2.4ГГц с DDR-400 разницы действительно почти не будет, т.к. тормозит память, а не проц
     
  11. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    В среднем да, а в частностях - у каждого свои достоинства и свои недостатки

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

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    Если аргумент второй операции зависит от результата первой, то конвейер ждёт облом. Разве не так?
     
  13. leo

    leo Active Member

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

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

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    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 тактов в общее время итерации. Соотв-но и скорость увеличивается (при условии, что память не тормозит), т.к. и команд меньше и возможность распараллеливания в общем случае увеличивается, т.к. лишние операции под ногами не путаются ;)
     
  15. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    leo
    Читаться может 8 байт, а оптимальное чтение двойными словами. Чтение два раза двойными словами не параллельно, а movq тормоз ещё тот. Толи здесь какая-то недоработка, то-ли мне чего-то неизвестно. Зачем было делать шину данных 64 бита, если от этого толку всё равно мало?
     
  16. Y_Mur

    Y_Mur Active Member

    Публикаций:
    0
    Регистрация:
    6 сен 2006
    Сообщения:
    2.494
    А может дело в этом?
     
  17. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    Y_Mur
    Спасибо, похоже и правда movntq рулит. Ещё я ошибся в тесте с развёрткой при записи, там нету прироста. Для чтения всё же наверно кэш рулит. Хотя и не понимаю, почему чтение/запись четверного слова через кэш так тормозит.
     
  18. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    Тогда по-идее на коре, 128бит movntpd будет ещё быстрее.
     
  19. TermoSINteZ

    TermoSINteZ Синоби даоса Команда форума

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.131
    Адрес:
    Russia
    Booster
    Так это уже SSE2 :-). Конечно будет быстрее.
     
  20. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.862
    TermoSINteZ
    На P4 она похоже здорово проигрывает 64бит movntq, так что пока не знаю.