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

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

А в чем суть-то?
Второй приём касается работы двух ядер с общим блоком данных, что требует постоянной синхронизации между ними. Если перейти к поочерёдному обращению к кэш-памяти, то это ликвидирует вычислительные затраты на синхронизацию. - и увеличит задержки при правильно сформированном коде? иначе говоря сделать так, чтобы говнокод работал быстрее, а хороший код медленнее?
или я что-то не так понимаю?

15%?
не стоило и новости

egan Да, чтото странное они придумали.
А ещё это:
Так, в случае заполнения кэш-памяти первого уровня учёные предлагают половину данных сбрасывать в разделяемую кэш-память, что в любом случае даст более быстрый доступ, чем к оперативной памяти. - убьёт всю производительность если блок интенсивно обрабатываемых данных будет рассчитан на почти полный размер кэша.
В сложных вещах вроде всегда идёт компромисс между кучей параметров и повышение в одном убивает другое, а они вот так вот просто типа решили проблему века.

вы что коллега? 15% ето ж 3 поколения интела)))

qartz
у intel интегрированная графика подросла.

хотел высказаться а тут все сказали... честно иногда мне кажется что "теоретики" не нужны...

Кажись сначала это внедрит IBM в своих процессорах, а потом может быть и Intel подтянется.

Что толку то у АМД L3 кеша в новых процессорах не предвидеться - значит опять только Интел ускорится а АМД отстанет!

Добавлено спустя 1 минуту 19 секунд:
Почему АМД не выпускает новый FX - не пойму? Ведь будут же брать!

Для амды полезны были бы такие новшества, у них кэш тормознутый- фактически висит мертвым грузом.

Добавлено спустя 3 минуты 35 секунд:

+15% не к производительности камня, а к скорости кэша. Сколько это даст прироста процессору? Дай бог +0.5-1.0 %

Добавлено спустя 1 минуту 10 секунд:
Хотя для амды может побольше дать, как я уже сказал. У них кэш никакой, интеловские камни с оперативкой работают и то быстрее.

Добавлено спустя 2 минуты 19 секунд:

Надо им ультиматумы не на Оверах объявлять, а на корпоративную почту писать.

Добавлено спустя 44 секунды:

Сомневаюсь. Поэтому и не выпускают.

Egorich1987
Это в играх может не дать, а в многопоточных приложениях- прилично.

В серверном сегменте похоже преимущество катка над копером не особо большое получается. Решили пропустить. А с ними - пропускают и FX, как побочный продукт.
Посмотрим, что экскаватор приготовит...

Допустим у нас есть две рядом расположенные переменные a и b в сегменте данных и два потока. Поток 1 пишет только переменную а, поток 2 только читает переменную b. Сегмент данных копируется в кэши ядер, после каждой записи переменной a первым потоком процессор вынужден сбрасывать линию кэша второго потока (64 байта), приостанавливая его на некоторое время. Предлагается размещать все данные в более медленной памяти и блокировать потоки единственным мьютексом на большее время. Большее время блокирования компенсируется частотой сброса при постоянных записях (возможно).
Ситуация размещения данных вполне типичная, хотя сейчас у программиста есть пространство для маневра - размещения переменных в разнесенных кусках. При новой организации ситуация не должна сильно ухудшится - при размещении переменных в разнесенных кусках синхронизатор не должен блокировать поток, если он не лезет в соседний кэш.
В итоге, возможно, что все целиком будет быстрее на каких-то алгоритмах, на каких-то медленнее. Но так как исходников широко используемых процессоров им никто не давал, и симуляцией они не могли проверить реальные программы - то практический эффект выглядит сомнительным.

Скорее наоборот, второй дикодер (добавленный в Steamroller) бесполезен в типичных ПК приложениях, а вот в серверах он бы пригодился.

не так понимаете.

правильно, нефиг привязываться к конкретным железкам. Это как использование недокументирвоанных фич. Нужно пользоваться АПИ, потому как реализация всегда может поменяться. Это наблюдается, когда начинается вонь "а вот на вин98 у меня прога шла, на ХР шла, а на 7/8 не идет". А потом оказывается, что прога использовала какой-нибудь хитрый оверфлоу какого-нибудь буфера и засчет этого что-то там делала. А кошерные Cache-Oblivious алгоритмы от этого только выиграют.

Добавлено спустя 1 минуту 31 секунду:
dE fENDER ой, да не надо разъяснять тонкости многопоточной синхронизации на мьютексах, лучше просто сказать человеку, что это заговор быдлокодеров чтобы покупали новые железки, тем более, что именно этот ответ ожидается

Добавлено спустя 1 минуту 26 секунд:

возможно они просто получили более быстрое теоретическое асимптотическое время при худших константах

Интересно, изменится ли влияние частоты памяти на производительность в обыденных, неспециализированных приложениях (ну да, например в играх)? Я вот даже даунклокнул свою оперативку с 2133 до 1600, т.к. разница была нулевой. Ведь по идее чем быстрее данные будут обработаны за счет быстрого кэша, тем быстрее они поступят в оперативную память, может все же прирост будет побольше 0.5-1%, обещанных Егорычем?

Для таких как ты сделали кабини с 1 Мб общего L2.
Вообще большой кеш полезен для устранения "заикания" ЦП при огромной одновременной нагрузке (например после включения винды).

Судя по тому, как тяжело и глючно идёт переход FM2/FM2+ со широко распространёнными сбросом памяти в одноканалку и нестабильной работой, для катка новый сокет будет желательно - напоминает по ощущениям AM3/AM3+ переход...

Кэш полезен всегда.

Добавлено спустя 4 минуты 52 секунды:

Если бы давал большой прирост - были бы новые камни на G34. Если новых камней нет - значит нет смысла их выкатывать, овчинка не стоит выделки.
А АМ3+ - просто побочный продукт серверного сегмента...