Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Напоминаем о том, что на сообщения новых участников распространяется действие системы премодерации сообщений.

О нарушениях можно сообщить модератору, нажав синюю кнопку #77 справа над спорным сообщением.

Када уже тестами порадуют?

про ассоциативность кеша уже писали в прошлом материале.
по контроллеру для дектопов вероятней всего будет либо 2 канала либо 4. для серверных решений видимо будет 4 и выше.
линий пси-е видимо будет от 20 для дектопа а для серверных решений не берусь прогнозировать.

Кажется, что как и в бульдозере и ко, будет 2 канала на каждый модуль и полный набор дополнительных задержек при доступе к памяти соседа, словно это двухпроцессорная система, а не 8и ядерный процессор. Честно говоря этот момент вызывает больше всего вопросов, так как точно негативно скажется на масштабирование задач, которые могут загрузить все ядра сразу. Впрочем актуально это больше в северном сегменте.

Так сколько метров L3 сможет отожрать однопоточное приложение?

И нарезать, наверное, на 2 или 4 ядра удобно.

Дай бог нагнуть хасвелл,
тогда норм!

чую беду.

Ровно столько, сколько размер кеша/ядра.
Однопоточное приложение???
Эпоха ДОС? Монополизация? Это Вам не курсовой думатель ядрёной ракеты, десятки, сотни потоков в фоне.

Один модуль обслуживает одновременно четыре ядра Zen с доступом каждого к любому участку L3
Подробнее: https://www.overclockers.ru/hardnews/78 ... d-zen.html

Ещё один не умеющий читать и делать выводы на основе прочитанного.
Да хоть 22 ядра к любому участку.
Вопрос был : сколько л3 выделится одному ядру в однопользовательском приложении.
Не компрене ву что-ли?
Выделится число Мб. / на число ядер.
Иначе будет монополизация процесса. Прощай многопоточность. Все ядра курят в уголке, ища в основной памяти, пока одно что-то там пыхтит.

Вообще L3 создавался для быстрого обмена между ядрами (т.е. для общих вычислений). Для вычислений у ядер есть L2 кеш.

Опять какие-то модули? А в ZEN+ они L3 переделают в цельный и выдадут за крутую фичу?

До полного размера кэша.



А ничего, что L3 был ещё во времена одноядерных систем?



Нет, выделится столько, сколько позволит ему алгоритм выделения кэша (в основном LRU). Если приложение активно лезет в память - кэша ему дадут больше.
Ну и плюс всякие технологии QoS для кэшей, но я хз как с этим будет в Zen: https://habrahabr.ru/company/intel/blog/144196/

Если будет +40% к вишере при том же частотном потенциале, то хорошо. Если нет, то опять слив и в лучшем случае мейнстрим-сегмент.

Вы правы. В данном случае весь смысл L3 (кроме кэширования) - синхронизация через него, а не через память, поэтому он и разделяемый. Но вот синхронизироваться сами L3 будут через ОЗУ. Насколько это плохо или все равно - покажет практика.


Но эта система не одноядерная. Был, и выполнял ту же роль: был быстрее ОЗУ. Просто раньше проблемы синхронизации памяти несколько ядер не стояло. Впрочем, в многопроцессорных системах все то же самое, и даже еще хуже.

Не факт. У оптеронов есть ht-assist и кроссбар.
И тут вполне может быть кросслинк между частями процессора.

HT-assist работает как раз в многопроцессорном варианте через HT.
Crossbar тоже никаких "кросслинков" между частями процессора не обеспечивает.

Можно, конечно, мучиться и пытаться объединить L3 между собой, но тогда возникает вопрос: почему было сразу не сделать его полностью разделяемым? Это архитектурно как-то обусловлено. Костылей, конечно, исключать нельзя, но в данном случае, я не уверен, что они тут даже нужны. Хотя делать что-то подобное в серверных процессорах, где таких наборов из 4х ядер может быть больше двух, возможно, AMD и будет.

Вообще-то 40% будет к экскаватору...

Если так, тогда догонят 6700к, может даже 5820к местами, т.к. 8 ядер. Весь вопрос в частотах.