lkj
> Сложнее. Главная фишка direct-mapped в том, что мы читаем тег и данные за одно обращение.
Еще раз, медленно.Для особо одаренных. Не direct-mapped, а кэш, сделанный без отдельно лежащих быстрых тэгов. Сложите наконец последовательность в голове: 1) direct-mapped без отдельных тэгов, 2) direct-mapped с быстрыми тэгами, 3) ассоциативность = 2, 4) ассоциативность > 2.
С вариантом 1) все понятно - "я его слепила из того, что было". Имеет смысл сравнивать 2) и 3). По сложности они почти не различаются. Зато ассоциативность = 2 очень важна для алгоритмов, когда имеется рабочее множество в кэше плюс к этому большой потоковый трафик основной памяти. В direct-mapped этот трафик будет смывать кэш и существенно снизит его эффективность. В ассоциативном кэше он займет один "путь", а данные в остальной части кэше останутся нетронутыми.
> Теги для кэша в 32 GB будут занимать 2 GB для строк в 64 байта.
Никакой идиот так делать не будет. Вы зациклились. Впрочем, если вам не интересно обсуждать организацию нормальных эффективных кэшей, то давайте не будем. Хотя вы сами начали разговор на эту тему.
> Если сократить кэш до 16 GB, тогда теги будут занимать 60 MB.
Хватит фантазировать и капризничать. Легко посчитать, что для блока в 4K можно уложиться в 10-20 MB хоть для direct-mapped, хоть для ассоциативного = 2. А если сделать микротэги, то еще меньше. Для современного процессора такой размер - мелочь. Ах, да, вы почему-то любите подсчитывать транзисторы. Хоть это и не очень адекватный показатель, но почему бы и нет ? По достаточно консервативному и округленному подсчету 10-20 MB превращается в 0.75-1.5 миллиарда самых плотных транзисторов.
> Но большие сектора по 2 KB могут показать провалы производительности для случайных обращений.
Если рассматривать вопрос в целом, то легко догадаться, что для случайных обращений HBM-кэш никакого выигрыша не даст. И предназначен он в первую очередь не для этого.
> Кстати, CLX-AP вероятно не сможет нагрузить 1 TB/s HBM2 полностью.
Не будет там никакого HBM2.
> Так два больших чипа CLX-AP по 600 mm2 (1200 mm2 в сумме) будут проигрывать одному небольшому чипу a64fx размером примерно 330 mm2
У этих продуктов разное назначение.
> Сложнее. Главная фишка direct-mapped в том, что мы читаем тег и данные за одно обращение.
Еще раз, медленно.
С вариантом 1) все понятно - "я его слепила из того, что было". Имеет смысл сравнивать 2) и 3). По сложности они почти не различаются. Зато ассоциативность = 2 очень важна для алгоритмов, когда имеется рабочее множество в кэше плюс к этому большой потоковый трафик основной памяти. В direct-mapped этот трафик будет смывать кэш и существенно снизит его эффективность. В ассоциативном кэше он займет один "путь", а данные в остальной части кэше останутся нетронутыми.
> Теги для кэша в 32 GB будут занимать 2 GB для строк в 64 байта.
Никакой идиот так делать не будет. Вы зациклились. Впрочем, если вам не интересно обсуждать организацию нормальных эффективных кэшей, то давайте не будем. Хотя вы сами начали разговор на эту тему.
> Если сократить кэш до 16 GB, тогда теги будут занимать 60 MB.
Хватит фантазировать и капризничать. Легко посчитать, что для блока в 4K можно уложиться в 10-20 MB хоть для direct-mapped, хоть для ассоциативного = 2. А если сделать микротэги, то еще меньше. Для современного процессора такой размер - мелочь. Ах, да, вы почему-то любите подсчитывать транзисторы. Хоть это и не очень адекватный показатель, но почему бы и нет ? По достаточно консервативному и округленному подсчету 10-20 MB превращается в 0.75-1.5 миллиарда самых плотных транзисторов.
> Но большие сектора по 2 KB могут показать провалы производительности для случайных обращений.
Если рассматривать вопрос в целом, то легко догадаться, что для случайных обращений HBM-кэш никакого выигрыша не даст. И предназначен он в первую очередь не для этого.
> Кстати, CLX-AP вероятно не сможет нагрузить 1 TB/s HBM2 полностью.
Не будет там никакого HBM2.
> Так два больших чипа CLX-AP по 600 mm2 (1200 mm2 в сумме) будут проигрывать одному небольшому чипу a64fx размером примерно 330 mm2
У этих продуктов разное назначение.