http://www.3dnews.ru/cpu/phenom_x4_9850/print - а вот сравнение 1 Фена и Квада 9300

Ядро в Phenom II осталось прежним, вычислялка, латентность L1 и L2 - прежние, ширина шин - естественно прежние, аппаратная выборка на том же уровне. Поэтому ядро в К10 было не таким и слабым, просто 65-нм + кэш в 2 метра - было не очень удачным для него решением.

нет ничего проще. Статьи на фцентре в отличии от других ресурсов(не будем показывать пальцем) рассортированы отлично.

http://www.fcenter.ru/online.shtml?arti ... sors/25857

только Гаврик не учёл FSB. Ему можно.
Это его работа. Смешивать правду и вымысел и выдавать за чистую монету. А что вы хотели?

А зачем ему чё-то учитывать ? он прогнал тесты на дефолтных процах и выдал результаты.

П.с. с холиварищем к автору этого обзора

Никуда квады не проваливаются. С какого перепугу им это делать?

К Гаврику с фцентра что-ли? Да на кой хрен он мне сдался?

Как то результаты тестов везде говорят об обратном. Причем тесты на многих ресурсах, а не где то в каком то одном кривом месте
К примеру раз два три

Это не мной привидённая линка, я только посмотрел и процитировал

И этот же автор впоследствии написал эти выводы:

http://www.fcenter.ru/online.shtml?articles/hardware/processors/29800
В этом же обзоре Phenom-ы оккупировали верхние строчки, а в прошлом были мягко говоря шнягой.
Кому верить? Раннему Gavric-у или более позднему и бородатому?

Ну как бе я Гаврику вообще не доверяю (ни раннему, ни позднему)
Кстати, поэтому и вообще сомневаюсь, что он способен адекватно сравнить производительность именно ядер на феноме и на феноме II.

У меня был Q9550, сейчас у меня 1055T, если считать "де-факто" 1055Т равным в большинстве игра 945-фену, то скажу, что 945 фен равен Q9550 (естественно не занимался мозготрахательными замерами - субъективно). А учитывая монокристальность фена, более живой прирост скорости в 64-битных ОС и приложениях, возможность того, что они в современных условиях могут быть быстрее (даже если сравнивать ЦП со сходными частотами) чем Core 2 Quad, очень даже вероятна. Не вижу причин для споров - кроме фанатства.
В современных приложениях Core i5/i7 тоже ушли вперёд - так что разрыв между процами AMD и Intel-а всё равно остался (вопрос для другого спора "Оправдывает ли этот 10-20% разрыв цена, которая минимум в полтора раза больше?").

Кто же виноват, что на старые C2Q начали подзабивать? Сейчас всё пишется под новые i5/i7, а они конструктивно ближе к Phenom-у, нежели к старым квадам - вот фены и начали получать скоростной пендель.

Пишеться оно как и писалось раньше, в лучшем случае делаются оптимизации под многопоточность, а кому удобней пережёвывать такого рода "высер" это уже не проблеммы софтописателей. Еслиб были какие либо заточки под архитектуру, х6 фен никогда в жизни ни в одном приложении не показал результат ниже равночастотного х4

Это где такое? Единственное, где у х6 будут потери, так это на обыск кешей 2 дополнительных ядер.

http://www.ixbt.com/cpu/amd-cpu-series-2010-part4.shtml
У x6 тоже проблемы случаются.

Падение производительности случается в плохооптимизированных под многопоточность приложениях. Например которые юзают одно или два ядра. Чтобы такого не было можно через диспетчер задач задать для приложения столько ядер сколько ему нужно и тогда винда не будет перекидывать потоки с ядра на ядро. Соответственно не будет падения производительности из-за потерь на перебрасывание тредов.

Здесь можно рассуждать годами, почему-же эти плохооптимизированные приложения тогда х4 так не просаживают ? или они его тоже просаживают но х6 ещё больше ?
Откуда я могу знать сколько приложению надо ядер ?
Если приложение уже запущенно и прошла инициализация на 4 ядра, я отключу 2 что я получу? ещё большее падение производительности чем с 4-мя? а оно мне надо ?

Скорей всего в кратности дело, потому как если создаются 8 потоков (тем более, что распространено 2,4,8 потоков (ведь Интел имеет всего лишь один редкий 6 ядерник) - под них и пишут - видимо, проще), то они (2 лишних потока) попусту лезут на 6 работающих ядер и наводят там неразбериху - похоже проблема как с софтописателями, так и со стороны диспетчера, который запросто может на один работающий поток (в котором случился просто из-за ожидания данных) кинуть другой и потом уже работавший ранее поток перекинуть на другой (типа перебрасывает потоки с одного нагруженного ядра на другой менее нагруженный)...

Вы попробуйте представить как работает диспетчер тредов в винде. Его задача равномерно нагрузить все ядра. Но как он это сделает если приложение однопоточное? Вот он и занимается ерундой(перекидыванием потока по ядрам). Чем больше ядер тем больше у него простора для того чтобы натворить делов. Поэтому если для вас важна максимальная производительность то задавайте для приложения меньшее число доступных ядер и смотрите как меняется производительность.

Добавлено спустя 17 минут 48 секунд:
Во-первых никакой инициализации не существует. Приложение создает столько потоков сколько было задумано создателями. Некоторые программисты указывают сколько ядер должно использовать приложение, но большинство полагается на диспетчер потоков виндовса. Который, как я уже говорил, не всегда способен адекватно реагировать.

Everlast82 вы программист ? Я нет, если вы тоже не програмист, то давайте оставим этот флейм им.