Комментарии 15
НЛО прилетело и опубликовало эту надпись здесь
Отключать кэши хорошо, когда используется память с латентностью один такт (и если это не противоречит архитектуре процессора в целом). А для динамической памяти совсем не здорово…
С тем же успехом можно под полным программным контролем заливать нужные области памяти по DMA в on-chip SRAM, у которой латентность как раз один такт (такая память называется Scratchpad Memory, Closely Coupled Memory или Tightly Coupled Memory, как кличет ее ARM). На этот счет есть любопытные исследования, могу дать ссылок. В общем, варианты есть, и кэш не должен рассматриваться как панацея.
Так давайте ссылок
Личный опыт показывает, что загрузка кода в SRAM не только бесполезна, но и вредна. На stm32f103 (без кеша) и stm32f407 (с кешем) это вызывало падение производительности.
TCM тоже совсем не панацея, по банальной причине, в тех мк с которыми мне довелось работать он сидел на D-bus, т.е. из него нельзя было выполнять код
PS копировать код по мере надобности — хороший способ достичь заявленной в названии поста цифры 1000 тактов на 10 команд
Личный опыт показывает, что загрузка кода в SRAM не только бесполезна, но и вредна. На stm32f103 (без кеша) и stm32f407 (с кешем) это вызывало падение производительности.
TCM тоже совсем не панацея, по банальной причине, в тех мк с которыми мне довелось работать он сидел на D-bus, т.е. из него нельзя было выполнять код
PS копировать код по мере надобности — хороший способ достичь заявленной в названии поста цифры 1000 тактов на 10 команд
Разумеется, речь не идет про SRAM, висящий на внешней шине вместе с периферийными устройствами. С точки зрения процессора это такая же внешняя память, как какой-нибудь DDR, даже если физически она находится на том же кристалле. Даже если память сама по себе обеспечивает доступ за один такт, все равно будет дополнительная задержка в бридже между процессором и шиной, а также накладные расходы на арбитраж.
CCM/TCM — совсем другое дело. Этот тип памяти фактически встроен в конвейер. Если в процессоре есть кэши, то CCM/TCM расположены бок о бок с ними, а не за ними, как SRAM на внешней шине. В процессоре с гарвардской архитектурой CCM/TCM для команд и данных раздельные, как и кэши. Кроме того, такая память может быть двухпортовой, и тогда процессор может читать из нее, скажем, команды, а DMA-контроллер одновременно может копировать в нее блок из внешней памяти.
Вот несколько ссылок, которые были под рукой:
Predictable Programming on a Precision Timed Architecture
Software-based Instruction Caching for Embedded Processors
An Optimal Memory Allocation Scheme for Scratch-Pad-Based Embedded Systems
CCM/TCM — совсем другое дело. Этот тип памяти фактически встроен в конвейер. Если в процессоре есть кэши, то CCM/TCM расположены бок о бок с ними, а не за ними, как SRAM на внешней шине. В процессоре с гарвардской архитектурой CCM/TCM для команд и данных раздельные, как и кэши. Кроме того, такая память может быть двухпортовой, и тогда процессор может читать из нее, скажем, команды, а DMA-контроллер одновременно может копировать в нее блок из внешней памяти.
Вот несколько ссылок, которые были под рукой:
Predictable Programming on a Precision Timed Architecture
Software-based Instruction Caching for Embedded Processors
An Optimal Memory Allocation Scheme for Scratch-Pad-Based Embedded Systems
Какая-то странная заметка, честно говоря.
КЭШ нужен для того, чтобы смягчить издержки при повторном обращении к данным, в этом вся его соль. Исследования и практика показывают, что доступ к уже имеющимся данным действительно происходит очень часто. Именно поэтому КЭШ это лучшее из того, что мы имеем сейчас. И именно благодаря ему сейчас увеличивается производительность(ну не только благодаря ему, но его вклад очень велик). Поэтому эта ваша фраза мягко говоря не имеет ничего общего с реальностью.
Я не знаю понятия «write burst», зато знаю «write through» и «write back». И эти обе стратегии не требуют от программистов никаких усилий. Кроме того, первая обновляет память сразу же, без ожидания «вытеснения».
Исходя из вышесказанного и размера статьи(написать про КЭШ три экрана это просто смех), я бы поставил 3- этой статье. Да и то с натягом.
P.S. не сочтите за наезд, просто заметка действительно сырая и противоречивая.
Поэтому если в вашем процессоре есть кэш — выключите его от греха подальше!
КЭШ нужен для того, чтобы смягчить издержки при повторном обращении к данным, в этом вся его соль. Исследования и практика показывают, что доступ к уже имеющимся данным действительно происходит очень часто. Именно поэтому КЭШ это лучшее из того, что мы имеем сейчас. И именно благодаря ему сейчас увеличивается производительность(ну не только благодаря ему, но его вклад очень велик). Поэтому эта ваша фраза мягко говоря не имеет ничего общего с реальностью.
Никакого «write burst» не будет до тех пор, пока программист явно не позабоится о том, чтобы «слить» обновленную строку кэша обратно в память (то есть сделать cache line flush), либо пока строка не будет вытеснена из кэша другой строкой.
Я не знаю понятия «write burst», зато знаю «write through» и «write back». И эти обе стратегии не требуют от программистов никаких усилий. Кроме того, первая обновляет память сразу же, без ожидания «вытеснения».
Исходя из вышесказанного и размера статьи(написать про КЭШ три экрана это просто смех), я бы поставил 3- этой статье. Да и то с натягом.
P.S. не сочтите за наезд, просто заметка действительно сырая и противоречивая.
Статья про конкретный кусок кода и его испонение процессором с кэшами. Про то, как реально происходят запросы в память и чего можно от них ожидать. Цели объяснять азы работы кэша я не ставил (благо ссылка на неплохую статью имеется в начале).
«Write burst» показан на последнем рисунке слева — он происходит, пока сигнал «Писать» выставлен в единицу. «Write-back» — это как раз то, как работает мой абстрактный процессор (который работает так же, как один широко известный в узких кругах реальный процессор). Очевидно, что он может потребовать некоторых усилий от программиста, особенно если тот пишет драйвер или программу для многоядерной системы.
«Write burst» показан на последнем рисунке слева — он происходит, пока сигнал «Писать» выставлен в единицу. «Write-back» — это как раз то, как работает мой абстрактный процессор (который работает так же, как один широко известный в узких кругах реальный процессор). Очевидно, что он может потребовать некоторых усилий от программиста, особенно если тот пишет драйвер или программу для многоядерной системы.
Т.е. write burst это запись из КЭШ в ОЗУ?
А разве можно заставить КЭШ записать в ОЗУ при write back стратегии? Покажите пример, если можно, желательно в терминах x86.
По поводу «виртуального контроллера»: пока читал статью забыл об этом отступлении в начале статьи, так что приношу свои извинения. Я решил, что статья общая.
Очевидно, что он может потребовать некоторых усилий от программиста, особенно если тот пишет драйвер или программу для многоядерной системы.
А разве можно заставить КЭШ записать в ОЗУ при write back стратегии? Покажите пример, если можно, желательно в терминах x86.
По поводу «виртуального контроллера»: пока читал статью забыл об этом отступлении в начале статьи, так что приношу свои извинения. Я решил, что статья общая.
«Write burst» — это не просто запись в ОЗУ, это пакетная запись в ОЗУ строки кэша для минимизации задержек на внешней шине процессора. Это настолько критично с точки зрения производительности, что все современные протоколы системных шин (те же AHB, AXI и т.д.) поддерживают специальные команды для записи/чтения строк кэша (так называемые «wrap bursts»), специально заточенные под режим «critical word first».
Совершенно точно можно заставить кэш данных записать свое содержимое в ОЗУ при «write-back» стратегии, причем в некоторых случаях это можно сделать как для всего кэша целиком, так и для конкретной строки. Для этого в процессоре предусмотрены команды или управляющие регистры. Запись измененных данных из кэша в ОЗУ называется «cache flushing». Для х86 это делается так: stackoverflow.com/questions/1756825/cpu-cache-flush
Совершенно точно можно заставить кэш данных записать свое содержимое в ОЗУ при «write-back» стратегии, причем в некоторых случаях это можно сделать как для всего кэша целиком, так и для конкретной строки. Для этого в процессоре предусмотрены команды или управляющие регистры. Запись измененных данных из кэша в ОЗУ называется «cache flushing». Для х86 это делается так: stackoverflow.com/questions/1756825/cpu-cache-flush
Можете посоветовать чтиво по протоколам шин и прочим около-того темам? Желательно книги.
С тех пор, как прикрыли Гигапедию, с книгами тяжко :) Я бы рекомендовал начать вот с этого: AMBA 2 Specification. Это не книга, а спецификация, но написана очень понятно, много картинок, к тому же бесплатная (надо только зарегистрироваться). Если есть какой-никакой бэкграунд, хотя бы на уровне институтского курса по цифровой схемотехнике — разобраться не составит труда. Читать можно только про AHB и APB — они до сих пор актуальны, в отличие от ASB.
Если есть возможность, можно полистать вот эти книжки: On-Chip Communication Architectures: System on Chip Interconnect или Networks on Chips: Technology and Tools
Если есть возможность, можно полистать вот эти книжки: On-Chip Communication Architectures: System on Chip Interconnect или Networks on Chips: Technology and Tools
Команда сброса кэша? Сброса линейки кэша (это уже смотря как контроллер).
Статья про конкретный кусок кода и его испонение процессором с кэшами.
Поэтому если в вашем процессоре есть кэш — выключите его от греха подальше!
А не слишком ли категорические выводы вы тогда делаете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Секреты кэш-памяти, или как потратить 1000 тактов на 10 команд