Oj marny ten wniosek, marny.

Wskazana większa uwaga przy czytaniu testu :+)

Zapowiada się bardzo ciekawy artykuł, zabieram się do czytania. Szkoda tylko, że nie daliście jeszcze Piledrivera z 8 MB L3 i zablokowanymi modułami. Patrząc jednak na zadziwiająco małe różnice między Athlonem 750 a FX-4300, cudów by pewnie nie było...

I wydajność cache chcesz zabić odczytem z dysku?

Pomysł jak na razie nierealny, bo procesor nie ma informacji jaki program wykonuje. Dostaje ciąg instrukcji i na ich podstawie działa.
Można by pokusić się o programowalny układ predykcji skoków. W trakcie ładowania aplikacji system ładuje odpowiedni program układu.

Jest jeszcze problem taki, pod dany program jest optymalizacja, a co z całą resztą działającą w tle? Czy taka optymalizacja miałaby działać na jeden rdzeń/moduł, czy na cały procesor? Jeżeli na poszczególne jednostki, to co z przełączaniem zadań między jednostkami?

Generalnie lepiej optymalizować kod pod daną architekturę niż procesor pod dany program. Mniej okazji do dziwnych sytuacji i spadku wydajności.

Tak, ale najpewniej nie będzie 2-modułowca z 8 MB L3, więc takie porównanie byłoby czysto naukowe.

Wystarczy w FX-6300 zablokować jeden moduł, oczywiście biorąc poprawkę na różnicę w zegarach - FX-4300 - 3,8 GHz, FX-6300 - 3,5 GHz.

Raczej niezbyt realne, bo instrukcje są zaszyte w strukturze fizycznej procesora. Niektóre instrukcje potrafią być wykonywane nawet w czasie jednego taktu. Stworzenie dodatkowego pakietu instrukcji adaptacyjnych mogłoby być interesujące, ale łatwiej optymalizować programy pod procesory niż procesory pod programy

To to ja wiem Chodziło mi o to, że takowy test przekaże nam wiedzę czysto teoretyczną, bo w praktyce nie będzie takiego procesora (najpewniej). O to mi chodziło, bo tak to oczywiście można było i przetestować Core i7-2600K z dwoma rdzeniami bez HT na 3 GHz i porównać do Pentiuma G860

Nieee no. Mojej opadającej szczęki nie mam co szukać na podłodze, bede musiał iść do sąsiada piętro niżej . PC Labowcy ostatnio czytają w myślach czytelników. Czyżbyście zdobyli kryształową kulę renderująca myśli czytelników w DX11 i dzięki temu tak skutecznie je interpretujecie???

O kurcze...
Świetny art. Faktycznie nie ma sensu niby testować FX4300 vs FX63/83...

To potwierdza moje obserwacje na temat tego, że generalnie większy cache głównie przydaje się do tych najtrudniejszych zadań. Np. w renderingu jest różnica pomiędzy procesorami z większym cachem, ale.... no właśnie nie w prostej siatce nawet high-poly.
Ciekawe, że A10 wydajne tak samo jak FX...

Najważniejszy problem o jakim trąbie od dawna jest to, że właśnie....
....może zamiast większej kaszy dać więcej rdzeni.

W przypadku Vishera widzę, że można by wcisnąć jeszcze dwa moduły zamiast L3. Takie rozwiązanie dałoby AMD odpowiednią wydajność do rywalizacji z intelem na polu serwerowym.

Po co uczyć - procesory już to umieją. Przewidywanie skoków ze sprawnością 90% to nic niezwykłego we współczesnych procesorach.

Niby prawda, ale cały artykuł jest bardziej naukowy niż praktyczny (co nie jest zarzutem, wręcz przeciwnie). Ciekawi mnie, ile straciliśmy na decyzji AMD o obcięciu pamięci podręcznej FXa 4300 (FX-41xx miał pełne 8MB).

Focusie, w tamtym tygodniu napisałeś, że: 'w tym tygodniu będą testy FX4300/6300'. Ten tydzień już minął, zaczął się następny. Nie mogąc się doczekać, mam już procesorek w rękach, ale nadal proszę o wydanie tej recki

Brawa za pomysł, test ciekawy.

Wzięliście do testów C2D, a o Lynnfield'ach kompletnie zapomnieliście :/ A spora ilość osób wciąż siedzi na i5-750 czy i7-860 i im pochodnych...

Mimo wszystko, dzięki za fajny test.

No tak ale chyba zaden z posiadaczy i5-750 nie wymieni go na kolejnego Lynnfielda, bo sie nie oplaca, wiec test 750 vs 820 nie ma duzego sensu. Chodzi mi o to, ze ten test bylby bardziej praktyczny niz naukowy, kiedy porownywalby aktualnie dostepne procesory czyli Ivy Bridge vs IB i Vishere vs Vishere, bo to sa aktulane dylematy procesorowe uzytkownikow.

Ten test ma charakter bardziej naukowy niz zwykle porownanie procesorow wzgledem siebie i mozna dzieki niemu wysnuc konkretne wznioski co do pojemnosci pamieci podrecznej trzeciego poziomu i kozysci plynacych z duzej pamieci L3 w konkretnych zastosowaniach, np. widac wyraznie, ze do biura nie ma sesnsu brac duzego L3, bo bardziej licza sie gigaherce.

Dzieki za linka!

Nie ma miejsca w procesorze na trzymanie tych danych. Najpierw musisz sobie uświadomić co tutaj jest trudnością - pamięć podręczna jest malutka, będzie wielokrotnie wypełniona i opróżniona, a rozgałęzień miliony. Nie można sięgnąć do dysku albo ramu po wskazówki, bo to zbyt długo trwa, a w procesorze nie ma miejsca na trzymanie takich rzeczy.

Z drugiej strony, to co proponujesz to zwykłe profilowanie kodu. Kompilatory automatycznie ustawiają wszystko tak, żeby przewidywane w momencie kompilacji lub profilowania rozgałęzienia były ładowane do pamięci podręcznej. Są specjalne instrukcje, które pomijają pamięć podręczną i w efekcie jej nie zaśmiecają.

A pamiętasz ile Lynnfield miał pamięci? 8 MB L3 niezależnie od tego czy był to i5, czy i7. Bloomfield miał dokładnie tyle samo. Dopiero Sandy Bridge w Core i5 miał mniej.

Przygotowujemy, a raczej kończymy przygotowywać

Test bardzo fajny.
Chociaż wydaje mi się, że nie powinno porównywać się w grupie pierwszej Athlona II X4 651. Jest to rdzeń Llano, który poza większym L2 ma też inne modyfikacje. Większe IPC itd. Pewnie jest to około 3% ale tyle trzebaby odjąć od średniej, bo większy L2 tyle nie daje.

Aha. Brakuje jeszcze w platformach testowych płyty FM1.