Я хотел бы разработать определенные эмпирические правила, которые помогут решить определенные проблемы компьютерного дизайна/архитектуры. Следовательно, какие операции в памяти обычно занимают больше времени: загрузка или сохранение?? Я думаю, что это может помочь сделать мой выбор более реалистичным в процессе проектирования.
С архитектурной точки зрения это зависит от того, какую политику использует ваш кеш.
В политике сквозной записи результат любой операции сохраняется в кэше и в физической памяти в одном и том же цикле; поэтому операция записи займет больше времени, а операция чтения будет зависеть от наличия блока данных в кэше.
В политике обратной записи результат просто сохраняется в кэше и копируется в физическую память только тогда, когда требуется тот же блок данных. Поэтому запись и чтение могут быть с одинаковой скоростью или любой из них может быть медленнее.
Это сильно различается между архитектурами. Вероятно, нет никакого полезного эмпирического правила. Технология, используемая в сегодняшней памяти, обычно обеспечивает одинаковое время чтения и записи. Это определенно не соответствует действительности исторически и может оказаться неверным в будущем. Например, основная память по своей природе быстрее записывается, чем читается.
Все становится сложнее, когда используется кэш-память. Сегодня вы, вероятно, можете предположить, что кэш-память имеет фиксированное время цикла, будь то чтение или запись. Однако соображения системного уровня изменяют общую стоимость чтения или записи.
При чтении часть памяти где-то должна быть физически прочитана, и ничего нельзя сделать, пока не будет возвращен этот результат. Если данные находятся в кэше, они могут быть доступны настолько быстро, насколько процессор может их использовать. Если его нет в кеше, то что-то должно оседлать осла, рвануть в более дальнюю и медленную память, получить запланированное чтение, дождаться результата и рысью вернуться к процессору с данными. Обратите внимание, что может быть несколько уровней кэширования, при этом задержка становится намного больше для более удаленных уровней. Если используется виртуальная память (на самом деле это просто еще одна форма кэширования), а данные в настоящее время выгружены, то чтение может длиться столько же, сколько доступ к диску (или что-то еще на вашем запоминающем устройстве).
Запись имеет то преимущество, что действие можно инициировать, но вам не нужно ждать его завершения. Однако это добавляет сложности, поэтому не все системы работают таким образом. Что-то должно отслеживать то, что на самом деле не было записано, на случай, если запрос на чтение придет до завершения процесса записи. Затем чтение может застопориться или получить значение откуда-то частично через процесс записи. Здесь есть много возможностей для ускорения, но за это приходится платить сложностью и дополнительным оборудованием. Поэтому существует множество различных реализаций. Например, запись всегда может гарантировать запись в кэш первого уровня до завершения операции или до того, как произойдет чтение. Но что тогда делать, если весь кеш уже занят разными адресами? Это может потребовать записи фрагмента кэша в память следующего уровня перед завершением записи в кэш первого уровня. Опять же, есть много компромиссов.
Запись может выполняться сразу же быстрее, потому что процесс может быть перекрыт последующим выполнением, но в целом они могут быть более дорогостоящими. Запись новых данных в кеш любого типа приводит к тому, что этот раздел кеша помечается как «грязный». Это означает, что он должен быть записан как минимум на следующий уровень более медленной памяти, прежде чем его можно будет повторно использовать для кэширования другого фрагмента глобальной концептуальной памяти.
В целом, я бы не стал предполагать, что запись или чтение будут выполняться быстрее на современном высокопроизводительном компьютере общего назначения, поскольку может происходить много причудливого кэширования, предварительной выборки и перекрывающейся записи. Ответ не является детерминированным и может зависеть от длины цикла, того, что еще происходит, и даже от того, как происходит выравнивание интересующего вас кода в памяти.
Фахгеддабудит.
"Что занимает больше времени?" — очень расплывчатый вопрос, и ответ зависит от того, что вы пытаетесь оптимизировать.
В большинстве случаев, рассматривая общую производительность системы, вы обеспокоены остановкой конвейера выполнения в ЦП. В этом смысле загрузка всегда занимает больше времени, чем сохранение, в том смысле, что у хранения нет будущих операций, которые зависят от них, в то время как у загрузки есть.
Другими словами, при операции сохранения вы отправляете адрес и данные в иерархию памяти и практически забываете о них. Однако при операции загрузки вы отправляете адрес, а затем вам нужно дождаться данных. Компилятор и/или аппаратный планировщик может тем временем найти полезную работу, а может и не найти, но есть некоторая ненулевая вероятность того, что конвейеру придется остановиться, когда он доберется до операции, зависящей от загружаемых данных.
В иерархии памяти могут быть и другие узкие места, в зависимости от количества уровней кэша, их размеров, времени доступа, политик обратной записи, пропускной способности соединяющих их шин и т. д. С несколькими ядрами и общей памятью стратегия синхронизации кэша также становится проблемой. Все эти вещи потенциально могут привести к остановке операции загрузки.
Единственный способ, которым хранилище может создать стойло, — это если буферы записи в иерархии памяти заполняются, не позволяя им принять другое хранилище из конвейера выполнения.
Джиппи
клабаккио
xupv5